セルフデプロイ コレクションによるルールとアラートの評価

このドキュメントでは、セルフデプロイ コレクションを使用する Managed Service for Prometheus のデプロイでのルールとアラートの評価の構成について説明します。

次の図は、2 つの Google Cloud プロジェクトで複数のクラスタを使用し、ルールとアラートの評価の両方を使用するデプロイメントを示しています。

セルフデプロイ コレクションを使用するルールとアラートの評価のデプロイメント。

図に示すようなデプロイメントを設定して使用する場合は、次のことに注意してください。

  • 標準の Prometheus を使用する場合と同様に、ルールは各 Managed Service for Prometheus コレクション サーバーにインストールされます。ルールの評価は、各サーバーに保存されているデータに対して実行されます。すべてのルールのルックバック期間(通常は 1 時間以内)に十分なデータ保持期間が構成されています。ルールの結果は、評価されてから Monarch に書き込まれます。

  • Prometheus AlertManager インスタンスは、すべての単一クラスタに手動でデプロイされます。Prometheus サーバーは、アラートルールをローカルの AlertManager インスタンスに送信するように構成ファイルの alertmanager_config フィールドを編集することで構成されます。通常、ミュート、確認応答、インシデント管理の各ワークフローは、PagerDuty などのサードパーティ ツールで処理されます。

    Kubernetes Endpoints リソースを使用すると、複数のクラスタにわたるアラート管理を単一の AlertManager に一元化できます。

  • Google Cloud 内で実行されている 1 つのクラスタが、指標スコープのグローバル ルール評価クラスタとして指定されます。スタンドアロンのルール エバリュエータがそのクラスタにデプロイされ、ルールが標準の Prometheus ルールファイル形式を使用してインストールされます。

    スタンドアロンのルール エバリュエータは、プロジェクト 1 とプロジェクト 2 を含む scoping_project_A を使用するように構成されます。scoping_project_A に対して実行されたルールは、プロジェクト 1 とプロジェクト 2 に自動的にファンアウトされます。基盤となるサービス アカウントには、scoping_project_A の Monitoring 閲覧者の権限が付与されている必要があります。

    構成ファイルの alertmanager_config フィールドを使用して、ローカルの Prometheus Alertmanager にアラートを送信するようにルール エバリュエータを構成します。

セルフデプロイ グローバル ルール エバリュエータを使用すると、ユーザーのルールで project_idlocationclusternamespace ラベルを保持または集計するかどうかによって、予期しない結果が生じることがあります。

  • ルールで(by(project_id) 句を使用して)project_id ラベルが保持されている場合、ルール結果は基盤となる時系列の元の project_id 値を使用して Monarch に書き戻されます。

    このシナリオでは、scoping_project_A のモニタリング対象プロジェクトごとに、基盤となるサービス アカウントに Monitoring 指標ライター権限があることを確認する必要があります。また、新しいモニタリング対象プロジェクトを scoping_project_A に追加する場合は、新しい権限をサービス アカウントに手動で追加する必要があります。

  • ルールで(by(project_id) 句を使用しないで)project_id ラベルを保持していない場合、グローバル ルール エバリュエータが実行されているクラスタの project_id 値を使用して、ルールの結果が Monarch に書き戻されます。

    このシナリオでは、基盤となるサービス アカウントをこれ以上変更する必要はありません。

  • ルールが(by(location) 句を使用して)location ラベルを保持している場合、ルールの結果は、基盤となる時系列が発生した元の Google Cloud リージョンを使用して Monarch に書き戻されます。

    ルールが location ラベルを保持しない場合、データはグローバル ルール エバリュエータが実行されているクラスタのロケーションに書き戻されます。

cluster ラベルと namespace ラベルは、可能な限り、ルールの評価結果で保持することを強くおすすめします。そうしないと、クエリのパフォーマンスが低下し、カーディナリティの制限に達する可能性があります。両方のラベルを削除することはおすすめしません。