对规则评估进行故障排除 - Amazon Managed Service for Prometheus
验证警报触发状态解决缺少警报通知的问题检查规则运行状况在查询中使用偏移量来处理摄取延迟常见问题和解决方案规则评估的最佳实践

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

对规则评估进行故障排除

本指南提供了有关亚马逊 Prometheus 托管服务 (AMP) 中规则评估常见问题的 step-by-step故障排除程序。按照以下步骤诊断和解决警报和记录规则存在的问题。

验证警报触发状态

在对规则评估问题进行故障排除时，首先要通过查询合成时间序列来验证警报是否已触发ALERTS。ALERTS时间序列包括以下标签：

  • 警报名称-警报的名称。

  • 警报状态 — 待处理或触发。

    • pending — 警报正在等待for子句中指定的持续时间。

    • 触发-警报在指定的持续时间内满足条件。其他标签是在您的警报规则中定义的。

注意

当警报触发或待处理时，样本值为 1。当您的警报处于空闲状态时，不会生成任何样本。

解决缺少警报通知的问题

如果警报已触发但通知未到达，请验证以下警报管理器设置：

  1. 验证您的警报管理器配置-检查路由、接收器和设置的配置是否正确。查看路径屏蔽设置，包括等待时间、时间间隔和必填标签，这些设置可能会影响警报触发。将警报规则与其对应的路由和接收器进行比较，以确认匹配是否正确。对于带有的路由time_interval，请验证时间戳是否在指定的间隔内。

  2. 检查提醒接收者的权限 — 使用 Amazon SNS 主题时，请验证 AMP 是否具有发布通知所需的权限。有关更多信息，请参阅 授予 Amazon Managed Service for Prometheus 向 Amazon SNS 主题发送警报消息的权限。

  3. 验证接收器有效载荷兼容性-确认您的警报接收器接受 Alertmanager 的有效载荷格式。有关亚马逊 SNS 的要求，请参阅。了解 Amazon SNS 消息验证规则

  4. 查看警报管理器日志 — AMP 提供警报管理器提供的日志，以帮助调试通知问题。有关更多信息，请参阅 使用日志监控亚马逊托管服务的 Prometheus 事件 CloudWatch 。

有关警报管理器的更多信息，请参阅。使用警报管理器在 Amazon Managed Service for Prometheus 中管理和转发警报

检查规则运行状况

格式错误的规则可能导致评估失败。使用以下方法来确定规则评估失败的原因：

使用 ListRules API

ListRulesAPI 提供有关规则运行状况的信息。选中health和lastError字段以诊断问题。

示例响应：

{
  "status": "success",
  "data": {
    "groups": [
      {
        "name": "my_rule_group",
        "file": "my_namespace",
        "rules": [
          {
            "state": "firing",
            "name": "broken_alerting_rule",
            "query": "...",
            "duration": 0,
            "keepFiringFor": 0,
            "labels": {},
            "annotations": {},
            "alerts": [],
            "health": "err",
            "lastError": "vector contains metrics with the same labelset after applying alert labels",
            "type": "alerting",
            "lastEvaluation": "1970-01-01T00:00:00.00000000Z",
            "evaluationTime": 0.08
          }
        ]
      }
    ]
  }
}

使用已售日志

ListRules API 仅显示最新信息。要了解更详细的历史记录，请在工作区中启用销售日志以访问：

  • 评估失败的时间戳

  • 详细的错误消息

  • 历史评估数据

出售的日志消息示例：

{
  "workspaceId": "ws-a2c55905-e0b4-4065-a310-d83ce597a391",
  "message": {
    "log": "Evaluating rule failed, name=broken_alerting_rule, group=my_rule_group, namespace=my_namespace, err=vector contains metrics with the same labelset after applying alert labels",
    "level": "ERROR",
    "name": "broken_alerting_rule",
    "group": "my_rule_group",
    "namespace": "my_namespace"
  },
  "component": "ruler"
}

有关来自 Ruler 或 Alertmanager 的日志的更多示例，请参阅规则器故障排除和。使用警报管理器在 Amazon Managed Service for Prometheus 中管理和转发警报

在查询中使用偏移量来处理摄取延迟

默认情况下，表达式是在没有偏移量的情况下计算的（即时查询），使用求值时的值。如果指标摄取延迟，则记录规则所代表的值可能与您在摄取所有指标后手动评估表达式时的值不同。

提示

使用 offset 修改器可以减少因摄取延迟而导致的问题。有关更多信息，请参阅 Prometheus 文档中的偏移修饰符。

如果您的规则在 12:00 进行评估，但由于摄取延迟，该指标的最新样本来自 11:45，则该规则将找不到在 12:00 时间戳处的样本。要缓解这种情况，请添加偏移量，例如:my_metric_name offset 15m 。

当指标来自不同的来源（例如两台服务器）时，它们可能会在不同的时间被采集。为了缓解这种情况，请形成一个表达式，例如：metric_from_server_A / metric_from_server_B

如果规则在服务器 A 和服务器 B 的摄取时间之间进行评估，则会得到意想不到的结果。使用偏移量可以帮助调整评估时间。

常见问题和解决方案

记录规则数据存在差距

如果您发现录制规则数据与手动评估相比存在差距（当您通过查询 API 或 UI 直接执行录制规则的原始 PromQL 表达式时），则可能是由于以下原因之一：

  1. 评估时间长-一个规则组不能同时进行多个评估。如果评估时间超过配置的时间间隔，则可能会错过后续评估。超过配置间隔的多次连续错过评估可能会导致录制规则过时。有关更多信息，请参阅 Pro methe us 文档中的 Stal eness。您可以使用 CloudWatch 指标来监控评估持续时间RuleGroupLastEvaluationDuration，以识别评估时间过长的规则组。

  2. 监控错过的评估 — AMP 提供用于跟踪何时跳过评估的RuleGroupIterationsMissed CloudWatch 指标。 ListRules API 显示每个规则/组的评估时间和上次评估时间，这有助于识别错过评估的模式。有关更多信息，请参阅 ListRules。

建议：将规则分成不同的组

要缩短评估持续时间，请将规则拆分为不同的规则组。组内的规则按顺序执行，而规则组可以并行执行。将相互依赖的相关规则保留在同一个组中。通常，较小的规则组可确保更一致的评估和更少的差距。

规则评估的最佳实践

  1. 优化规则组大小-保持规则组较小，以确保评估的一致性。将相关规则分组在一起，但要避免使用大型规则组。

  2. 设置适当的评估间隔-在及时警报和系统负载之间取得平衡。查看监控指标的稳定性模式，了解其正常波动范围。

  3. 对延迟指标使用偏移修饰符-添加偏移量以补偿摄取延迟。根据观察到的摄取模式调整偏移持续时间。

  4. 监控评估绩效-跟踪RuleGroupIterationsMissed指标。在 ListRules API 中查看评估时间。

  5. 验证规则表达式-确保规则定义和手动查询之间的表达式完全匹配。测试具有不同时间范围的表达式以了解行为。

  6. 定期查看规则运行状况-检查规则评估中是否存在错误。监控已售日志，了解反复出现的问题。

通过遵循这些故障排除步骤和最佳实践，您可以识别和解决适用于 Prometheus 的亚马逊托管服务中规则评估的常见问题。