マネージド コレクションを使ってみる

このドキュメントでは、マネージド コレクションを使用して Google Cloud Managed Service for Prometheus を設定する方法について説明します。この設定は、サンプル アプリケーションをモニタリングし、収集された指標を Monarch に保存する Prometheus の Deployment を使用した、取り込み操作の最小限の例です。

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

• 環境とコマンドライン ツールを設定する。
• クラスタのマネージド コレクションを設定する。
• ターゲットの取得と指標の取り込みのためにリソースを構成します。
• 既存の prometheus-operator カスタム リソースを移行する。

コレクタのデプロイ、スケーリング、シャーディング、構成、メンテナンスなどの複雑さが軽減されるまで、マネージド コレクションを使用することをおすすめします。マネージド コレクションは、GKE と他のすべての Kubernetes 環境でサポートされています。

マネージド コレクションは、Prometheus ベースのコレクタを Daemonset として実行し、同じ場所に配置されたノード上のターゲットをスクレイピングすることだけでスケーラビリティを保証します。軽量のカスタム リソースを持つコレクタを、pull コレクションを使用してエクスポータをスクレイピングするように構成してから、コレクタがスクレイピングしたデータを中央のデータストアの Monarch に push します。Google Cloud がクラスタに直接アクセスして指標データを pull したり、スクレイピングすることは決してありません。コレクタが Google Cloud にデータを push します。マネージド デプロイとセルフデプロイによるデータ収集の詳細については、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
    

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

  • gcloud CLI の概要
  • kubectl コマンド

名前空間を設定する

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

kubectl create ns NAMESPACE_NAME

マネージド コレクションを設定する

マネージド コレクションは、GKE クラスタと GKE 以外の Kubernetes クラスタの両方で使用できます。

マネージド コレクションを有効にすると、クラスタ内コンポーネントが実行されますが、指標はまだ生成されません。PodMonitoring リソースや ClusterPodMonitoring リソースは、これらのコンポーネントで指標エンドポイントを正しく取得するために必要です。これらのリソースを有効な指標エンドポイントとともにデプロイするか、GKE に組み込まれている Kube 状態指標などのマネージド指標パッケージのいずれかを有効にする必要があります。トラブルシューティングについては、取り込み側の問題をご覧ください。

マネージド モードでの収集を有効にすると、クラスタに次のコンポーネントがインストールされます。

• gmp-operator Deployment。Prometheus 向けマネージド サービスの Kubernetes オペレーターをデプロイします。
• rule-evaluator Deployment。アラートルールと記録ルールの構成と実行に使用します。
• collector DaemonSet。各コレクタと同じノードで実行されている Pod からの指標のみを取得して、コレクションを水平にスケーリングします。
• alertmanager StatefulSet。トリガーされたアラートを推奨通知チャネルに送信するように構成されます。

Managed Service for Prometheus に関するリファレンス ドキュメントについては、マニフェスト ページをご覧ください。

マネージド コレクションを有効にする: GKE

マネージド コレクションは、次のものに対してデフォルトで有効になっています。

• GKE バージョン 1.25 以降を実行している GKE Autopilot クラスタ。

• GKE バージョン 1.27 以降を実行している GKE Standard クラスタ。このデフォルトは、クラスタの作成時にオーバーライドできます。マネージド コレクションを無効にするをご覧ください。

マネージド コレクションをデフォルトで有効にしない GKE 環境で実行している場合は、マネージド コレクションを手動で有効にするをご覧ください。

クラスタ内コンポーネント バージョンが新しくリリースされると、GKE のマネージド コレクションが自動的にアップグレードされます。

GKE のマネージド モードでの収集では、デフォルトの Compute Engine サービス アカウントに付与されている権限を使用します。デフォルトのノード サービス アカウントの標準権限を変更するポリシーがある場合、続行するには Monitoring Metric Writer ロールの追加が必要になることがあります。

マネージド コレクションを手動で有効にする

デフォルトでマネージド コレクションが有効になっていない GKE 環境で実行している場合は、次の方法でマネージド コレクションを有効にできます。

• Cloud Monitoring の GKE クラスタ ダッシュボード。
• Google Cloud コンソールの Kubernetes Engine ページ。
• Google Cloud CLI。gcloud CLI を使用するには、GKE バージョン 1.21.4-gke.300 以降を実行する必要があります。

• Google Kubernetes Engine 向けの Terraform。Terraform を使用して Managed Service for Prometheus を有効にするには、GKE バージョン 1.21.4-gke.300 以降を実行する必要があります。

gcloud config set project PROJECT_ID

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

マネージド コレクションを無効にする

クラスタでマネージド コレクションを無効にするには、次のいずれかの方法を使用します。

gcloud config set project PROJECT_ID

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

マネージド コレクションを有効にする: GKE 以外の Kubernetes

GKE 以外の環境で実行している場合は、次の方法でマネージド コレクションを有効にできます。

• kubectl CLI。

• バージョン 1.12 以降を実行する GKE Enterprise デプロイに含まれるバンドル ソリューション。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

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

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

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

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

PodMonitoring リソースを構成する

サンプル アプリケーションによって出力された指標データを取り込むために、Managed Service for Prometheus はターゲットのスクレイピングを使用します。ターゲットのスクレイピングと指標の取り込みは、Kubernetes のカスタム リソースを使用して構成されます。マネージド サービスは、PodMonitoring カスタム リソース（CR）を使用します。

PodMonitoring CR は、CR がデプロイされている名前空間のターゲットのみをスクレイピングします。複数の名前空間でターゲットをスクレイピングするには、各名前空間に同じ PodMonitoring CR をデプロイします。kubectl get podmonitoring -A を実行すると、目的の名前空間に PodMonitoring リソースがインストールされていることを確認できます。

すべての Managed Service for Prometheus CR のリファレンス ドキュメントについては、prometheus-engine/doc/api のリファレンスをご覧ください。

次のマニフェストでは、NAMESPACE_NAME Namespace で PodMonitoring リソース prom-example を定義します。このリソースでは、Kubernetes ラベルセレクタを使用して、ラベルが app.kubernetes.io/name で値が prom-example の名前空間内のすべての Pod を検索します。一致する Pod が 30 秒ごとに、/metrics HTTP パスの metrics というポートでスクレイピングされます。

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

このリソースを適用するには、次のコマンドを実行します。

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

マネージド コレクタが一致する Pod をスクレイピングしています。 スクレイピング ターゲットのステータスを表示するには、ターゲット ステータス機能を有効にします。

すべての Namespace にわたって Pod の範囲に適用される水平コレクションを構成するには、ClusterPodMonitoring リソースを使用します。ClusterPodMonitoring リソースは、PodMonitoring リソースと同じインターフェースを提供しますが、検出された Pod を特定の名前空間に制限しません。

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

• Cloud Monitoring で PromQL を使用してサンプル アプリケーションによって取り込まれた指標をクエリするには、Cloud Monitoring を使用したクエリをご覧ください。
• Grafana を使用してサンプル アプリケーションによって取り込まれた指標をクエリするには、Grafana または Prometheus API コンシューマーを使用したクエリをご覧ください。
• エクスポートされた指標のフィルタリングと prom-operator リソースの調整については、マネージド コレクションに関するその他のトピックをご覧ください。

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

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

GKE で実行する場合、情報を収集する Prometheus サーバーは、ノードのサービス アカウントに基づいて環境から認証情報を自動的に取得します。GKE 以外の Kubernetes クラスタでは、gmp-public 名前空間内の OperatorConfig リソースによって認証情報を明示的に提供する必要があります。

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

   gcloud config set project PROJECT_ID
   

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

   gcloud iam service-accounts create gmp-test-sa
   

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 gmp-public create secret generic gmp-test-sa \
     --from-file=key.json=gmp-test-sa-key.json
   

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

   kubectl -n gmp-public edit operatorconfig config
   

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

      apiVersion: monitoring.googleapis.com/v1
      kind: OperatorConfig
      metadata:
        namespace: gmp-public
        name: config
      collection:
        credentials:
          name: gmp-test-sa
          key: key.json
      

      マネージド ルールの評価が機能するように、これらの認証情報を rules セクションに追加します。

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

   マネージド コレクションに関するその他のトピック

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

   • ターゲット ステータス機能を有効にして、デバッグを容易にする。
   • Terraform を使用してターゲットのスクレイピングを構成する。
   • マネージド サービスにエクスポートするデータをフィルタする。
   • Kubelet と cAdvisor の指標をスクレイピングする。
   • マネージド サービスで使用できるように既存の prom-operator リソースを変換する。
   • GKE の外部でマネージド コレクションを実行する。

   ターゲット ステータス機能の有効化

   Managed Service for Prometheus には、コレクタによってターゲットが適切に検出されてスクレイピングされているかどうかを確認する方法が用意されています。このターゲット ステータス レポートは、緊急の問題をデバッグするためのツールです。この機能は、緊急の問題を調査する場合にのみ有効にすることを強くおすすめします。大規模なクラスタでターゲット ステータス レポートをオンのままにすると、オペレーターがメモリ不足になり、クラッシュ ループが発生する可能性があります。

   次のように、OperatorConfig リソース内の features.targetStatus.enabled 値を true に設定すると、PodMonitoring リソースまたは ClusterPodMonitoring リソース内のターゲットのステータスを確認できます。

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       features:
         targetStatus:
           enabled: true
   

   構成されている場合、数秒後にすべての有効な PodMonitoring リソースまたは ClusterPodMonitoring リソースに Status.Endpoint Statuses フィールドが表示されます。

   NAMESPACE_NAME Namespace に prom-example という名前の PodMonitoring リソースがある場合は、次のコマンドを実行してステータスを確認できます。

   kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example
   

   出力は次のようになります。

   API Version:  monitoring.googleapis.com/v1
   Kind:         PodMonitoring
   ...
   Status:
     Conditions:
       ...
       Status:                True
       Type:                  ConfigurationCreateSuccess
     Endpoint Statuses:
       Active Targets:       3
       Collectors Fraction:  1
       Last Update Time:     2023-08-02T12:24:26Z
       Name:                 PodMonitoring/custom/prom-example/metrics
       Sample Groups:
         Count:  3
         Sample Targets:
           Health:  up
           Labels:
             Cluster:                     CLUSTER_NAME
             Container:                   prom-example
             Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
             Job:                         prom-example
             Location:                    REGION
             Namespace:                   NAMESPACE_NAME
             Pod:                         prom-example-589ddf7f7f-hcnpt
             project_id:                  PROJECT_ID
           Last Scrape Duration Seconds:  0.020206416
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.054189485
           Health:                        up
           Labels:
             ...
           Last Scrape Duration Seconds:  0.006224887
   

   出力には次のステータス フィールドが含まれます。

   • Status.Conditions.Status は、Managed Service for Prometheus が PodMonitoring または ClusterPodMonitoring に応答して処理する場合、true になります。
   • Status.Endpoint Statuses.Active Targets は、この PodMonitoring リソースのすべてのコレクタで Managed Service for Prometheus がカウントする取得ターゲットの数を示します。サンプル アプリケーションでは、prom-example Deployment に 1 つの指標ターゲットを持つ 3 つのレプリカがあるため、値は 3 になります。異常なターゲットがある場合は、Status.Endpoint Statuses.Unhealthy Targets フィールドが表示されます。
   • Status.Endpoint Statuses.Collectors Fraction は、Managed Service for Prometheus からすべてのマネージド コレクタに到達可能な場合、1 の値（100% を意味する）を示します。
   • Status.Endpoint Statuses.Last Update Time は、最終更新時刻を表示します。最終更新時刻が目的の収集間隔よりも大幅に長い場合は、その差がターゲットまたはクラスタに問題があることを示している可能性があります。
   • Status.Endpoint Statuses.Sample Groups フィールドには、コレクタによって挿入された共通のターゲット ラベルでグループ化されたサンプル ターゲットが示されます。この値は、ターゲットが検出されない状況のデバッグに役立ちます。すべてのターゲットが正常で、収集されている場合、Health フィールドの期待値は up であり、Last Scrape Duration Seconds フィールドの値が一般的なターゲットの通常の期間です。

   これらのフィールドの詳細については、Managed Service for Prometheus API のドキュメントをご覧ください。

   次のいずれかは、構成に問題があることを示しています。

   • PodMonitoring リソースに Status.Endpoint Statuses フィールドがない。
   • Last Scrape Duration Seconds フィールドの値が古すぎる。
   • ターゲットが少なすぎる。
   • Health フィールドの値が、ターゲットが down であることを示している。

   ターゲット検出の問題のデバッグの詳細については、トラブルシューティング ドキュメントの取り込み側の問題をご覧ください。

   承認済みスクレイピング エンドポイントの構成

   スクレイピング ターゲットに認可が必要な場合は、適切な認可タイプを使用して関連するシークレットを提供するようにコレクタを設定できます。

   Google Cloud Managed Service for Prometheus は、次の認可タイプをサポートしています。

   • mTLS
   • BasicAuth
   • HTTP 認可ヘッダー
   • OAuth 2

   mTLS

   mTLS は、Istio サービス メッシュや Cloud Service Mesh などのゼロトラスト環境内で構成するのが一般的です。

   mTLS を使用して保護されたエンドポイントのスクレイピングを有効にするには、PodMonitoring リソースの Spec.Endpoints[].Scheme フィールドを https に設定します。推奨されていませんが、PodMonitoring リソースの Spec.Endpoints[].insecureSkipVerify フィールドを true に設定して、証明書認証局の検証をスキップできます。または、シークレット リソースから証明書と鍵を読み込むように Managed Service for Prometheus を構成することもできます。

   たとえば、次の Secret リソースには、クライアント（cert）、秘密鍵（key）、認証局（ca）証明書の鍵が含まれています。

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     cert: ********
     key: ********
     ca: ********
   

   Managed Service for Prometheus コレクタに、その Secret リソースにアクセスする権限を付与します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   GKE Autopilot クラスタでは、次のように表示されます。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   以前の Secret リソースを使用する PodMonitoring リソースを構成するには、リソースを変更して scheme セクションと tls セクションを追加します。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       scheme: https
       tls:
         ca:
           secret:
             name: secret-example
             key: ca
         cert:
           secret:
             name: secret-example
             key: cert
         key:
           secret:
             name: secret-example
             key: key
   

   Managed Service for Prometheus のすべての mTLS オプションに関するリファレンス ドキュメントについては、API リファレンス ドキュメントをご覧ください。

   BasicAuth

   BasicAuth を使用して保護されたスクレイピング エンドポイントを有効にするには、PodMonitoring リソースの Spec.Endpoints[].BasicAuth フィールドにユーザー名とパスワードを設定します。その他の HTTP 認可ヘッダーの種類については、HTTP 認可ヘッダーをご覧ください。

   たとえば、次の Secret リソースには、パスワードを保存するキーが含まれています。

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     password: ********
   

   Managed Service for Prometheus コレクタに、その Secret リソースにアクセスする権限を付与します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   GKE Autopilot クラスタでは、次のように表示されます。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   前の Secret リソースと foo というユーザー名を使用する PodMonitoring リソースを構成するには、リソースを変更して basicAuth セクションを追加します。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       basicAuth:
         username: foo
         password:
           secret:
             name: secret-example
             key: password
   

   Managed Service for Prometheus のすべての BasicAuth オプションに関するリファレンス ドキュメントについては、API リファレンス ドキュメントをご覧ください。

   HTTP 認可ヘッダー

   HTTP 認可ヘッダーを使用して保護されたスクレイピング エンドポイントを有効にするには、PodMonitoring リソースの Spec.Endpoints[].Authorization フィールドにタイプと認証情報を設定します。BasicAuth エンドポイントの場合は、代わりに BasicAuth 構成を使用します。

   たとえば、次の Secret リソースには、認証情報を格納するキーが含まれています。

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     credentials: ********
   

   Managed Service for Prometheus コレクタに、その Secret リソースにアクセスする権限を付与します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   GKE Autopilot クラスタでは、次のように表示されます。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   前の Secret リソースと Bearer のタイプを使用する PodMonitoring リソースを構成するには、リソースを変更して authorization セクションを追加します。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       authorization:
         type: Bearer
         credentials:
           secret:
             name: secret-example
             key: credentials
   

   Managed Service for Prometheus のすべての HTTP 認可ヘッダー オプションに関するリファレンス ドキュメントについては、API リファレンス ドキュメントをご覧ください。

   OAuth 2

   OAuth 2 を使用して保護されたスクレイピング エンドポイントを有効にするには、PodMonitoring リソースで Spec.Endpoints[].OAuth2 フィールドを設定する必要があります。

   たとえば、次の Secret リソースには、クライアント シークレットを保存するキーが含まれています。

   kind: Secret
   metadata:
     name: secret-example
   stringData:
     clientSecret: ********
   

   Managed Service for Prometheus コレクタに、その Secret リソースにアクセスする権限を付与します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gmp-system
     kind: ServiceAccount
   

   GKE Autopilot クラスタでは、次のように表示されます。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: secret-example-read
   rules:
   - resources:
     - secrets
     apiGroups: [""]
     verbs: ["get", "list", "watch"]
     resourceNames: ["secret-example"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: gmp-system:collector:secret-example-read
     namespace: default
   roleRef:
     name: secret-example-read
     kind: Role
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - name: collector
     namespace: gke-gmp-system
     kind: ServiceAccount
   

   クライアント ID が foo でトークン URL が example.com/token の以前の Secret リソースを使用する PodMonitoring リソースを構成するには、リソースを変更して oauth2 セクションを追加します。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: prom-example
   spec:
     selector:
       matchLabels:
         app.kubernetes.io/name: prom-example
     endpoints:
     - port: metrics
       interval: 30s
       oauth2:
         clientID: foo
         clientSecret:
           secret:
             name: secret-example
             key: password
         tokenURL: example.com/token
   

   Managed Service for Prometheus のすべての OAuth 2 オプションに関するリファレンス ドキュメントについては、API リファレンス ドキュメントをご覧ください。

   Terraform を使用したターゲット スクレイピングの構成

   kubernetes_manifest Terraform リソースタイプまたは kubectl_manifest Terraform リソースタイプ（任意のカスタム リソースが指定できるほう）を使用して、PodMonitoring リソースと ClusterPodMonitoring リソースを自動的に作成し、管理できます。

   Terraform と Google Cloud を使用する場合の一般的な情報については、Google Cloud での Terraform をご覧ください。

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

   大量のデータを収集する場合は、費用を抑えるため、一部の時系列が Managed Service for Prometheus に送信されないようにする必要があります。これを行うには、Prometheus のラベル変更ルールで、許可リストの keep アクションまたは拒否リストの drop アクションを使用します。マネージド コレクションの場合、このルールは PodMonitoring または ClusterPodMonitoring リソースの metricRelabeling セクションにあります。

   たとえば、次の指標のラベル変更ルールは、foo_bar_、foo_baz_、または foo_qux_ で始まる指標を除外します。

     metricRelabeling:
     - action: drop
       regex: foo_(bar|baz|qux)_.+
       sourceLabels: [__name__]
   

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

   • 指標ドメイン全体と個々の指標での、バイトベースとサンプルベースの両方の課金に対する取り込み量。
   • 指標のラベルとカーディナリティに関するデータ。
   • 各指標の読み取り回数。
   • アラート ポリシーとカスタム ダッシュボードでの指標の使用。
   • 指標書き込みエラーの割合。

   また、指標の管理を使用して不要な指標を除外し、取り込みのコストを削減することもできます。[指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。

   費用を減らす方法については、費用管理とアトリビューションをご覧ください。

   Kubelet と cAdvisor の指標のスクレイピング

   Kubelet は、それ自体に関する指標と、ノード上で実行されているコンテナに関する cAdvisor の指標を公開します。OperatorConfig リソースを編集することで、Kubelet と cAdvisor の指標を取得するようにマネージド コレクションを構成できます。手順については、Kubelet と cAdvisor のエクスポータのドキュメントをご覧ください。

   既存の prometheus-operator リソースを変換する

   通常は、既存の prometheus-operator リソースを Prometheus 向けのマネージド サービスのマネージド コレクションの PodMonitoring リソースと ClusterPodMonitoring リソースに変換できます。

   たとえば、ServiceMonitor リソースは、一連のサービスのモニタリングを定義します。PodMonitoring リソースは、ServiceMonitor リソースによって提供されるフィールドのサブセットを処理します。次の表のようにフィールドをマッピングすることで、ServiceMonitor CR を PodMonitoring CR に変換できます。

   monitoring.coreos.com/v1 ServiceMonitor	互換性	monitoring.googleapis.com/v1 PodMonitoring
   .ServiceMonitorSpec.Selector	同一	.PodMonitoringSpec.Selector
   .ServiceMonitorSpec.Endpoints[]	.TargetPort は .Port にマッピングされます .Path: compatible .Interval: compatible .Timeout: compatible	.PodMonitoringSpec.Endpoints[]
   .ServiceMonitorSpec.TargetLabels	PodMonitor は以下を指定する必要があります。 .FromPod[].From Pod ラベル .FromPod[].To ターゲット ラベル	.PodMonitoringSpec.TargetLabels

   以下に、ServiceMonitor の CR の例を示します。太字のコンテンツは変換で置き換えられ、斜体のコンテンツは直接マッピングされます。

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - targetPort: web
       path: /stats
       interval: 30s
     targetLabels:
     - foo
   

   類似 PodMonitoring の CR は、サービスとその Pod に app=example-app ラベルが付いていることを前提としています。この前提を満たしていない場合は、基盤となる Service リソースのラベルセレクタを使用する必要があります。

   太字の部分が変換で置き換えられました。

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: example-app
   spec:
     selector:
       matchLabels:
         app: example-app
     endpoints:
     - port: web
       path: /stats
       interval: 30s
     targetLabels:
       fromPod:
       - from: foo # pod label from example-app Service pods.
         to: foo
   

   マネージド コレクタの代わりに自己デプロイ型のコレクタを使用すると、既存の prometheus-operator のリソースとデプロイ構成をいつでも使用できます。両方のコレクタタイプから送信される指標のクエリを実行できるため、既存の Prometheus デプロイにはセルフデプロイ コレクタを使用し、新しい Prometheus デプロイにはマネージド コレクタを使用できます。

   予約済みラベル

   Managed Service for Prometheus は、収集されたすべての指標に自動的に次のラベルを追加します。これらのラベルは、Monarch のリソースを一意に識別するために使用されます。

   • project_id: 指標に関連付けられた Google Cloud プロジェクトの ID。
   • location: データが保存される物理的な場所（Google Cloud リージョン）。通常、この値は GKE クラスタのリージョンです。AWS またはオンプレミス デプロイメントからデータが収集される場合、値は最も近い Google Cloud のリージョンになります。
   • cluster: 指標に関連付けられた Kubernetes クラスタの名前。
   • namespace: 指標に関連付けられた Kubernetes Namespace の名前。
   • job: Prometheus ターゲットのジョブラベル（既知の場合）。ルール評価の結果で空の場合もあります。
   • instance: Prometheus ターゲットのインスタンス ラベル（既知の場合）。ルール評価の結果で空の場合もあります。

   Google Kubernetes Engine で実行する場合はおすすめしませんが、project_id、location、cluster ラベルをオーバーライドするには、operator.yaml 内の Deployment リソースに、これらを args として追加します。予約済みラベルを指標ラベルとして使用する場合、Managed Service for Prometheus は、接頭辞 exported_ を追加して自動的に再度ラベル付けを行います。この動作は、アップストリーム Prometheus が予約済みラベルとの競合を処理する方法と一致します。

   構成を圧縮する

   PodMonitoring リソースが多いと、ConfigMap の容量が不足する可能性があります。この問題を解決するには、OperatorConfig リソースで gzip 圧縮を有効にします。

     apiVersion: monitoring.googleapis.com/v1
     kind: OperatorConfig
     metadata:
       namespace: gmp-public
       name: config
     features:
       config:
         compression: gzip
   

   マネージド コレクションの垂直 Pod 自動スケーリング（VPA）を有効にする

   クラスタ内のコレクタ Pod でメモリ不足（OOM）エラーが発生している場合や、コレクタのデフォルトのリソース リクエストと上限がニーズを満たしていない場合は、垂直 Pod 自動スケーリングを使用してリソースを動的に割り振ることができます。

   OperatorConfig リソースに scaling.vpa.enabled: true フィールドを設定すると、オペレーターはクラスタに VerticalPodAutoscaling マニフェストをデプロイします。これにより、コレクタ Pod のリソース リクエストと上限を使用状況に基づいて自動的に設定できます。

   Managed Service for Prometheus でコレクタ Pod の VPA を有効にするには、次のコマンドを実行します。

   kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge
   

   コマンドが正常に完了すると、オペレーターはコレクタ Pod の垂直 Pod 自動スケーリングを設定します。メモリ不足エラーが発生すると、リソースの上限が直ちに増加します。OOM エラーがない場合、通常は 24 時間以内にコレクタ Pod のリソース リクエストと上限が調整されます。

   VPA を有効にしようとすると、次のエラーが表示されることがあります。

   vertical pod autoscaling is not available - install vpa support and restart the operator

   このエラーを解決するには、まずクラスタレベルで垂直 Pod 自動スケーリングを有効にする必要があります。

   1. Google Cloud コンソールで [Kubernetes Engine - クラスタ] ページに移動します。

      Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

      [Kubernetes クラスタ] に移動

      検索バーを使用してこのページを検索した場合は、小見出しが [Kubernetes Engine] の結果を選択します。

   2. 変更するクラスタを選択します。

   3. [自動化] セクションで、[垂直 Pod 自動スケーリング] オプションの値を編集します。

   4. [垂直 Pod 自動スケーリングを有効にする] チェックボックスをオンにして、[変更を保存] をクリックします。この変更により、クラスタが再起動されます。このプロセスの一環としてオペレーターが再起動されます。

   5. 次のコマンド（kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge）を再試行して、Managed Service for Prometheus の VPA を有効にします。

   OperatorConfig リソースが正常に編集されたことを確認するには、kubectl -n gmp-public edit operatorconfig config コマンドを使用して開きます。成功すると、OperatorConfig に次のセクションが太字で追加されます。

   apiVersion: monitoring.googleapis.com/v1
   kind: OperatorConfig
   metadata:
     namespace: gmp-public
     name: config
   scaling:
     vpa:
       enabled: true
   

   垂直 Pod 自動スケーリングは、ノード間で均等に分割された一定数のサンプルを取り込む場合に最適です。指標の負荷が不規則または急増する場合、または指標の負荷がノード間で大きく異なる場合は、VPA が効率的なソリューションにならない可能性があります。

   詳細については、GKE での垂直 Pod 自動スケーリングをご覧ください。

   破棄

   gcloud または GKE UI を使用してデプロイされたマネージド コレクションを無効にするには、次のいずれかを行います。

   • 次のコマンドを実行します。

     gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus
     

   • GKE UI を使用します。

     1. Google Cloud コンソールで [Kubernetes Engine] を選択して、[クラスタ] を選択します。

     2. マネージド コレクションを無効にするクラスタを見つけて、その名前をクリックします。

     3. [詳細] タブの [機能] までスクロールし、編集ボタンを使用して状態を [無効] に変更します。

   Terraform を使用してデプロイされたマネージド コレクションを無効にするには、google_container_cluster リソースの managed_prometheus セクションで enabled = false を指定します。

   kubectl を使用してデプロイされたマネージド コレクションを無効にするには、次のコマンドを実行します。

   kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml
   

   マネージド コレクションを無効にすると、クラスタは Managed Service for Prometheus への新しいデータの送信を停止します。この操作を行っても、システムにすでに保存されている既存の指標データは削除されません。

   マネージド コレクションを無効にすると、gmp-public 名前空間と、その名前空間内のすべてのリソース（その名前空間にインストールされているエクスポータを含む）が削除されます。

   GKE の外部でマネージド コレクションを実行する

   GKE 環境では、さらなる構成なしでマネージド コレクションを実行できます。他の Kubernetes 環境では、認証情報、指標を格納する project-id 値、指標が保存される location 値（Google Cloud リージョン）、コレクタが実行されているクラスタの名前を保存する cluster の値を明示的に指定する必要があります。

   gcloud は Google Cloud 環境の外部では機能しないため、代わりに kubectl を使用してデプロイする必要があります。gcloud とは異なり、kubectl を使用してマネージド コレクションをデプロイしても、新しいバージョンが利用可能になったときに、クラスタが自動的にアップグレードされません。リリースページで新しいバージョンを確認し、新しいバージョンで kubectl コマンドを再実行して手動でアップグレードしてください。

   認証情報を明示的に指定するで説明されているように、operator.yaml 内の OperatorConfig リソースを変更して、サービス アカウント キーを指定できます。project-id、location、cluster の値は、operator.yaml 内の Deployment リソースに args として追加できます。

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

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

   cluster には、Operator がデプロイされているクラスタの名前を選択することをおすすめします。

   正しく構成されると、OperatorConfig は次のようになります。

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         credentials:
           name: gmp-test-sa
           key: key.json
       rules:
         credentials:
           name: gmp-test-sa
           key: key.json
   

   Deployment リソースは次のようになります。

   apiVersion: apps/v1
   kind: Deployment
   ...
   spec:
     ...
     template:
       ...
       spec:
         ...
         containers:
         - name: operator
           ...
           args:
           - ...
           - "--project-id=PROJECT_ID"
           - "--cluster=CLUSTER_NAME"
           - "--location=REGION"
   

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

   Google Cloud の外部で Managed Service for Prometheus を実行すると、データ転送料金が発生します。Google Cloud へのデータ転送には料金がかかります。また、別のクラウドからのデータ移転にも料金が発生する場合があります。OperatorConfig でワイヤー上の gzip 圧縮を有効にすると、これらの費用を最小限に抑えることができます。太字で示されているテキストをリソースに追加します。

       apiVersion: monitoring.googleapis.com/v1
       kind: OperatorConfig
       metadata:
         namespace: gmp-public
         name: config
       collection:
         compression: gzip
         ...
   

   マネージド コレクション カスタム リソースに関する関連情報

   Prometheus カスタム リソースのすべてのマネージド サービスに関するリファレンス ドキュメントについては、prometheus-engine/doc/api リファレンスをご覧ください。

   次のステップ

   • Cloud Monitoring で PromQL を使用して Prometheus 指標をクエリする。
   • Grafana を使用して Prometheus 指標をクエリする。
   • Cloud Monitoring で PromQL アラートを使用する。
   • マネージド ルールの評価を設定する。
   • よく使用されるエクスポータを設定する。