本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 使用规则修改或监控收到的指标 您可以设置规则，以便在 Amazon Managed Service for Prometheus 收到指标时对指标采取操作。这些规则可以监控指标，甚至可以根据收到的指标创建新的计算指标。 Amazon Managed Service for Prometheus 支持两种类型的*规则*，并定期对其进行评估： + *记录规则*让您可以预先计算经常需要或计算成本高昂的表达式，并将其结果另存为一组新的时间序列。相比于每次需要时都运行原始表达式，查询预先计算的结果通常快得多。 + *警报规则*让您可以根据 PromQL 和阈值定义警报条件。当规则触发阈值时，会向[警报管理器](AMP-alert-manager.md)发送通知，警报管理器可配置为管理规则，或将其转发给通知下游接收器，如 Amazon Simple Notification Service。 要在 Amazon Managed Service for Prometheus 中使用规则，您需要创建一个或多个 YAML 规则文件来定义规则。Amazon Managed Service for Prometheus 规则文件的格式与独立 Prometheus 中的规则文件格式相同。有关更多信息，请参阅 Prometheus 文档中的 [Defining Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) 和 [Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)。 一个工作区中可以有多个规则文件。每个单独的规则文件都包含在单独的*命名空间*中。有了多个规则文件，您便可以将现有 Prometheus 规则文件导入工作区，而无需对其进行更改或合并。不同的规则组命名空间也可以有不同的标签。 **规则排序** 在规则文件中，规则包含在*规则组*中。规则文件中单个规则组中的规则始终按从上到下的顺序进行评估。因此，在记录规则中，一条记录规则的结果可以用于计算以后的记录规则，也可以用于同一规则组中的警报规则。但是，由于您无法指定运行单独规则文件的顺序，因此不能使用一条记录规则的结果来计算其他规则组或其他规则文件中的规则。 **Topics** + [了解使用规则所需的 IAM 权限](AMP-ruler-IAM-permissions.md) + [创建规则文件](AMP-ruler-rulesfile.md) + [将规则配置文件上传到 Amazon Managed Service for Prometheus](AMP-rules-upload.md) + [编辑或替换规则配置文件](AMP-rules-edit.md) + [对规则评估进行故障排除](troubleshoot-rule-evaluations.md) + [规则器故障排除](Troubleshooting-rule-fail-error.md) # 了解使用规则所需的 IAM 权限 必须向用户授予使用 Amazon Managed Service for Prometheus 中规则的权限。创建具有以下权限的 AWS Identity and Access Management (IAM) 策略，并将该策略分配给您的用户、群组或角色。 **注意** 有关 IAM 的更多信息，请参阅。[Amazon Managed Service for Prometheus 的身份和访问管理](security-iam.md) **授权用户使用规则的策略** 以下策略授权使用账户中所有资源的规则。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aps:CreateRuleGroupsNamespace", "aps:ListRuleGroupsNamespaces", "aps:DescribeRuleGroupsNamespace", "aps:PutRuleGroupsNamespace", "aps:DeleteRuleGroupsNamespace" ], "Resource": "*" } ] } ``` ------ **仅授予一个命名空间访问权限的策略** 您也可以创建仅允许访问特定策略的策略。以下示例策略仅授予对指定的 `RuleGroupNamespace` 的访问权限。要使用此政策，请将**、****、和，替换为**与您的账户对应的值。 # 创建规则文件 要在 Amazon Managed Service for Prometheus 中使用规则，您需要创建一个规则文件来定义规则。Amazon Managed Service for Prometheus 规则文件是一个 YAML 文本文件，其格式与独立 Prometheus 中的规则文件相同。有关更多信息，请参阅 *Prometheus* 文档中的 [Defining Recording rules](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/) 和 [Alerting rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)。 以下是规则文件的基本示例： ``` groups: - name: cpu_metrics interval: 60s rules: - record: avg_cpu_usage expr: avg(rate(node_cpu_seconds_total[5m])) by (instance) - alert: HighAverageCPU expr: avg_cpu_usage > 0.8 for: 10m keep_firing_for: 20m labels: severity: critical annotations: summary: "Average CPU usage across cluster is too high" ``` 此示例创建了规则组 `cpu_metrics`，该组每 60 秒评估一次。此规则组使用记录规则创建一个名为 `avg_cpu_usage` 的新指标，然后在警报中使用该指标。下面描述一些使用的属性。有关警报规则和可包含的其他属性的更多信息，请参阅 *Prometheus* 文档中的[警报规则](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/)。 + `record: avg_cpu_usage` – 此记录规则创建一个名为 `avg_cpu_usage` 的新指标。 + 如果未指定 `interval` 属性，则规则组的默认评估间隔为 60 秒。 + `expr: avg(rate(node_cpu_seconds_total[5m])) by (instance)` – 记录规则的此表达式按 `instance` 标签分组，计算每个节点过去 5 分钟 CPU 的平均使用率。 + `alert: HighAverageCPU` – 此警报规则创建一个名为 `HighAverageCPU` 的新警报 + `expr: avg_cpu_usage > 0.8 ` – 此表达式要求警报查找 CPU 平均使用率超过 80% 的样本。 + `for: 10m`：只有当平均 CPU 使用率在至少 10 分钟内超过 80% 时，才会触发警报。 在这种情况下，该指标的计算值为过去 5 分钟的平均值。因此，只有当至少有两个连续的 5 分钟样本（总计 10 分钟）且其中平均 CPU 使用率高于 80% 时，才会触发警报。 + `keep_firing_for: 20m` – 此警报将继续触发，直到样本低于阈值至少 20 分钟。这对避免警报连续反复升降很有帮助。 **注意** 您可以在本地创建规则定义文件，然后将其上传到 Amazon Managed Service for Prometheus，也可以直接在 Amazon Managed Service for Prometheus 控制台中创建、编辑和上传定义。无论哪种方式，都适用相同的格式规则。要了解有关上传和编辑文件的更多信息，请参阅[将规则配置文件上传到 Amazon Managed Service for Prometheus](AMP-rules-upload.md)。 # 将规则配置文件上传到 Amazon Managed Service for Prometheus 一旦您知道规则配置文件中需要哪些规则，就可以在控制台中创建和编辑该文件，也可以使用控制台或 AWS CLI上传文件。 **注意** 如果您运行的是 Amazon EKS 集群，还可以使用 [AWS Controllers for Kubernetes](integrating-ack.md) 上传规则配置文件。 **使用 Amazon Managed Service for Prometheus 控制台编辑或替换规则配置并创建命名空间** 1. 打开适用于 Prometheus 的亚马逊托管服务控制台，网址为。[https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home) 1. 在页面左上角，选择菜单图标，然后选择**所有工作区**。 1. 选择工作区的工作区 ID，然后选择**规则管理**选项卡。 1. 选择**添加命名空间**。 1. 选择**选择文件**，然后选择规则定义文件。 或者，您也可以直接在 Amazon Managed Service for Prometheus 控制台中创建和编辑规则定义文件，方法是选择**定义配置**。这将创建一个默认定义文件样本，您可以在上传前对其进行编辑。 1. （可选）要向命名空间添加标签，请选择**添加新标签**。 然后，对于 **Key**（键），输入标签的名称。您可以在 **Value** (值) 中添加可选的标签值。 要添加其他标签，**添加新标签**。 1. 选择**继续**。Amazon Managed Service for Prometheus 会创建一个与您选择的规则文件同名的新命名空间。 **使用将警报管理器配置上传 AWS CLI 到新命名空间中的工作区** 1. Base64 对警报管理器文件的内容进行编码。在 Linux 系统上，您可以使用以下命令： ``` base64 input-file output-file ``` 在 macOS 系统上，您可以使用以下命令： ``` openssl base64 input-file output-file ``` 1. 输入以下命令之一即可创建命名空间并上传文件。 在 AWS CLI 版本 2 上，输入： ``` aws amp create-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 在 AWS CLI 版本 1 上，输入： ``` aws amp create-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 1. 您的警报管理器配置需要几秒钟才能生效。要检查状态，请输入以下命令： ``` aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region ``` 如果 `status` 是 `ACTIVE`，则您的规则文件已生效。 # 编辑或替换规则配置文件 如果要更改已经上传到 Amazon Managed Service for Prometheus 的规则文件中的规则，可以上传一个新的规则文件来替换现有配置，也可以直接在控制台中编辑当前配置。或者，您可以下载当前文件，在文本编辑器中对其进行编辑，然后上传新版本。 **使用 Amazon Managed Service for Prometheus 控制台编辑您的规则配置** 1. 打开适用于 Prometheus 的亚马逊托管服务控制台，网址为。[https://console.aws.amazon.com/prometheus/](https://console.aws.amazon.com/prometheus/home) 1. 在页面左上角，选择菜单图标，然后选择**所有工作区**。 1. 选择工作区的工作区 ID，然后选择**规则管理**选项卡。 1. 选择要编辑的规则配置文件的名称。 1. （可选）如果要下载当前的规则配置文件，请选择**下载**或**复制**。 1. 选择**修改**可直接在控制台内编辑配置。完成后选择**保存**。 或者，您可以选择**替换配置**来上传新的配置文件。如果是这样选择，请选择新的规则定义文件，然后选择**继续**上传文件。 **AWS CLI 使用编辑规则配置文件** 1. Base64 对规则文件的内容进行编码。在 Linux 系统上，您可以使用以下命令： ``` base64 input-file output-file ``` 在 macOS 系统上，您可以使用以下命令： ``` openssl base64 input-file output-file ``` 1. 输入下列命令之一即可上传新文件。 在 AWS CLI 版本 2 上，输入： ``` aws amp put-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 在 AWS CLI 版本 1 上，输入： ``` aws amp put-rule-groups-namespace --data fileb://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 1. 您的规则文件需要几秒钟才能生效。要检查状态，请输入以下命令： ``` aws amp describe-rule-groups-namespace --workspace-id workspace_id --name namespace-name --region region ``` 如果 `status` 是 `ACTIVE`，则您的规则文件已生效。在此之前，此规则文件的先前版本仍处于活动状态。 # 对规则评估进行故障排除 本指南提供了有关亚马逊 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 中规则评估的常见问题。 # 规则器故障排除 使用 [使用日志监控亚马逊托管服务 Prometheus 事件 CloudWatch](CW-logs.md)，您可以对警报管理器和规则器相关问题进行故障排除。本部分包含与规则器相关的故障排除主题。 ** **当日志包含以下规则器失败错误时** ``` { "workspaceId": "ws-12345c67-89c0-4d12-345b-f14db70f7a99", "message": { "log": "Evaluating rule failed, name=failure, group=canary_long_running_vl_namespace, namespace=canary_long_running_vl_namespace, err=found duplicate series for the match group {dimension1=\\\"1\\\"} on the right hand-side of the operation: [{__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"b\\\"}, {__name__=\\\"fake_metric2\\\", dimension1=\\\"1\\\", dimension2=\\\"a\\\"}];many-to-many matching not allowed: matching labels must be unique on one side", "level": "ERROR", "name": "failure", "group": "canary_long_running_vl_namespace", "namespace": "canary_long_running_vl_namespace" }, "component": "ruler" } ``` 这意味着在执行规则时出现了一些错误。 **要采取的操作** 使用错误消息对规则执行进行故障排除。