アラート発射ステータスを検証する欠落しているアラート通知を解決するルールのヘルスステータスを確認するクエリでオフセットを使用して取り込みの遅延を処理する一般的なの問題と解決策ルール評価のベストプラクティス

ルール評価のトラブルシューティング

このガイドでは、Amazon Managed Service for Prometheus (AMP) のルール評価に関する一般的な問題のトラブルシューティング手順をstep-by-stepで説明します。以下の手順に従って、アラートルールと記録ルールの問題を診断して解決します。

トピック

アラート発射ステータスを検証する
欠落しているアラート通知を解決する
ルールのヘルスステータスを確認する
クエリでオフセットを使用して取り込みの遅延を処理する
一般的なの問題と解決策
ルール評価のベストプラクティス

アラート発射ステータスを検証する

ルール評価の問題をトラブルシューティングするときは、まず合成時系列をクエリしてアラートが発生したかどうかを確認しますALERTS。ALERTS 時系列には、次のラベルが含まれます。

alertname – アラートの名前。
alertstate – 保留中または発射中。
- 保留中 – アラートは for句で指定された期間待機しています。
- 射撃 — アラートが指定された期間、条件を満たしています。追加のラベルはアラートルールで定義されます。

注記

アラートが発射中または保留中の場合、サンプル値は 1 です。アラートがアイドル状態の場合、サンプルは生成されません。

欠落しているアラート通知を解決する

アラートが発生していても通知が届かない場合は、次のアラートマネージャー設定を確認します。

アラートマネージャーの設定を確認する – ルートレシーバーと設定が正しく設定されていることを確認します。アラートの発射に影響を与える可能性のある待機時間、時間間隔、必要なラベルなどのルートブロック設定を確認します。アラートルールと対応するルートとレシーバーを比較して、適切な一致を確認します。を持つルートの場合time_interval、タイムスタンプが指定された間隔内にあることを確認します。
アラートレシーバーのアクセス許可を確認する – Amazon SNS トピックを使用する場合は、AMP が通知を発行するために必要なアクセス許可を持っていることを確認します。詳細については、「Amazon SNS トピックにアラートメッセージを送信するためのアクセス許可を Amazon Managed Service for Prometheus に付与する」を参照してください。
レシーバーペイロードの互換性を検証する – アラートレシーバーがアラートマネージャーのペイロード形式を受け入れていることを確認します。Amazon SNS の要件については、「」を参照してくださいAmazon SNS メッセージ検証ルールを理解する。
アラートマネージャーログの確認 – AMP はアラートマネージャーから提供されたログを提供し、通知問題のデバッグに役立ちます。詳細については、「CloudWatch Logs で Amazon Managed Service for Prometheus イベントをモニタリングする」を参照してください。

アラートマネージャーの詳細については、「」を参照してくださいアラートマネージャーを使用して Amazon Managed Service for Prometheus でアラートを管理および転送する。

ルールのヘルスステータスを確認する

ルールの形式が正しくないと、評価が失敗する可能性があります。ルールが評価に失敗した理由を特定するには、次の方法を使用します。

ListRules API を使用する

ListRules 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
          }
        ]
      }
    ]
  }
}

提供されたログを使用する

ListRules API には、最新の情報のみが表示されます。より詳細な履歴については、ワークスペースで販売ログを有効にして以下にアクセスします。

評価失敗のタイムスタンプ
詳細なエラーメッセージ
履歴評価データ

提供されたログメッセージの例：


{
  "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 またはアラートマネージャーからのログのその他の例については、ルーラーのトラブルシューティング「」および「」を参照してくださいアラートマネージャーを使用して Amazon Managed Service for Prometheus でアラートを管理および転送する。

クエリでオフセットを使用して取り込みの遅延を処理する

デフォルトでは、式は、評価時に値を使用してオフセットなし (インスタントクエリ) で評価されます。メトリクスの取り込みが遅れた場合、記録ルールは、すべてのメトリクスが取り込まれた後に式を手動で評価する場合と同じ値を表さない場合があります。

ヒント

オフセット修飾子を使用すると、取り込みの遅延による問題を減らすことができます。詳細については、Prometheus ドキュメントの「オフセット修飾子」を参照してください。

ルールが 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 式を直接実行した場合）、次のいずれかが原因である可能性があります。

長い評価時間 – ルールグループは複数の同時評価を持つことはできません。評価時間が設定された間隔を超えると、後続の評価が失われる可能性があります。設定された間隔を超える複数の連続した評価の欠落により、記録ルールが古くなる可能性があります。詳細については、Prometheus ドキュメントの「古さ」を参照してください。CloudWatch メトリクスを使用して評価期間をモニタリングRuleGroupLastEvaluationDurationし、評価に時間がかかりすぎているルールグループを特定できます。
欠落した評価のモニタリング – AMP は、評価がスキップされるタイミングを追跡するための RuleGroupIterationsMissed CloudWatch メトリクスを提供します。ListRules API には、各ルール/グループの評価時刻と最終評価時刻が表示されます。これにより、見逃した評価のパターンを特定できます。詳細については、「ListRules」を参照してください。

推奨事項: ルールを別々のグループに分割する

評価期間を短縮するには、ルールを別々のルールグループに分割します。グループ内のルールは順番に実行されますが、ルールグループは並行して実行できます。相互に依存する関連ルールを同じグループに保持します。一般的に、ルールグループを小さくすると、評価の一貫性が向上し、ギャップが少なくなります。

ルール評価のベストプラクティス

ルールグループサイズの最適化 – ルールグループを小さくして、一貫した評価を確保します。関連するルールをグループ化しますが、大きなルールグループは避けます。
適切な評価間隔を設定する – タイムリーなアラートとシステム負荷のバランスをとります。モニタリング対象のメトリクスの安定性パターンを確認して、通常の変動範囲を理解します。
遅延メトリクスにオフセット修飾子を使用する – 取り込みの遅延を補正するオフセットを追加します。観測された取り込みパターンに基づいてオフセット期間を調整します。
評価パフォーマンスのモニタリング – RuleGroupIterationsMissedメトリクスを追跡します。ListRules API で評価時間を確認します。
ルール式の検証 – ルール定義と手動クエリの間で式が完全に一致することを確認します。さまざまな時間範囲で式をテストして動作を理解します。
ルールのヘルスを定期的に確認する – ルール評価でエラーがないか確認します。定期的な問題がないか、販売ログをモニタリングします。

これらのトラブルシューティング手順とベストプラクティスに従うことで、Amazon Managed Service for Prometheus のルール評価に関する一般的な問題を特定して解決できます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ルールファイルを編集する

ルーラーのトラブルシューティング