使用英语阅读

通过

使用适用于 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 工作区限制和配额的最佳做法：

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

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

    针对大量数据，优化性能

    引流

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

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

    例如，请考虑如下事项：

  • 优化抓取间隔。
    • 默认抓取频率为 30 秒，可以使用 configmap 根据默认目标更改此频率。 若要平衡数据粒度和资源使用状况之间的权衡关系，请根据指标的关键性调整 scrape_interval 和 scrape_timeout。
  • 为高基数指标删除不必要的标签。
    • 对于高基数指标，请识别不必要的标签并删除这些标签以减少时序数量。 使用 metric_relabel_configs 从引入中删除特定标签。 有关更多信息，请参阅 Prometheus 配置。

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

    查询

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

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

    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

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

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

    在查询中使用筛选器

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

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

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

    例如，不要使用 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 服务器的稳定性。 若要高效处理大量并行查询，请遵循以下最佳做法：

    最佳做法 说明
    查询负载分布。 通过将查询分散到不同的时间间隔或 Prometheus 实例来分配查询负载。
    交错查询。 以不同的间隔运行计划查询，以避免同时执行查询导致出现峰值。

    如果仍然发现运行许多并行查询时出现问题，请创建支持工单以请​​求增加查询限制。

    警报和记录规则

    优化警报和记录规则以实现大规模查询

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

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