翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ルール評価のトラブルシューティング
このガイドでは、Amazon Managed Service for Prometheus (AMP) のルール評価に関する一般的な問題のトラブルシューティング手順をステップバイステップで説明します。アラートルールと記録ルールの問題を診断して解決するには、次の手順に従います。
**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** – **[保留中]** または **[実行中]**。
+ **pending** – アラートは `for` 句で指定された期間待機しています。
+ **firing** — アラートが指定された期間、条件を満たしています。追加のラベルはアラートルールで定義されます。
**注記**
アラートが **[実行中]** または **[保留中]** の場合、サンプル値は **[1]** です。アラートがアイドル状態の場合、サンプルは生成されません。
## 欠落しているアラート通知を解決する
アラートが実行中でも通知が届かない場合は、次のアラートマネージャー設定を確認します。
1. **アラートマネージャーの設定を確認する** – ルートレシーバーと設定が正しく設定されていることを確認します。アラートの実行に影響を与える可能性のある待機時間、時間間隔、必要なラベルなどのルートブロック設定を確認します。アラートルールと対応するルートとレシーバーを比較して、適切な一致を確認します。`time_interval` を持つルートの場合、タイムスタンプが指定された間隔内にあることを確認します。
1. **アラートレシーバーのアクセス許可を確認する** – Amazon SNS トピックを使用する場合は、AMP が通知を発行するために必要なアクセス許可を持っていることを確認します。詳細については、「[Amazon SNS トピックにアラートメッセージを送信するためのアクセス許可を Amazon Managed Service for Prometheus に付与する](AMP-alertmanager-receiver-AMPpermission.md)」を参照してください。
1. **レシーバーペイロードの互換性を検証する** – アラートレシーバーがアラートマネージャーのペイロード形式を受け入れていることを確認します。Amazon SNS の要件については、「[Amazon SNS メッセージ検証ルールを理解する](AMP-alertmanager-receiver-validation-truncation.md)」を参照してください。
1. **アラートマネージャーログの確認** – AMP はアラートマネージャーから公開ログを提供し、通知問題のデバッグに役立ちます。詳細については、「[CloudWatch Logs で Amazon Managed Service for Prometheus イベントをモニタリングする](CW-logs.md)」を参照してください。
アラートマネージャーの詳細については、「[アラートマネージャーを使用して 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"
}
```
ルーラーまたはアラートマネージャーからのログのその他の例については、「[ルーラーのトラブルシューティング](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\_metric\_name offset 15m ** などのオフセットを追加します。
### 例: 複数のソースからのメトリクスを処理する
メトリクスが、2 つのサーバーなど異なるソースから生成される場合、メトリクスは異なる時間に取り込まれる可能性があります。これを軽減するには、**metric\_from\_server\_A / metric\_from\_server\_B ** のような式を形成します。
ルールがサーバー 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 のルール評価に関する一般的な問題を特定して解決できます。