このドキュメントでは、Google Cloud Managed Service for Prometheusで使用する Google Cloud プロジェクトの指標スコープを構成する方法について説明します。
理想的な Managed Service for Prometheus のデプロイは、必要に応じた通常の Prometheus デプロイとは異なります。Prometheus は、データを収集する Prometheus サーバーでルールとクエリが実行される、インスタンス固有のスコープ（通常はクラスタ スコープ）です。Managed Service for Prometheus はグローバル バックエンド（Monarch）にデータを送信するため、ローカル クラスタではなく Monarch に対して実行されるようにクエリを構成する必要があります。マネージド コレクションを使用している場合、同じ要件がルールに適用されます。
Prometheus の Managed Service を使用してクエリを実行するデータは、データのクエリ方法に関係なく、Cloud Monitoring の構成の指標スコープによって決まります。
指標スコープ
Monitoring の指標スコープは読み取り専用の構成です。これを使用すると、複数の Google Cloud プロジェクトに属している指標データをクエリできます。すべての指標スコープは、スコープ対象プロジェクトと呼ばれる専用の Google Cloud プロジェクトでホストされます。
デフォルトでは、プロジェクトは独自の指標スコープのスコープ対象プロジェクトであり、指標スコープにはそのプロジェクトの指標と構成が含まれます。スコープ対象プロジェクトは、指標スコープ内に複数のモニタリング対象プロジェクトを持つことができます。指標スコープ内のすべてのモニタリング対象プロジェクトの指標と構成は、そのスコープ対象プロジェクトに表示されます。1 つのモニタリング対象プロジェクトが複数の指標スコープに属している場合もあります。
スコープ対象プロジェクト内の指標をクエリし、そのスコープ対象プロジェクトがマルチプロジェクトの指標スコープをホストしている場合は、複数のプロジェクトからデータを取得できます。指標スコープにすべてのプロジェクトが含まれている場合、クエリとルールはグローバルに評価されます。
スコープ対象プロジェクトと指標スコープの詳細については、指標スコープをご覧ください。マルチプロジェクトの指標スコープを構成する方法については、複数のプロジェクトの指標を表示するをご覧ください。
権限モデルの複雑さを最小限に抑えるには、指標スコープをできるだけ少なくします。指標データに機密性がなく、すべてのユーザーがすべての指標にアクセスできる場合は、すべてのプロジェクトを含む単一の指標スコープを使用します。
クエリのためにプロジェクトをグループ化する
それ以外のベスト プラクティスのシナリオでは、次の指標スコープの構成を使用します。
| スコープ A | スコープ B | スコープ C | |
|---|---|---|---|
| スコーピング プロジェクト | scoping-project-A | scoping-project-B | scoping-project-C |
| モニタリング対象プロジェクト | プロジェクト 1 プロジェクト 2 |
プロジェクト 3 プロジェクト 4 |
プロジェクト 1 プロジェクト 2 プロジェクト 3 プロジェクト 4 プロジェクト 5 |
| IAM 権限のあるグループ （例） |
開発チーム A | 開発チーム B | SRE チーム |