本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 对规则评估进行故障排除
本指南提供了有关亚马逊 Prometheus 托管服务 (AMP) 中规则评估常见问题的 step-by-step故障排除程序。按照下列过程来诊断和解决警报和记录规则问题。
**Topics**
+ [验证警报触发状态](#troubleshoot-rule-validate-firing-status)
+ [解决警报通知缺失](#troubleshoot-rule-missing-alert-notifications)
+ [检查规则运行状况](#troubleshoot-rule-check-health-status)
+ [在查询中使用偏移量来处理摄取延迟](#troubleshoot-rule-offset-queries)
+ [常见问题和解决方案](#troubleshoot-rule-common-issues)
+ [规则评估的最佳实践](#troubleshoot-rule-best-practices)
## 验证警报触发状态
在对规则评估问题进行故障排除时，首先要通过查询合成时间序列 `ALERTS` 来验证警报是否已触发。`ALERTS` 时间序列包括以下标签：
+ **警报名称**：警报的名称。
+ **警报状态**：**待处理**或**触发**。
+ **待处理**：警报正在等待在 `for` 子句中指定的持续时间。
+ **触发**：警报在指定的持续时间内满足条件。其他标签在您的警报规则中定义。
**注意**
当警报为**触发**或**待处理**时，样本值为 **1**。当警报处于空闲状态时，不会生成任何样本。
## 解决警报通知缺失
如果警报已触发但通知未到达，请验证以下 Alertmanager 设置：
1. **验证 Alertmanager 配置**：检查路由、接收器和设置是否配置正确。查看路径屏蔽设置，包括等待时间、时间间隔和所需标签，这些设置可能会影响警报触发。将警报规则与其对应的路由和接收器进行比较，以确认匹配是否正确。对于带有 `time_interval` 的路由，请验证时间戳是否在指定的间隔内。
1. **检查警报接收器权限**：使用 Amazon SNS 主题时，请验证 AMP 是否具有发布通知所需的权限。有关更多信息，请参阅 [授予 Amazon Managed Service for Prometheus 向 Amazon SNS 主题发送警报消息的权限](AMP-alertmanager-receiver-AMPpermission.md)。
1. **验证接收器有效载荷兼容性**：确认警报接收器接受 Alertmanager 的有效载荷格式。有关 Amazon SNS 要求，请参阅[了解 Amazon SNS 消息验证规则](AMP-alertmanager-receiver-validation-truncation.md)。
1. **查看 Alertmanager 日志**：AMP 提供 Alertmanager 中的已出售日志，以协助调试通知问题。有关更多信息，请参阅 [使用日志监控亚马逊托管服务 Prometheus 事件 CloudWatch](CW-logs.md)。
有关 Alertmanager 的更多信息，请参阅[使用警报管理器在 Amazon Managed Service for Prometheus 中管理和转发警报](AMP-alert-manager.md)。
## 检查规则运行状况
格式错误的规则可能导致评估失败。使用以下方法来确定规则评估失败的原因：
**Example**
**使用 ListRules API**
[ListRules](AMP-APIReference-ListRules.md) API 提供有关规则运行状况的信息。检查 `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
}
]
}
]
}
}
```
**Example**
**使用已出售日志**
ListRules API 仅显示最新信息。有关更详细的历史记录，请在工作区中启用[已出售日志](CW-logs.md)以访问：
+ 评估失败的时间戳
+ 详细错误消息
+ 历史评估数据
**已出售日志消息示例：**
```
{
"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 的日志的更多示例，请参阅[规则器故障排除](Troubleshooting-rule-fail-error.md)和[使用警报管理器在 Amazon Managed Service for Prometheus 中管理和转发警报](AMP-alert-manager.md)。
## 在查询中使用偏移量来处理摄取延迟
默认情况下，表达式是在没有偏移量（即时查询）的情况下使用评估时的值进行评估的。如果指标摄取延迟，则记录规则所代表的值可能与您在摄取所有指标后手动评估表达式时的值不同。
**提示**
使用偏移量修改器可以减少因摄取延迟而导致的问题。有关更多信息，请参阅《Prometheus 文档》**中的[偏移量修改器](https://prometheus.io/docs/prometheus/latest/querying/basics/#offset-modifier)。
### 示例：处理延迟的指标
如果规则在 12:00 进行评估，但由于摄取延迟，该指标的最新样本来自 11:45，则该规则将找不到在 12:00 时间戳处的样本。要减轻这一影响，请添加偏移量，例如：**my\$1metric\$1name offset 15m **。
### 示例：处理来自多个来源的指标
当指标源自不同的来源（例如两台服务器）时，系统可能会在不同的时间摄取这些指标。为减轻这一影响，请构建一个表达式，例如：**metric\$1from\$1server\$1A / metric\$1from\$1server\$1B **
如果规则在服务器 A 和服务器 B 的摄取时间之间进行评估，您将得到预期之外的结果。使用偏移量有助于使评估时间保持一致。
## 常见问题和解决方案
**记录规则数据存在差距**
如果您发现记录规则数据与手动评估（当您通过查询 API 或 UI 直接执行记录规则的原始 PromQL 表达式时）相比存在差距，则可能是由于以下原因之一：
1. **评估时间长**：一个规则组不能同时进行多个评估。如果评估时间超过配置的间隔，则可能会错过后续评估。超过所配置间隔的多次连续错过评估可能会导致记录规则变得过时。有关更多信息，请参阅《Prometheus 文档》**中的 [Staleness](https://prometheus.io/docs/prometheus/latest/querying/basics/#staleness)。您可以使用 CloudWatch 指标来监控评估持续时间`RuleGroupLastEvaluationDuration`，以识别评估时间过长的规则组。
1. **监控错过的评估** — AMP 提供用于跟踪何时跳过评估的`RuleGroupIterationsMissed` CloudWatch 指标。 ListRules API 显示每个规则/组的评估时间和上次评估时间，这有助于识别错过评估的模式。有关更多信息，请参阅 [ListRules](AMP-APIReference-ListRules.md)。
**建议：将规则拆分为不同的组**
要缩短评估持续时间，请将规则拆分为不同的规则组。组内的规则按顺序执行，而规则组可以并行执行。将相互依赖的相关规则保留在同一个组中。通常，较小的规则组可确保评估更一致和差距更少。
## 规则评估的最佳实践
1. **优化规则组大小**：使规则组保持较小，以确保评估一致性。将相关的规则分组在一起，但避免使用大的规则组。
1. **设置适当的评估间隔**：在及时警报与系统负载之间取得平衡。查看受监控指标的稳定性模式，以了解其正常波动范围。
1. **对延迟的指标使用偏移量修改器**：添加偏移量以补偿摄取延迟。根据观测到的摄取模式调整偏移量持续时间。
1. **监控评估性能**：跟踪 `RuleGroupIterationsMissed` 指标。在 ListRules API 中查看评估时间。
1. **验证规则表达式**：确保规则定义和手动查询之间的表达式完全匹配。测试具有不同时间范围的表达式以了解行为。
1. **定期查看规则运行状况**：检查规则评估中是否存在错误。监控已出售日志，以了解反复出现的问题。
通过遵循这些故障排除步骤和最佳实践，您可以识别和解决 Amazon Managed Service for Prometheus 中规则评估的常见问题。