マネージド コレクションによるルールとアラートの評価

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

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

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

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

  • マネージド ルールのエバリュエータは、マネージド コレクションが実行されているクラスタに自動的にデプロイされます。これらのエバリュエータは次のように構成されています。

    • Rules リソースを使用して、名前空間内のデータにルールを実行します。Rules リソースは、ルールを実行するすべての名前空間に適用する必要があります。

    • ClusterRules リソースを使用して、クラスタ全体のデータにルールを実行します。ClusterRules リソースは各クラスタに 1 回適用する必要があります。

  • すべてのルール評価は、グローバル データストアである Monarch に対して実行されます。

    • Rules リソースは、ルールがインストールされているプロジェクト、ロケーション、クラスタ、名前空間に対してルールを自動的にフィルタリングします。
    • ClusterRules リソースは、ルールがインストールされているプロジェクト、ロケーション、クラスタに対してルールを自動的にフィルタリングします。
    • すべてのルールの結果が評価されてから Monarch に書き込まれます。

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

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

上記の図には、オプションの GlobalRules リソースも示されています。複数のプロジェクトにわたりグローバル SLO を計算する場合や、単一の Google Cloud プロジェクト内のすべてのクラスタでルールを評価するなど、GlobalRules は限られたタスクで慎重に使用してください。可能な限り、Rules と ClusterRules を使用することを強くおすすめします。これらのリソースは優れた信頼性を提供するため、一般的な Kubernetes デプロイ メカニズムとテナンシー モデルに適しています。

GlobalRules リソースを使用する場合は、上記の図で次の点に注意してください。

  • Google Cloud 内で実行されている 1 つのクラスタが、指標スコープのグローバル ルール評価クラスタとして指定されます。このマネージド ルール エバリュエータは、プロジェクト 1 とプロジェクト 2 を含む scoping_project_A を使用するように構成されています。scoping_project_A に対して実行されたルールは、プロジェクト 1 とプロジェクト 2 に自動的にファンアウトされます。

    基盤となるサービス アカウントには、scoping_project_A の Monitoring 閲覧者の権限が付与されている必要があります。これらのフィールドの設定方法の詳細については、マルチプロジェクトとグローバル ルールの評価をご覧ください。

  • 他のすべてのクラスタと同様に、このルール エバリュエータは、名前空間またはクラスタをスコープとするルールを評価する Rules リソースと ClusterRules リソースを使用して設定されます。これらのルールは、ローカル プロジェクト（この場合はプロジェクト 1）に自動的にフィルタリングされます。scoping_project_A にはプロジェクト 1 が含まれているため、Rules と ClusterRules で構成されたルールは、想定どおりローカル プロジェクトのデータに対してのみ実行されます。

  • このクラスタには、scoping_project_A に対してルールを実行する GlobalRules リソースもあります。GlobalRules は自動的にフィルタリングされないため、scoping_project_A のプロジェクト、ロケーション、クラスタ、名前空間のすべてに GlobalRule が記述されたとおりに適用されます。

  • 配信されたアラートルールは、セルフホストの AlertManager に想定どおり送信されます。

GlobalRules を使用すると、ユーザーのルールで project_id、location、cluster、namespace の各ラベルを保持または集計するかどうかによって、予期しない結果が生じる可能性があります。

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

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

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

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

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

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

cluster ラベルと namespace ラベルは、ルールの目的がこれらのラベルを集約し取り除くことである場合を除き、ルールの評価結果で保持することを強くおすすめします。そうしないと、クエリのパフォーマンスが低下し、基数の上限に達する可能性があります。両方のラベルを削除することは絶対に避けてください。