Google Cloudの外部で実行する
クラスタが Google Cloud内で実行されていない場合は、project_id ラベルと location ラベルの値を手動で構成する必要があります。次のことをおすすめします。
このクラスタがマルチテナント モニタリング モデルにどのように適合するかに基づいて
project_idを設定します。選択したproject_idに対する正しい権限がサービス アカウントに構成されている必要があります。デプロイメントに最も近い Google Cloud リージョンに基づいて
locationを設定します。
これらのラベルは、ラベル変更ルールで書き換えることはできません。
組織に 3,500 を超える数のプロジェクトがある
指標スコープ内のサポートされるプロジェクトの最大数は 375 ですが、サポートされない状態での最大数は 3,500 です。
プロジェクト数が 3,500 を超えている場合、実行しているプロジェクトの 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 リージョンにまたがるデータをクエリできます。
ほとんどの状況においてこのデフォルトの動作で問題ありませんが、規制の厳しい環境下など、すべての指標データを単一の Google Cloud リージョンに保存する必要があるケースも考えられます。
すべての指標データを単一のリージョンに保存するには、コレクタが動作しているクラスタの自動検出された場所ではなく、単一の location を使用するようにコレクタを構成します。
データを単一の Google Cloud リージョンに保存すると、Rules や ClusterRule の使用が複雑になる可能性があります。これらはインストールされた場所に限定されるため、各 Google Cloud リージョンで同じクラスタ名や名前空間名のセットを持っているとは限らないからです。代わりに GlobalRules の使用が必要になる場合があります。