

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 對規則評估進行故障診斷
<a name="troubleshoot-rule-evaluations"></a>

本指南提供 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)

## 驗證警示觸發狀態
<a name="troubleshoot-rule-validate-firing-status"></a>

疑難排解規則評估問題時，請先查詢合成時間序列 來驗證您的提醒是否已觸發`ALERTS`。`ALERTS` 時間序列包含下列標籤：
+ **alertname** – 提醒的名稱。
+ **alertstate** – **待定**或**觸發**。
  + **擱置**中 – 提醒正在等待 `for`子句中指定的持續時間。
  + **觸發** – 警示在指定的持續時間內符合條件。警示規則中會定義其他標籤。

**注意**  
當警示**觸發**或**擱置**時，範例值為 **1**。當您的提醒閒置時，不會產生任何範例。

## 解決遺漏的提醒通知
<a name="troubleshoot-rule-missing-alert-notifications"></a>

如果警示已觸發，但通知未送達，請確認下列 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)。

## 檢查規則運作狀態
<a name="troubleshoot-rule-check-health-status"></a>

格式不正確的規則可能會導致評估失敗。使用下列方法來識別規則無法評估的原因：

**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)。

## 在查詢中使用位移來處理擷取延遲
<a name="troubleshoot-rule-offset-queries"></a>

根據預設，運算式的評估時不會偏移 （即時查詢），在評估時間使用值。如果指標擷取延遲，則記錄規則可能不會代表與擷取所有指標後手動評估表達式時相同的值。

**提示**  
使用位移修飾詞可以減少擷取延遲所造成的問題。如需詳細資訊，請參閱 *Prometheus 文件*中的[位移修飾詞](https://prometheus.io/docs/prometheus/latest/querying/basics/#offset-modifier)。

### 範例：處理延遲指標
<a name="example-delayed-metrics"></a>

如果您的規則在 12：00 評估，但指標的最新範例是由於擷取延遲而從 11：45 開始，則規則在 12：00 時間戳記時將找不到任何範例。若要緩解此問題，請新增位移，例如：**my\$1metric\$1name offset 15m **。

### 範例：處理來自多個來源的指標
<a name="example-metrics-multiple-sources"></a>

當指標來自不同的來源時，例如兩個伺服器，它們可能會在不同的時間被擷取。若要緩解這種情況，請形成表達式，例如： **metric\$1from\$1server\$1A / metric\$1from\$1server\$1B **

如果規則評估伺服器 A 和伺服器 B 的擷取時間，您會收到非預期的結果。使用位移有助於調整評估時間。

## 常見問題與解決方案
<a name="troubleshoot-rule-common-issues"></a>

**記錄規則資料中的差距**

如果您發現記錄規則資料與手動評估相比有差距 （當您透過查詢 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)。

**建議：將規則分割為不同的群組**

若要減少評估持續時間，請將規則分割為不同的規則群組。群組內的規則會依序執行，而規則群組可以平行執行。在相同群組中保留彼此相依的相關規則。一般而言，較小的規則群組可確保更一致的評估和較少的差距。

## 規則評估的最佳實務
<a name="troubleshoot-rule-best-practices"></a>

1. **最佳化規則群組大小** – 將規則群組保持較小，以確保評估一致。將相關規則分組在一起，但避免大型規則群組。

1. **設定適當的評估間隔** – 在及時警示和系統負載之間取得平衡。檢閱受監控指標的穩定性模式，以了解其正常波動範圍。

1. **針對延遲指標使用位移修飾詞** – 新增位移以補償擷取延遲。根據觀察到的擷取模式調整位移持續時間。

1. **監控評估效能** – `RuleGroupIterationsMissed` 追蹤指標。在 ListRules API 中檢閱評估時間。

1. **驗證規則表達式** – 確保表達式完全符合規則定義和手動查詢。使用不同的時間範圍測試表達式，以了解行為。

1. **定期檢閱規則運作**狀態 – 檢查規則評估中的錯誤。監控付費日誌是否有經常性問題。

透過遵循這些疑難排解步驟和最佳實務，您可以在 Amazon Managed Service for Prometheus 中識別和解決規則評估的常見問題。