セルフデプロイ コレクションを使ってみる。

このドキュメントでは、セルフデプロイ コレクションを使用して Google Cloud Managed Service for Prometheus を設定する方法について説明します。サンプル アプリケーションは Kubernetes クラスタにデプロイされ、収集した指標を Monarch に保存する Prometheus サーバーによってモニタリングされます。

このドキュメントでは、次の方法について説明します。

  • 環境とコマンドライン ツールを設定する。
  • Workload Identity 対応クラスタのサービス アカウントを構成する。
  • Kubernetes でドロップインの Prometheus バイナリを実行する。
  • Managed Service for Prometheus に取り込む指標を制御する。
  • Managed Service for Prometheus を prometheus-operator の設定と統合する。
  • Prometheus バイナリを手動でコンパイルして実行する。

セルフデプロイ コレクションでは、Prometheus 環境を通常どおりユーザー自身で管理します。唯一の違いは、Managed Service for Prometheus のドロップイン代替バイナリである gke.gcr.io/prometheus-engine/prometheus:v2.41.0-gmp.9-gke.0 を、アップストリームの Prometheus バイナリの代わりに実行することです。

このドロップイン バイナリは、--export.* フラグを使用した追加の構成オプションを提供します。詳細については、--help オプションの出力をご覧ください。このドキュメントでは、最も重要なオプションについて説明します。

Managed Service for Prometheus では、連携サーバーや、リモート書き込みレシーバとして使用するサーバーからの指標のエクスポートをサポートしていません。フィルタとローカル集計を使用すると、Monarch に送信する前にデータを集約して取り込み量を減らすなど、すべての連携サーバー機能をレプリケートできます。

Managed Service for Prometheus にデータをストリーミングすると、追加のリソースが消費されます。コレクタをセルフデプロイする場合は、CPU とメモリの上限を 5 倍に増やし、実際の使用量に基づいて調整することをおすすめします。

マネージド デプロイとセルフデプロイによるデータ収集の詳細については、Managed Service for Prometheus を使用したデータ収集をご覧ください。

始める前に

このセクションでは、このドキュメントで説明するタスクに必要な構成について説明します。

プロジェクトとツールを設定する

Google Cloud Managed Service for Prometheus を使用するには、次のリソースが必要です。

  • Cloud Monitoring API が有効になっている Google Cloud プロジェクト。

    • Google Cloud プロジェクトが存在しない場合は、以下の操作を行います。

      1. Google Cloud コンソールで [新しいプロジェクト] に移動します。

        新しいプロジェクトを作成

      2. [プロジェクト名] フィールドにプロジェクトの名前を入力して、[作成] をクリックします。

      3. [お支払い] に移動します。

        [お支払い] に移動

      4. 作成したプロジェクトをまだ選択していない場合は、ページ上部でプロジェクトを選択します。

      5. 既存のお支払いプロファイルを選択するか、新しいお支払いプロファイルを作成するように求められます。

      新しいプロジェクトでは、Monitoring API がデフォルトで有効になっています。

    • Google Cloud プロジェクトがすでに存在する場合は、Monitoring API が有効になっていることを確認します。

      1. [API とサービス] に移動します。

        [API とサービス] に移動

      2. プロジェクトを選択します。

      3. [API とサービスの有効化] をクリックします。

      4. 「Monitoring」を検索します。

      5. 検索結果で、[Cloud Monitoring API] をクリックします。

      6. [API が有効です] と表示されていない場合は、[有効にする] をクリックします。

  • Kubernetes クラスタ。Kubernetes クラスタがない場合は、GKE のクイックスタートの手順を行います。

また、次のコマンドライン ツールも必要です。

  • gcloud
  • kubectl

gcloud ツールと kubectl ツールは Google Cloud CLI に含まれています。インストールの詳細については、Google Cloud CLI コンポーネントの管理をご覧ください。インストールされている gcloud CLI コンポーネントを確認するには、次のコマンドを実行します。

gcloud components list

環境を構成する

プロジェクト ID またはクラスタ名を繰り返し入力しないようにするには、次の構成を行います。

  • コマンドライン ツールを次のように構成します。

    • Google Cloud プロジェクトの ID を参照するように gcloud CLI を構成します。

      gcloud config set project PROJECT_ID

    • クラスタを使用するように kubectl CLI を構成します。

      kubectl config set-cluster CLUSTER_NAME

    これらのツールの詳細については、以下をご覧ください。

名前空間を設定する

サンプル アプリケーションの一部として作成するリソースに NAMESPACE_NAME Kubernetes Namespace を作成します。

kubectl create ns NAMESPACE_NAME

サービス アカウントの認証情報を確認する

Kubernetes クラスタで Workload Identity が有効になっている場合は、このセクションをスキップできます。

GKE で実行すると、Managed Service for Prometheus は Compute Engine のデフォルトのサービス アカウントに基づいて環境から認証情報を自動的に取得します。デフォルトのサービス アカウントには、必要な権限である monitoring.metricWriter と monitoring.viewer がデフォルトで付与されています。Workload Identity を使用せずに、以前にいずれかのロールをデフォルトのノードサービス アカウントから削除している場合は、続行する前に、不足している権限を再度追加する必要があります。

GKE で実行していない場合は、認証情報を明示的に提供するをご覧ください。

Workload Identity のサービス アカウントを構成する

Kubernetes クラスタで Workload Identity が有効になっていない場合は、このセクションをスキップできます。

Managed Service for Prometheus は、Cloud Monitoring API を使用して指標データをキャプチャします。クラスタで Workload Identity を使用している場合は、Kubernetes サービス アカウントに Monitoring API の権限を付与する必要があります。このセクションでは、次のことを説明します。

サービス アカウントを作成してバインドする

この手順は、Managed Service for Prometheus のドキュメントの複数の場所で説明されています。前のタスクですでに行っている場合は、この手順を繰り返す必要はありません。サービス アカウントを承認するに進んでください。

次のコマンド シーケンスでは、gmp-test-sa サービス アカウントを作成し、NAMESPACE_NAME 名前空間でデフォルトの Kubernetes サービス アカウントにバインドします。

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

別の GKE 名前空間またはサービス アカウントを使用している場合は、コマンドを適宜調整してください。

サービス アカウントを承認する

ロールには関連する権限がまとめられています。このロールをプリンシパル（この例では Google Cloud サービス アカウント）に付与します。Monitoring のロールの詳細については、アクセス制御をご覧ください。

次のコマンドは、Google Cloud サービス アカウント gmp-test-sa に、指標データの書き込みに必要な Monitoring API のロールを付与します。

前のタスクで Google Cloud サービス アカウントに特定のロールを付与している場合は、再度付与する必要はありません。

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Workload Identity 構成をデバッグする

Workload Identity の動作に問題がある場合は、Workload Identity の設定の確認と Workload Identity のトラブルシューティング ガイドをご覧ください。

Workload Identity の構成で最も一般的なエラーの原因は入力ミスや、部分的なコピー / 貼り付けです。これらの手順のコードサンプルに埋め込まれた編集可能な変数と、クリック可能なコピー / 貼り付けアイコンを使用することを強くおすすめします。

本番環境での Workload Identity

このドキュメントの例では、Google Cloud サービス アカウントをデフォルトの Kubernetes サービス アカウントにバインドし、Monitoring API を使用するために必要なすべての権限を Google Cloud サービス アカウントに付与しています。

本番環境では、各コンポーネントのサービス アカウントを最小権限で使用し、よりきめ細かいアプローチを使用する必要があります。Workload Identity 管理のサービス アカウントを構成する方法については、Workload Identity の使用をご覧ください。

セルフデプロイ コレクションを設定する

このセクションでは、セルフデプロイ コレクションを使用するサンプル アプリケーションを設定して実行する方法について説明します。

サンプル アプリケーションをデプロイする

このサンプル アプリケーションでは、metrics ポートに example_requests_total カウンタ指標と example_random_numbers ヒストグラム指標が出力されます。アプリケーションのマニフェストでは 3 つのレプリカを定義しています。

サンプル アプリケーションをデプロイするには、次のコマンドを実行します。

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.8.2/examples/example-app.yaml

置換 Prometheus バイナリを実行する

サンプル アプリケーションから出力された指標データを取り込むには、Google のフォーク バージョンの Prometheus サーバーをデプロイします。これは、ワークロードの指標と独自の指標エンドポイントを取得するように構成されています。

  1. 次のコマンドを実行して、フォークされたサーバーをデプロイします。

    kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.8.2/examples/prometheus.yaml

    デプロイされた Prometheus サーバーは、アップストリームの Prometheus バイナリの thin fork です。これは標準的な Prometheus サーバーと同様に動作しますが、Managed Service for Prometheus にデータを取り込むこともできます。

    上記のマニフェストは、データをグローバル データストアである Monarch に送信する基本的な動作例を示しています。データのローカルコピーは永続的に保存されません。事前定義の構成の機能と拡張方法については、オープンソースの Prometheus 構成のドキュメントをご覧ください。

    ビルド前のイメージは Linux ノードでのみ動作します。Windows ノードで実行されているターゲットを取得するには、サーバーを Linux ノードにデプロイして、Windows ノードでエンドポイントを取得するように構成するか、Windows 自体のバイナリをビルドします。

  2. Prometheus サーバーの Pod とサンプル アプリケーションの Pod が正常にデプロイされたことを確認します。

    kubectl -n NAMESPACE_NAME get pod

    デプロイに成功すると、次のような出力が表示されます。

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

GKE で実行している場合は、次の操作を行います。

GKE の外部で実行する場合は、次のセクションで説明するように、サービス アカウントを作成して指標データの書き込みを承認する必要があります。

認証情報を明示的に提供する

GKE で実行する場合、情報を収集する Prometheus サーバーは、ノードのサービス アカウントまたは Workload Identity の設定に基づいて、環境から認証情報を自動的に取得します。GKE 以外の Kubernetes クラスタでは、フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して、認証情報を収集する Prometheus サーバーに明示的に提供する必要があります。

  1. コンテキストをターゲット プロジェクトに設定します。

    gcloud config set project PROJECT_ID

  2. サービス アカウントの作成:

    gcloud iam service-accounts create gmp-test-sa

    この手順では、Workload Identity の手順ですでに作成したサービス アカウントを作成します。

  3. サービス アカウントに必要な権限を付与します。

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. サービス アカウント キーを作成してダウンロードします。

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. 鍵ファイルを Secret として GKE 以外のクラスタに追加します。

    kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Prometheus StatefulSet リソースを開いて編集します。

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. 太字で示されているテキストをリソースに追加します。

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    2. ファイルを保存して、エディタを閉じます。変更が適用されると、Pod が再作成され、指定されたサービス アカウントで指標のバックエンドに対する認証が開始します。

    また、この例で設定されたフラグを使用する代わりに、GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用してキーファイル パスを設定することもできます。

    セルフデプロイ コレクションに関する追加トピック

    このセクションでは、次の操作を行う方法について説明します。

    • マネージド サービスにエクスポートするデータをフィルタします。
    • 既存のデプロイ構成を変換します。
    • 高可用性モードで Prometheus バイナリを実行します。
    • 代替 Prometheus バイナリをビルドして実行します。
    • Google Cloud の外部で Managed Service for Prometheus を実行します。

    エクスポートした指標をフィルタする

    大量のデータを収集する場合は、費用を抑えるため、一部の時系列が Managed Service for Prometheus に送信されないようにする必要があります。

    Prometheus スクレイピング構成で通常の指標の再ラベル付け構成を使用できます。再ラベル付け構成により、取り込み時にラベルの一致に基づいて指標をドロップできます。

    Managed Service for Prometheus にエクスポートせずに、ローカルでのデータの取り込みが必要になることもあります。エクスポートされた指標をフィルタリングするには、--export.match フラグを使用します。

    このフラグには 1 つ以上の PromQL シリーズ セレクタを指定します。このフラグは複数回使用できます。時系列が少なくとも 1 つのフラグのセレクタをすべて満たしている場合、その時系列は Managed Service for Prometheus にエクスポートされます。つまり、適格性を判断する際、1 つのフラグ内の条件は AND で結合され、別のフラグ内の条件は OR で結合されます。次の例では、2 つのフラグ インスタンスを使用します。

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    この変更により、「prometheus」ジョブの指標と、ジョブレベルに集約された記録ルールによって生成された指標（命名のベスト プラクティスに従っている場合）のみがエクスポートされます。他のすべての時系列のサンプルは除外されます。デフォルトでは、セレクタは指定されず、すべての時系列がエクスポートされます。

    --export.match フラグのセマンティクスは、Prometheus 連携の match[] パラメータと同じです。そのため、連携サーバーからセレクタを、連携された Prometheus サーバーでスクレイピングした Prometheus サーバーのフラグとして直接使用することで、連携設定を Managed Service for Prometheus に移行できます。連携サーバーからマネージド サービスへの指標のエクスポートはサポートされていません。

    フィルタに histogram タイプの指標を含めるには、_count、_sum、_bucket 指標を指定する必要があります。また、セレクタ {__name__=~"histogram_metric_.+"} のようなワイルドカード マッチャーを使用してこの操作を行うこともできます。

    prometheus-operator ライブラリを使用している場合は、コンテナの EXTRA_ARGS 環境変数を使用して --export.match フラグを設定します。詳細については、prometheus-operator と一緒に使用するをご覧ください。

    フィルタフラグをローカルで実行される記録ルールと組み合わせると、Monarch に送信する前にデータを「ロールアップ」して、カーディナリティと費用を削減できます。詳しくは、費用管理とアトリビューションをご覧ください。

    Cloud Monitoring の [指標の管理] ページでは、オブザーバビリティに影響を与えることなく、課金対象の指標に費やす金額を制御するために役立つ情報が提供されます。[指標の管理] ページには、次の情報が表示されます。

    • 指標ドメイン全体と個々の指標での、バイトベースとサンプルベースの両方の課金に対する取り込み量。
    • 指標のラベルとカーディナリティに関するデータ。
    • アラート ポリシーとカスタム ダッシュボードでの指標の使用。
    • 指標書き込みエラーの割合。
    [指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。

    prometheus-operator と一緒に使用する

    Managed Service for Prometheus の Prometheus バイナリは、prometheus-operator によって管理される既存の GKE Prometheus デプロイでも使用できます。

    マネージド サービスのバイナリを使用するには、Prometheus リソースのイメージ仕様を置き換えます。

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.41.0-gmp.9-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Workload Identity クラスタ内にいて、リソースの名前空間またはサービス アカウントが異なる場合は、追加の名前空間と Kubernetes サービス アカウントのペアに対して Workload Identity の手順を繰り返します。

    GKE 以外の Kubernetes クラスタで実行する場合は、認証情報を手動で指定する必要があります。認証情報を提供するには、次の手順を行います。

    1. 認証情報を明示的に指定するの説明に従って、適切なサービス アカウント キーファイルを Secret として追加します。

    2. Prometheus リソースを変更して、太字で示されているテキストを追加します。

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    コンテナの EXTRA_ARGS 環境変数を設定して、指標フィルタリング フラグなどのフラグを追加できます。コンテナ仕様の args セクションは Prometheus Operator によって管理されるため、これは環境変数を介して行われます。

    kube-prometheus と一緒に使用する

    人気の kube-prometheus ライブラリを使用してデプロイメントを作成し、Prometheus 用のマネージド サービスを使用するように構成できます。

    kube-prometheus には、デフォルトの名前空間とサービス アカウントに対して内部的に緊密な依存関係があるため、Prometheus 用のマネージド サービスにデータを送信するのに必要な最小限のフィールドのみ変更することをおすすめします。

    manifests/prometheus-prometheus.yaml 内で、イメージ仕様を置き換え、replicas を 1 に減らして高可用性収集をオフにします。

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.41.0-gmp.9-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...

    GKE 上で実行していて、ノード上のデフォルトのサービス アカウントを変更していない場合は、変更したマニフェストを適用すると、Prometheus 用のマネージド サービスへのデータ送信がすぐに開始されます。それ以外の場合は、サービス アカウントを構成して適用する必要がある場合があります。GKE 上で実行していて、Workload Identity を使用する場合は、monitoring 名前空間内で prometheus-k8s サービス アカウントを作成して承認する必要がある場合があります。GKE 以外の Kubernetes クラスタで実行する場合は、prometheus-operator セクションの手順に従ってください。

    kube-prometheus はデフォルトで多くの指標を収集します。それらのほとんどは、GKE などのマネージド Kubernetes 環境では不要な場合が数多くあります。取り込みコストを節約するために、kube-prometheus をカスタマイズして、関心のある指標だけを収集するようにしたり、エクスポートされた指標を積極的にフィルタリングしたりできます。

    その他の提案については、費用管理とアトリビューションをご覧ください。

    高可用性デプロイ

    代替 Prometheus バイナリには、リーダー選出を使用した高可用性コレクションのサポートが組み込まれています。高可用性モードのレプリケートされた Prometheus サーバーは、通常どおり指標の収集とルールの評価を行いますが、Google Cloud Managed Service for Prometheus にデータを送信するのはいずれか 1 つだけです。

    同じ Prometheus サーバーのレプリカには、同じ external_labels を含め、常に同じ構成にする必要があります。この要件は、レプリカを明示的に区別するために __replica__ などの特別な外部ラベルに依存する他のシステムとは異なります。

    Kubernetes API サーバーは、サポートされているリーダー選出バックエンドであり、次のフラグを設定することで有効にできます。

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    LEASE_NAMESPACE と LEASE_NAME の値は、リーダー選出が行われるリースリソースを識別します。同じリソースを参照する Prometheus サーバーはすべて同じレプリカセットに属します。Prometheus デプロイメントの Kubernetes サービス アカウントには、対応するリースリソースの読み取りと書き込みを行うための権限が必要です。Kubernetes クラスタの外部で Prometheus サーバーを実行する場合は、--export.ha.kube.config フラグを使用して明示的な構成を指定します。

    この設定を行った後、replicas に 2 以上の値を設定できるようになります。

    バイナリ デプロイ

    コンテナ化されていない環境で実行する場合は、置換 Prometheus バイナリを直接ビルドできます。

    ソースのビルド

    Prometheus をコンパイルする既存のプロセスがある場合は、GitHub リポジトリをプロセスに透過的に置換できます。Managed Service for Prometheus には独自のバージョンタグ拡張機能があり、リリースとアップストリーム リリースを区別できます。

    プレーン バイナリをビルドするには、Go ツールチェーンと最新バージョンの NPM / Yarn をマシンにインストールする必要があります。詳細については、アップストリーム ビルドの手順をご覧ください。

    1. リポジトリのクローンを作成します。

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. 目的のバージョンタグをチェックアウトします。

      git checkout v2.41.0-gmp.9

    3. Managed Service for Prometheus tarball を作成するには、次のコマンドを実行します。

      make build && make tarball

    作成された tarball とバイナリには、ディレクトリ構造と機能の点で、アップストリーム バリアントと完全な互換性があります。

    指標とラベルの作成と更新に関する制限

    Managed Service for Prometheus では、新しい指標の作成と既存の指標への新しい指標ラベルの追加に、1 分あたりのレート制限が適用されます。通常、このレート制限は、Managed Service for Prometheus と初めて統合するときにのみ発生します（たとえば、既存の成熟した Prometheus デプロイをセルフデプロイ済みのコレクションを使用する方式に移行する場合）。これは、データポイントを取り込む場合のレート制限ではありません。このレート制限は、未知の指標を作成する場合、または既存の指標に新しいラベルを追加する場合にのみ適用されます。

    この割り当ては固定されていますが、新しい指標と指標ラベルを作成するときのレートが 1 分あたりの制限以下になると、問題は自動的に解決されます。

    詳細については、トラブルシューティングをご覧ください。

    Google Cloud の外部でセルフデプロイ コレクションを実行する

    Compute Engine 環境、GKE 環境、または適切な権限を持つアカウントで gcloud login を実行したマシンでは、追加構成なしでセルフデプロイ コレクションを実行できます。Google Cloud の外部では、認証情報を明示的に指定するか、指標を格納する project_id と指標を保存する location（Google Cloud リージョン）を明示的に指定する必要があります。また、cluster ラベルと namespace ラベルを設定する必要があります。これは Kubernetes 以外の環境で実行する場合でも同様です。

    サービス アカウント キーを指定するには、認証情報を明示的に指定するで説明しているように、--export.credentials-file フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用します。

    読み取り用に計画されたテナンシー モデルに基づいて project_id を選択することをおすすめします。後で指標スコープを使用して読み取りを整理する方法に基づいて、指標を保存するプロジェクトを選択します。問題がなければ、すべてを 1 つのプロジェクトにまとめても構いません。

    location については、デプロイに最も近い Google Cloud リージョンを選択することをおすすめします。選択した Google Cloud リージョンがデプロイから遠くなるほど、書き込みレイテンシが大きくなり、より多くのネットワーク問題が発生する可能性があります。複数のクラウドにまたがるリージョンのリストをご覧ください。問題がなければ、すべてを 1 つの Google Cloud リージョンにまとめることができます。global をロケーションとして使用することはできません。

    Kubernetes 環境で実行する場合は、cluster と namespace の値をローカル クラスタと名前空間に設定します。Kubernetes の外部で実行する場合は、階層的に意味のある値に設定します。たとえば、AWS 上で実行される VM ベースの環境では、cluster の値を __aws__ に、namespace の値をインスタンス ID に設定します。ローカル メタデータ サーバーを呼び出すラベル変更ルールを使用して、インスタンス ID を動的に入力できます。

    最小の例では、次のコマンドを使用して、ローカルのセルフ モニタリング Prometheus バイナリを実行できます。

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    この例では、REGION 変数が us-central1 などの値に設定されていることを前提としています。

    ただし、Prometheus 構成の global.external_labels セクションでマネージド サービスの export ターゲット ラベルを設定することをおすすめします。たとえば、Kubernetes 環境では次の構成を使用できます。

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    Google Cloud の外部で Managed Service for Prometheus を実行すると、データ転送料金が発生します。Google Cloud へのデータ転送には料金がかかります。また、別のクラウドからのデータ移転にも料金が発生する場合があります。--export.compression=gzip フラグを使用して圧縮を有効にすると、このコストを最小限に抑えることができます。

    次のステップ