本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 使用規則來修改或監控收到指標時的指標 您可以設定規則，在 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 說明文件中的[定義記錄規則](https://prometheus.io/docs/prometheus/latest/configuration/recording_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* 文件中的[定義錄製規則](https://prometheus.io/docs/prometheus/latest/configuration/recording_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" ``` 此範例會建立每 60 秒評估一次`cpu_metrics`的規則群組。此規則群組會使用稱為 的錄製規則建立新的指標，`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)` – 錄製規則的此表達式會計算每個節點過去 5 分鐘內 CPU 使用率的平均速率，並依`instance`標籤分組。 + `alert: HighAverageCPU` – 此提醒規則會建立新的提醒，稱為 `HighAverageCPU` + `expr: avg_cpu_usage > 0.8 ` – 此表達式會通知 警示尋找平均 CPU 用量超過 80% 的範例。 + `for: 10m` – 只有在平均 CPU 用量超過 80% 至少 10 分鐘時，警示才會觸發。 在此情況下，指標計算為過去 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. 開啟 Amazon Managed Service for 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. 輸入以下其中一個命令，建立命名空間並上傳檔案。 在第 2 AWS CLI 版上，輸入： ``` aws amp create-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 在第 1 AWS CLI 版上，輸入： ``` 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. 開啟 Amazon Managed Service for 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. 輸入以下其中一個命令以上傳新檔案。 在第 2 AWS CLI 版上，輸入： ``` aws amp put-rule-groups-namespace --data file://path_to_base_64_output_file --name namespace-name --workspace-id my-workspace-id --region region ``` 在第 1 AWS CLI 版上，輸入： ``` 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`，則表示您的規則檔案已生效。在此之前，此規則檔案的以前版本仍為啟用中。 # 對規則評估進行故障診斷 本指南提供 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` 時間序列包含下列標籤： + **alertname** – 提醒的名稱。 + **alertstate** – **待定**或**觸發**。 + **擱置**中 – 提醒正在等待 `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 的付費日誌，以協助偵錯通知問題。如需詳細資訊，請參閱[使用 CloudWatch Logs 監控 Amazon Managed Service for Prometheus 事件](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 文件*中的[過時](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 中識別和解決規則評估的常見問題。 # 尺規疑難排解 使用 [使用 CloudWatch Logs 監控 Amazon Managed Service for Prometheus 事件](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" } ``` 這表示執行規則時發生一些錯誤。 **採取動作** 使用錯誤訊息疑難排解規則執行。