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

このドキュメントでは、セルフデプロイ コレクションを使用して 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.28.1-gmp.2-gke.0 を、アップストリームの Prometheus バイナリの代わりに実行することです。

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

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

始める前に

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

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

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

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

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

      1. Cloud Console で [新しいプロジェクト] に移動します。

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

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

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

        [お支払い] に移動

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

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

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

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

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

        [API とサービス] に移動

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

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

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

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

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

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

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

  • gcloud
  • kubectl

gcloudkubectl は Cloud SDK に含まれています。インストール方法については、Cloud SDK コンポーネントの管理をご覧ください。インストールされている Cloud SDK コンポーネントを確認するには、次のコマンドを実行します。

gcloud components list

環境を構成する

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

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

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

      gcloud config set project PROJECT_ID
      
    • クラスタを使用するように kubectl ツールを構成します。

      kubectl config set-cluster CLUSTER_NAME
      

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

名前空間を設定する

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

kubectl create ns gmp-test

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

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

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

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

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

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

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[gmp-test/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace gmp-test \
  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

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

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

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

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

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

マネージド サービスは、metrics ポートに Prometheus 指標を送信するサンプル アプリケーションのマニフェストを提供します。このアプリケーションは 3 つのレプリカを使用します。

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

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

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

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

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

    kubectl -n gmp-test apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.1.1/examples/prometheus.yaml
    

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

    上記のマニフェストは基本的な動作例のみを示すもので、データを永続的に保存するわけではないことに注意してください。事前定義の構成の機能と拡張方法については、オープンソースの Prometheus 構成のドキュメントをご覧ください。マネージド ストレージへのデータの取り込み中は高可用性の Prometheus ペアを実行できません。

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

    kubectl -n gmp-test 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 サーバーは、Compute Engine のデフォルト サービス アカウントまたは Workload Identity の設定に応じて環境から認証情報を自動的に取得します。

GKE 以外の Kubernetes クラスタでは、フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して、認証情報を収集する Prometheus サーバーに明示的に提供する必要があります。

  1. サービス アカウントを作成します。

    gcloud iam service-accounts create gmp-test-sa
    

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

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

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

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

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
      --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
    
  4. 鍵ファイルを Secret として GKE 以外のクラスタに追加します。

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

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

    kubectl -n gmp-test edit statefulset prometheus-test
    

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

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      namespace: gmp-test
      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
    ...
    

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

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

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

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

  • マネージド サービスにエクスポートするデータをフィルタします。
  • 既存のデプロイ構成を変換します。
  • 置換 Prometheus バイナリをビルドして実行します。

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

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

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

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

このフラグには PromQL 時系列セレクタを指定し、複数回使用できます。少なくとも 1 つのセレクタに一致する場合は、時系列が Managed Service for Prometheus にエクスポートされます。次の例では、2 つのフラグ インスタンスを使用します。

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

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

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

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

prometheus-operator と一緒に使用する

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

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

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

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
    

コンテナの 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.28.1-gmp.2-gke.0
      ...
      replicas: 1
      version: v2.28.1
      ...
  

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

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

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

バイナリ デプロイ

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

ソースのビルド

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

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

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

    git clone https://github.com/GoogleCloudPlatform/prometheus &&
    cd prometheus
    
  2. 目的のバージョンタグをチェックアウトします。

    git checkout v2.28.1-gmp.2
    
  3. Managed Service for Prometheus tarball を作成するには、次のコマンドを実行します。

    make build && make tarball
    

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

バイナリを実行する

Compute Engine 環境または適切な権限を持つアカウントで実行した gcloud login マシンでは、追加構成なしでバイナリを実行できます。サーバーはスクレイピングした指標を Monarch に送信します。

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

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

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

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

ただし、次のように、Prometheus 構成の global.external_labels セクションでマネージド サービスの export ターゲット ラベルを設定することをおすすめします。

global:
  external_labels:
    project_id: PROJECT_ID
    location: ZONE
    namespace: local-testing

scrape_configs:
  ...

次のステップ