通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用适用于 Prometheus 的 Azure Monitor 托管服务扩展 Azure Monitor 工作区的最佳做法

使用适用于 Prometheus 的 Azure Monitor 托管服务可以大规模收集和分析指标。 Prometheus 指标存储在 Azure Monitor 工作区中。 该工作区支持的分析工具包括 Azure 托管的 Grafana、支持 PromQL 的 Azure Monitor 指标资源管理器，以及 PromQL 和 Grafana 等开源工具。

本文提供了组织 Azure Monitor 工作区以满足规模和不断增长的数据引入量的最佳做法。

拓扑设计条件

单个 Azure Monitor 工作区足以满足许多用例的需求。 某些组织会创建多个工作区以更好地满足他们的要求。 确定创建额外工作区的正确标准时，应创建可满足要求的最低数量的工作区，同时进行优化以最大限度地减少管理开销。

下面是需要将 Azure Monitor 工作区拆分为多个工作区的方案：

情景 最佳做法
主权云 使用多个主权云时，请在每个云中创建一个 Azure Monitor 工作区。
合规性或法规要求 如果你受到要求在特定区域存储数据的法规的约束，请根据要求为每个区域创建一个 Azure Monitor 工作区。
区域缩放 若要管理区域多样化的组织（例如具有区域帐户的大型服务或金融机构）的指标，请为每个区域创建一个 Azure Monitor 工作区。
Azure 租户 对于多个 Azure 租户，请在每个租户中创建一个 Azure Monitor 工作区。 不支持跨租户查询数据。
部署环境 为每个部署环境创建单独的工作区，以维护开发、测试、预生产环境和生产环境的离散指标。
服务限制和配额 Azure Monitor 工作区设有默认引入限制，可通过提交支持工单请求提升限额。 如果即将达到摄入限制，或估计超出限制，请考虑请求增加限制，或将工作区拆分为两个或多个工作区。

服务限制和配额

Azure Monitor 工作区对指标设有默认配额和限制，即每分钟最多引入 100 万个事件‌。 随着使用量的增长，需要引入更多指标，可以请求增加此限额。 如果容量要求非常大，并且数据引入需求超出了单个 Azure Monitor 工作区的限制，请考虑创建多个 Azure Monitor 工作区。 使用 Azure Monitor 工作区平台指标来监视利用率和限制。 有关限制和配额的详细信息，请参阅 Azure Monitor 服务限制和配额。

请考虑以下用于管理 Azure Monitor 工作区限制和配额的最佳做法：

最佳做法 DESCRIPTION
监视并创建有关引入限制和利用率的警报。 在 Azure 门户中，导航到你的 Azure Monitor 工作区。 转到“指标”，验证指标活动时序利用率和每分钟引入的事件利用率是否低于 100%。 设置 Azure Monitor 警报以监视利用率，并在利用率超过限制的 80% 时触发。 有关监视利用率和限制的详细信息，请参阅如何监视服务限制和配额。
当利用率超过当前限制的 80% 时，请求增加限制。 随着 Azure 使用量的增长，引入的数据量可能会增加。 如果数据引入量超过或接近引入限制的 80%，建议请求增加限制。 若要请求提升限额，请提交支持工单。 若要提交支持工单，请参阅创建 Azure 支持请求。
估算预计的规模。 随着使用量的增长并将更多指标引入工作区，请估算预计的规模和增长率。 请根据预测的使用量，请求提升限额。
使用 Azure Monitor sidecar 容器通过远程写入引入指标。 如果使用 Azure Monitor sidecar 容器或远程写入功能将指标引入 Azure Monitor 工作区，请考虑以下限制：
  • Sidecar 容器最多可以处理 150,000 个唯一时间序列。
  • 容器可能会在处理超过 150,000 个请求时（由于并发连接数较高）引发错误。 通过将远程批处理大小从默认值 500 增加到 1,000 来缓解此问题。 更改远程批大小可减少打开的连接数。
    		•
    DCR/DCE 限制。 限制适用于将 Prometheus 指标数据发送到 Azure Monitor 工作区的数据收集规则 (DCR) 和数据收集终结点 (DCE)。 有关这些限制的信息，请参阅 Prometheus 服务限制。 这些限制无法提高。

    请考虑创建更多的 DCR 和 DCE，以跨多个终结点分配数据摄取负载。 此方法有助于优化性能并确保高效的数据处理。 有关创建 DCR 和 DCE 的详细信息，请参阅 如何为现有 Azure Monitor 工作区创建自定义数据收集终结点（DCE）和自定义数据收集规则（DCR），以引入 Prometheus 指标。

    针对大量数据，优化性能

    摄入

    若要优化引入，请考虑以下最佳做法：

    最佳做法 DESCRIPTION
    识别高基数指标。 识别具有高基数的指标或生成许多时间序列的指标。 确定高基数指标后，优化它们，删除不必要的标签以减少时间序列的数量。
    使用 Prometheus 配置优化引入。 Azure 托管 Prometheus 提供 Configmaps，其中具有可配置并用于优化引入的设置。 有关详细信息，请参阅 ama-metrics-settings-configmap 和 ama-metrics-prometheus-config-configmap。 这些配置采用与 Prometheus 配置文件相同的格式。
    有关自定义收集的信息，请参阅在 Azure Monitor 适用于 Prometheus 的托管服务中自定义 Prometheus 指标的抓取。 例如，请考虑以下事项：

  • 调整抓取间隔。
    • 默认抓取频率为 30 秒，可以使用 configmap 根据默认目标更改此频率。 若要平衡数据粒度和资源使用状况之间的权衡关系，请根据指标的关键性调整 scrape_interval 和 scrape_timeout。

  • 为高基数指标删除不必要的标签。
    • 对于高基数指标，请识别不必要的标签并删除这些标签以减少时序数量。 使用 metric_relabel_configs 从引入中删除特定标签。 有关更多信息，请参阅 Prometheus 配置。

    使用 configmap，根据需要更改设置，并将 configmap 应用到群集的 kube-system 命名空间。 如果使用远程写入来写入到 Azure Monitor 工作区，请在引入期间在 Prometheus 配置中直接应用自定义项。

    查询

    若要优化查询，请考虑以下最佳做法：

    使用记录规则优化查询性能

    Prometheus 记录规则用于预先计算常用或计算成本高昂的查询，使其更高效、查询速度更快。 记录规则对于查询原始数据可能很慢且耗费资源的大容量指标特别有用。 有关详细信息，请参阅记录规则。 Azure 托管 Prometheus 通过 Azure 托管 Prometheus 规则组提供一种托管且可扩展的方式来创建和更新录制规则。

    创建规则组后，Azure 托管 Prometheus 会自动加载并开始评估这些规则组。 从 Azure Monitor 工作区查询规则组，像其他 Prometheus 指标一样。

    记录规则具有以下优势：

    • 提高查询性能 记录规则可以用于预计算复杂查询，以便在以后查询时更快。 通过预计算复杂查询，可在查询这些指标时减少 Prometheus 上的负载。

    • 效率和缩短查询时间 记录规则预计算查询结果，减少了查询数据所需的时间。 对于具有多个面板或高基数指标的仪表板，这一点特别有用。

    • 单纯 记录规则简化了 Grafana 或其他可视化工具中的查询，因为它们可以引用预计算指标。

    以下示例演示了 Azure 托管 Prometheus 规则组中定义的记录规则：

    "record": "job:request_duration_seconds:avg ",
"expression": "avg(rate(request_duration_seconds_sum[5m])) by (job)",
"labels": {  "workload_type": "job"
                        },
"enabled": true

    对于更复杂的指标，请创建聚合多个指标或执行更高级的计算的记录规则。 在以下示例中，instance:node_cpu_utilisation:rate5m 会计算 CPU 未空闲时的 CPU 利用率

    "record": "instance:node_cpu_utilisation:rate5m",
 "expression": "1 - avg without (cpu) (sum without (mode)(rate(node_cpu_seconds_total{job=\"node\", mode=~\"idle|iowait|steal\"}[5m])))",
"labels": {
                            "workload_type": "job"
                        },
"enabled": true

    请考虑以下优化记录规则的最佳做法：

    最佳做法 DESCRIPTION
    识别大容量指标。 重点关注那些查询频繁且基数较高的指标。
    优化规则评估间隔。 若要在数据新鲜度和计算负载之间取得平衡，请调整记录规则的评估间隔。
    监控性能。 监视查询性能并根据需要调整记录规则。
    通过限制范围优化规则。 为了加快记录规则的速度，请将其范围限制在特定群集内。 有关详细信息，请参阅限制特定群集的规则。

    在查询中使用筛选器

    使用筛选器优化 Prometheus 查询涉及细化查询以仅返回必要的数据，减少已处理的数据量并提高性能。 以下是优化 Prometheus 查询的一些常见技术。

    最佳做法 DESCRIPTION
    使用标签筛选器。 标签筛选器有助于缩小数据范围，仅显示你需要的数据。 Prometheus 允许使用 {label_name="label_value"} 语法进行筛选。 如果多个群集中存在大量指标，则限制时序的一种简单方法是使用 cluster 筛选器。

    例如，按群集 container_cpu_usage_seconds_total 筛选，而不是进行 container_cpu_usage_seconds_total{cluster="cluster1"} 查询。
    应用时间范围选择器。 使用特定的时间范围可以显著减少查询的数据量。

    例如，不要使用 http_requests_total{job="myapp"} 查询过去七天的所有数据点，而是使用 http_requests_total{job="myapp"}[1h] 查询过去一小时的数据点。
    使用聚合和分组。 聚合函数可用于汇总数据，这比处理原始数据点更有效率。 聚合数据时，请使用 by 按特定标签分组，或使用 without 排除特定标签。

    例如，按作业分组的总和请求数：sum(rate(http_requests_total[5m])) by (job)。
    在查询的早期进行筛选。 若要从一开始就限制数据集，请尽早在查询中应用筛选器。 例如，不要使用 sum(rate(http_requests_total[5m])) by (job)，而是先进行筛选，然后按如下方式聚合：sum(rate(http_requests_total{job="myapp"}[5m])) by (job)。
    尽可能避免正则表达式。 正则表达式筛选器功能强大，但计算成本也很高。 尽可能使用完全匹配项。 例如，使用 http_requests_total{job=~"myapp.*"}，而不是 http_requests_total{job="myapp"}。
    对历史数据使用偏移量。 如果要将当前数据与历史数据进行比较，请使用 offset 修饰符。

    例如，若要将当前请求与 24 小时前的请求进行比较，请使用 rate(http_requests_total[5m]) - rate(http_requests_total[5m] offset 24h)。
    限制图表中的数据点。 创建图表时，限制数据点数以提高呈现性能。 使用步进参数来控制解析度。

    例如，在 Grafana 中：设置更大的步值以减少数据点：http_requests_total{job="myapp"}[1h:10s]。

    并行查询

    在 Prometheus 中运行大量并行查询可能会导致遭遇性能瓶颈，并影响 Prometheus 服务器的稳定性。 若要高效处理大量并行查询，请遵循以下最佳做法：

    最佳做法 DESCRIPTION
    查询负载分布。 通过将查询分散到不同的时间间隔或 Prometheus 实例来分配查询负载。
    交错查询。 将查询设定为以不同的时间间隔运行，以避免查询同时执行时的流量峰值。

    如果在运行许多并行查询时仍然出现问题，请创建一个支持票据以请求增加查询限制。

    警报和记录规则

    针对大规模方案优化警报和记录规则

    可以将 Prometheus 警报和记录规则定义为 Prometheus 规则组。 一个规则组最多可以包含 20 个警报或记录规则。 最多可为每个工作区创建 500 个规则组，以适应所需的警报/规则数。 若要提升此限额，请提交支持工单

    在定义记录规则时，请考虑评估间隔，以优化每个规则的时序数量和规则评估的性能。 评估间隔介于 1 分钟到 24 小时之间。 默认值为 1 分钟。

    使用资源运行状况查看记录规则状态中的查询

    设置资源运行状况以在门户中查看 Prometheus 规则组的运行状况。 使用资源运行状况可以检测记录规则中的问题，例如配置不正确或查询限制问题。 有关设置资源运行状况的详细信息，请参阅查看 Prometheus 规则组的资源运行状况状态。