Google Cloud の外部での実行
クラスタが Google Cloud 内で実行されていない場合は、project_id ラベルと location ラベルの値を手動で構成する必要があります。次のことをおすすめします。
このクラスタがマルチテナント モニタリング モデルにどのように適合するかに基づいて
project_idを設定します。選択したproject_idに対する正しい権限がサービス アカウントに構成されている必要があります。デプロイメントに最も近い Google Cloud リージョンに基づいて
locationを設定します。
これらのラベルは、ラベル変更ルールで書き換えることはできません。
組織に 1,000 以上のプロジェクトがある
指標スコープ内のサポートされているプロジェクトの最大数は 375 ですが、指標スコープ内のサポートされていないプロジェクトの最大数は 1,000 です。
1,000 以上のプロジェクトがある場合、推奨の回避方法は、実行しているプロジェクトの ID の代わりに、中央の project_id を使用するようにコレクタを構成することです。すべてのプロジェクトの指標は、その中央プロジェクト ID の下にある Monarch に保存されるため、中央プロジェクトを指標スコープに含めるだけで済みます。
このアプローチには、次のようなデメリットがあります。
- 権限をプロジェクト単位でしか設定できないため、マルチテナンシーの粒度が失われます。プロジェクトをいくつかのカテゴリに論理的にグループ化し、それぞれに異なる中央プロジェクトを使用することもできます。
- Google Cloud システム指標の
project_id値はオーバーライドできません。この回避策では、中央プロジェクトに無料の Google Kubernetes Engine の指標は表示されません。これは、指標が元のプロジェクト内にあるためです。 - 1 つの中央プロジェクトを使用すると、ルールと ClusterRules の使用が複雑になる場合があります。これらのルールのスコープが、インストールされたプロジェクトに指定されており、同じクラスタ名と名前空間名の組み合わせが存在する可能性が低いためです。代わりに GlobalRules の使用が必要になる場合があります。
単一の Google Cloud リージョンでの手動によるデータの検索
デフォルトでは、Managed Service for Prometheus はデータの生成元である Google Cloud リージョンにデータを保存します。クエリはグローバルであるため、複数の Google Cloud リージョンにまたがるデータをクエリするために、データを地理的に同じ場所に配置する必要はありません。
ほとんどの場合、このデフォルトの動作で十分です。ただし、規制の厳しい環境などでは、すべての指標データを 1 つの Google Cloud リージョンに保存しなければならない場合があります。
すべての指標データを 1 つのリージョンに保存するには、コレクタが実行しているクラスタに自動的に検出された場所ではなく、単一の location を使用するようにコレクタを構成します。
単一の Google Cloud リージョンにデータを保存すると、ルールと ClusterRule の使用が複雑になる可能性があります。それらがインストールされた場所にスコープが指定されており、各 Google Cloud リージョンで同じクラスタ名と名前空間名の組み合わせが存在する可能性が低いためです。代わりに GlobalRules の使用が必要になる場合があります。