Cloud Run 用の Prometheus サイドカーを使用する

Cloud Run 用の Managed Service for Prometheus サイドカーは、Cloud Run サービスで Prometheus スタイルのモニタリングを行うために Google が推奨する方法です。Cloud Run サービスが OTLP 指標を書き込む場合は、OpenTelemetry サイドカーを使用できます。ただし、Prometheus 指標を書き込むサービスの場合は、このドキュメントで説明する Managed Service for Prometheus サイドカーを使用してください。

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

サイドカーは、サーバー側で Google Cloud Managed Service for Prometheus を使用し、クライアント側でサーバーレス ワークロード用にカスタムビルドされた OpenTelemetry Collector のディストリビューションを使用します。このカスタム ディストリビューションには、Cloud Run をサポートするための変更が含まれています。コレクタは、10 秒後に起動時のスクレイピングを実行し、インスタンスの持続期間がどれほど短くてもシャットダウン スクレイピングを実行します。信頼性を最大限に高めるため、サイドカーを実行する Cloud Run サービスでも、常に割り当てられる CPU を使用することをおすすめします。詳細については、CPU 割り当て(サービス)をご覧ください。秒間クエリ数(QPS)が少ないために CPU の割り当てが抑制されている場合、一部のスクレイピングの試行が失敗する可能性があります。常に割り当てられる CPU は引き続き使用できます。

サイドカーは、Cloud Run マルチコンテナ(サイドカー)機能を使用して、ワークロード コンテナとともにサイドカー コンテナとしてコレクタを実行します。Cloud Run のサイドカーの詳細については、複数のコンテナをサービスにデプロイする(サイドカー)をご覧ください。

Cloud Run 用の Managed Service for Prometheus サイドカーには、Kubernetes PodMonitoring カスタム リソースのサブセットである新しい構成 RunMonitoring が導入されています。ほとんどのユーザーはデフォルトの RunMonitoring 構成で十分ですが、カスタム構成を作成することもできます。デフォルトの構成とカスタム RunMonitoring 構成の詳細については、Cloud Run サービスにサイドカーを追加するをご覧ください。

始める前に

このセクションでは、このドキュメントを使用するために必要な設定について説明します。

gcloud CLI をインストールして構成する

このドキュメントで説明する手順の多くは、Google Cloud CLI を使用します。gcloud CLI のインストールについては、Google Cloud CLI コンポーネントの管理をご覧ください。

gcloud コマンドを呼び出すときに、Google Cloud プロジェクトの ID を指定する必要があります。Google Cloud CLI のデフォルト プロジェクトを設定すると、すべてのコマンドでプロジェクトを指定する必要がなくなります。プロジェクトをデフォルトとして設定するには、次のコマンドを入力します。

gcloud config set project PROJECT_ID

Cloud Run サービスのデフォルト リージョンを設定することもできます。デフォルトのリージョンを設定するには、次のコマンドを入力します。

gcloud config set run/region REGION

API を有効にする

Google Cloud プロジェクトで次の API を有効にする必要があります。

  • Cloud Run Admin API: run.googleapis.com
  • Artifact Registry API: artifactregistry.googleapis.com
  • Cloud Monitoring API: monitoring.googleapis.com
  • Cloud Logging API: logging.googleapis.com
  • (省略可)カスタム RunMonitoring 構成を作成する場合は、Secret Manager API secretmanager.googleapis.com を有効にする必要があります。
  • (省略可)Cloud Build を使用してサンプルアプリを実行する場合は、次の API も有効にする必要があります。

プロジェクトで有効になっている API を確認するには、次のコマンドを実行します。

gcloud services list

有効になっていない API を有効にするには、次のいずれかのコマンドを実行します。

gcloud services enable run.googleapis.com
gcloud services enable artifactregistry.googleapis.com
gcloud services enable secretmanager.googleapis.com
gcloud services enable monitoring.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable cloudbuild.googleapis.com
gcloud services enable iam.googleapis.com

Cloud Run のサービス アカウント

デフォルトでは、Cloud Run のジョブとサービスは Compute Engine のデフォルトのサービス アカウント PROJECT_NUMBER-compute@developer.gserviceaccount.com を使用します。このサービス アカウントには通常、このドキュメントで説明する指標とログの書き込みに必要な Identity and Access Management(IAM)のロールが付与されています。

  • roles/monitoring.metricWriter
  • roles/logging.logWriter

カスタム RunMonitoring 構成を作成する場合は、サービス アカウントに次のロールも必要です。

  • roles/secretmanager.admin
  • roles/secretmanager.secretAccessor

Cloud Run のユーザー管理サービス アカウントを構成することもできます。ユーザー管理のサービス アカウントには、これらのロールも必要です。Cloud Run のサービス アカウントの詳細については、サービス ID の構成をご覧ください。

サイドカーを構成して Cloud Run サービスに追加する

Cloud Run 用の Managed Service for Prometheus サイドカーには、Kubernetes PodMonitoring カスタム リソースのサブセットである新しい構成 RunMonitoring が導入されています。RunMonitoring 構成では、既存の PodMonitoring オプションを使用して Cloud Run をサポートし、Kubernetes 固有のオプションを除外しています。

デフォルトの RunMonitoring 構成を使用することも、カスタム構成を作成することもできます。以降のセクションでは、この両方の方法について説明します。両方を行う必要はありません。デフォルト構成またはカスタム構成の使用方法については、対応するタブを選択してください。

デフォルト構成

デフォルトの RunMonitoring 構成を使用する

カスタム RunMonitoring 構成を作成しない場合、サイドカー コレクタは次のデフォルト構成を合成して、/metrics 指標パスのポート 8080 から 30 秒ごとに指標をスクレイピングします。

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: run-gmp-sidecar
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 30s

デフォルト構成を使用する場合、Cloud Run サービスにサイドカーを追加する以外の追加設定は必要ありません。

Cloud Run サービスにサイドカーを追加する

デフォルトの RunMonitoring 構成でサイドカーを使用するには、既存の Cloud Run 構成を変更してサイドカーを追加する必要があります。サイドカーを追加するには、次の操作を行います。

  • コンテナの起動とシャットダウンの順序を指定するコンテナ依存関係アノテーションを追加します。次の例では、collector という名前のサイドカー コンテナが、app という名前のアプリケーション コンテナの後に起動し、その後シャットダウンします。
  • コレクタのコンテナを作成します。次の例では collector という名前にしています。

たとえば、+(プラス)記号で始まる行を Cloud Run 構成に追加して、サービスを再デプロイします。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
+       name: collector

構成ファイル run-service.yaml を使用して Cloud Run サービスを再デプロイするには、次のコマンドを実行します。

gcloud run services replace run-service.yaml --region=REGION

カスタム構成

カスタム RunMonitoring 構成を作成する

デフォルトの構成では不十分な場合は、Cloud Run サービスの RunMonitoring 構成を作成できます。たとえば、次のような構成を作成できます。

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

この構成では、次の処理が行われます。

  • ポート 8080 から指標を取得し、デフォルトの指標パス /metrics を使用します。
  • 10 秒のスクレイピング間隔を使用します。
  • ラベルの付け直しを行い、スクレイピングされたすべての指標に、値が label_value のラベル label_key を追加します。
  • スクレイピングされたすべての指標に service メタデータ ラベルと revision メタデータ ラベルを追加します。

使用可能な構成オプションについては、RunMonitoring 仕様: 構成オプションをご覧ください。

カスタム RunMonitoring 構成を使用する場合は、次の追加構成を行う必要があります。

Secret Manager を使用して構成を保存する

カスタム RunMonitoring 構成を用意するには、次の操作を行います。

  • カスタム構成を含むファイルを作成します。
  • カスタム構成を含む Secret Manager シークレットを作成します。

次のコマンドでは、custom-config.yaml ファイルから mysecret という名前のシークレットを作成します。

gcloud secrets create mysecret --data-file=custom-config.yaml

custom-config.yaml ファイルの変更後に構成の変更を反映するには、シークレットを削除して再作成してから、Cloud Run サービスを再デプロイする必要があります。

Secret Manager での構成の更新

カスタム RunMonitoring 構成をいつでも更新できるようにするには、既存の Secret の新しいバージョンを Secret Manager に追加します。

たとえば、ファイル custom-config-updated.yaml に保存された新しい構成で mysecret を更新するには、次のコマンドを実行します。

gcloud secrets versions add mysecret --data-file=custom-config-updated.yaml

サイドカーが自動的に再読み込みされ、変更が構成に適用されます。

Cloud Run サービスにサイドカーを追加する

RunMonitoring 構成の Secret Manager シークレットを作成したら、Cloud Run の構成を次のように変更する必要があります。

  • Managed Service for Prometheus サイドカーを追加します。
    • コンテナの起動とシャットダウンの順序を指定するコンテナ依存関係アノテーションを追加します。次の例では、collector という名前のサイドカー コンテナが、app という名前のアプリケーション コンテナの後に起動し、その後シャットダウンします。
    • コレクタのコンテナを作成します。次の例では collector という名前にしています。
  • シークレットをロケーション /etc/rungmp/config.yaml にマウントして追加します。
    • カスタム RunMonitoring 構成を保持するシークレットを参照するシークレット アノテーションを追加します。
    • ファイル config.yaml を参照するシークレット用に、次の例では config という名前のボリュームを作成します。
    • コレクタ イメージの一部としてボリュームをマウントパス /etc/rungmp にマウントします。

たとえば、+(プラス)記号で始まる行を Cloud Run 構成に追加して、サービスを再デプロイします。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
+       run.googleapis.com/container-dependencies: '{"collector":["app"]}'
+       run.googleapis.com/secrets: 'mysecret:projects/PROJECT_ID/secrets/mysecret'
    spec:
      containers:
      - image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
+     - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
+       name: collector
+       volumeMounts:
+       - mountPath: /etc/rungmp/
+         name: config
+     volumes:
+     - name: config
+       secret:
+         items:
+         - key: latest
+           path: config.yaml
+         secretName: 'mysecret'

構成ファイル run-service.yaml を使用して Cloud Run サービスを再デプロイするには、次のコマンドを実行します。

gcloud run services replace run-service.yaml --region=REGION

RunMonitoring 仕様: 構成オプション

このセクションでは、Managed Service for Prometheus サイドカーの RunMonitoring 構成仕様について説明します。カスタム構成の例を次に示します。

apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
  name: my-custom-cloud-run-job
spec:
  endpoints:
  - port: 8080
    path: /metrics
    interval: 10s
    metricRelabeling:
    - action: replace
      sourceLabels:
      - __address__
      targetLabel: label_key
      replacement: label_value
  targetLabels:
    metadata:
    - service
    - revision

RunMonitoring

RunMonitoring 構成は、Cloud Run サービスをモニタリングします。

フィールド 説明 スキーム 必須
metadata すべての永続リソースに必要となるメタデータ。 metav1.ObjectMeta false
spec Prometheus によるターゲット探索用に選択された Cloud Run デプロイの仕様。 RunMonitoringSpec true
RunMonitoringSpec

この仕様では、RunMonitoring 構成で Cloud Run サービスをモニタリングする方法を記述します。

フィールド 説明 スキーム 必須
endpoints 選択した Pod でスクレイピングするエンドポイント。 []ScrapeEndpoint true
targetLabels 検出されたエンドポイントの Prometheus ターゲットに追加するラベル。instance ラベルは常に Cloud Run インスタンス ID に設定されます。 RunTargetLabels false
limits スクレイピング時に適用される制限。 *ScrapeLimits false
RunTargetLabels

RunTargetLabels 構成を使用すると、検出された Prometheus ターゲットの Cloud Run ラベルを含めることができます。

フィールド 説明 スキーム 必須
metadata すべてのスクレイピングされたターゲットに設定されている Cloud Run メタデータ ラベル。

許可されるキーは、instancerevisionserviceconfiguration です。

許可されるキーが設定されている場合、サイドカーは Cloud Run インスタンスの対応する値(instanceIDrevision_nameservice_nameconfiguration_name)を指標ラベルとしてすべての指標に追加します。

デフォルトでは、許可されるすべてのキーが設定されます。
*[]string false

サンプルアプリをビルドして実行する

このセクションでは、サンプルアプリを使用して Managed Service for Prometheus サイドカーを実行する方法について説明します。このセクションは省略可能です。Cloud Run サービスがすでにあり、そのサービスと一緒にサイドカーをデプロイする場合は、Managed Service for Prometheus サイドカーを Cloud Run サービスに追加するをご覧ください。

run-gmp-sidecar リポジトリのクローンを作成する

サンプルアプリとその構成ファイルを取得するには、次のコマンドを実行して run-gmp-sidecar リポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/run-gmp-sidecar/

リポジトリのクローンを作成したら、run-gmp-sidecar ディレクトリに移動します。

cd run-gmp-sidecar

サンプルアプリをビルドして実行する

サンプルアプリを実行するには、Linux 用の Docker または同様のコンテナ ビルドシステムが必要です。次のいずれかの方法でサンプルアプリをビルドして実行できます。

  • Cloud Build を使用すると、ローカルの Docker サポートなしで実行できます。Cloud Build を使用する場合は、Cloud Build API を有効にする必要があります。
  • サンプルアプリを手動でビルドして実行します。

以降のセクションでは、この両方の方法について説明します。両方を行う必要はありません。詳細については、いずれかの方法のタブを選択してください。

Cloud Build を使用する

Cloud Build を使用する

run-gmp-sidecar リポジトリには、Cloud Build の構成ファイルが含まれています。これらのファイルには、サンプルアプリのビルドとデプロイに必要なステップがバンドルされています。

Cloud Build によって処理されるステップを手動で実行することもできます。詳細については、手動でビルドして実行するをご覧ください。

Cloud Build 用に設定する

これらの構成ファイルを使用するには、Cloud Build サービス アカウントと Artifact Registry リポジトリが必要です。run-gmp-sidecar リポジトリには、次の処理を行うスクリプト create-sa-and-ar.sh も含まれています。

  • サービス アカウント run-gmp-sa@PROJECT_ID.iam.gserviceaccount.com を作成します。
  • サービス アカウントに次のロールを付与します。
    • roles/iam.serviceAccountUser
    • roles/storage.objectViewer
    • roles/logging.logWriter
    • roles/artifactregistry.createOnPushWriter
    • roles/secretmanager.admin
    • roles/secretmanager.secretAccessor
    • roles/run.admin
  • コンテナ イメージ用の Artifact Registry リポジトリ run-gmp を作成します。

run-gmp-sa サービス アカウントと run-gmp リポジトリを作成するには、次のコマンドを実行します。

./create-sa-and-ar.sh

権限が反映されるまでに時間がかかります。30 秒ほど待ってから次のステップに進むことをおすすめします。そうしないと、承認エラーが表示されることがあります。

Cloud Build リクエストを送信する

run-gmp-sa サービス アカウントと run-gmp リポジトリを設定したら、Cloud Build 構成ファイルを送信して Cloud Build ジョブを開始できます。次の gcloud builds submit コマンドを使用できます。

gcloud builds submit . --config=cloudbuild-simple.yaml --region=REGION

このコマンドの実行には数分かかりますが、Cloud Build ビルドの詳細を確認できる場所がすぐに表示されます。次のようなメッセージが表示されます。

Logs are available at [
https://console.cloud.google.com/cloud-build/builds/637860fb-7a14-46f2-861e-09c1dc4cea6b?project=PROJECT_NUMBER].

ビルドの進行状況を確認するには、ブラウザで、返された URL に移動します。Cloud Logging でサイドカーのログを確認することもできます。

サービスの URL を確認する

Cloud Build ジョブが終了したら、次のコマンドを実行して Cloud Run サービスのエンドポイント URL を確認します。

gcloud run services describe my-cloud-run-service --region=REGION --format="value(status.url)"

このコマンドは、次のようなサービス URL を返します。

https://my-cloud-run-service-abcdefghij-ue.a.run.app

この URL は、アプリが実行されていることを確認するSERVICE_URL の値として使用します。

手動でビルドして実行する

手動でビルドして実行する

Cloud Build を使用するで説明しているように、Cloud Build によって処理されるステップを手動で実行することもできます。以降のセクションでは、同じタスクを手動で実行する方法について説明します。

後のステップで使用する変数を設定する

以降のいくつかのステップでは、共通の値として環境変数を使用します。これらの変数を設定するには、次のコマンドを使用します。

export GCP_PROJECT=PROJECT_ID
export REGION=REGION

コンテナ イメージ リポジトリを作成する

次のコマンドを実行して、コンテナ イメージの Artifact Registry リポジトリを作成します。

gcloud artifacts repositories create run-gmp \
    --repository-format=docker \
    --location=${REGION}

サンプルアプリをビルドして push する

この例では、Linux で Docker を使用してサンプルアプリをビルドし、Artifact Registry リポジトリに push します。Windows または macOS 環境で作業している場合は、これらのコマンドの調整が必要になることがあります。

サンプルアプリをビルドして Artifact Registry に push するには、次の操作を行います。

  1. Google Cloud CLI を使用して Docker クライアントを認証します。

    gcloud auth configure-docker ${REGION}-docker.pkg.dev
    
  2. run-gmp-sidecar リポジトリの simple-app ディレクトリに移動します。

    pushd sample-apps/simple-app
    

  3. 次のコマンドを実行して、simple-app アプリをビルドします。

    docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .
    
  4. 次のコマンドを実行して、ビルド済みアプリのイメージを push します。

    docker push ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app
    

  5. run-gmp-sidecar ディレクトリに戻ります。

    popd
    

Cloud Run サービスを構成する

run-gmp-sidecar リポジトリの run-service-simple.yaml ファイルは、前の手順でビルドしたサンプルアプリとコレクタ イメージを使用するマルチコンテナ Cloud Run サービスを定義します。run-service-simple.yaml ファイルには、次の Service 仕様が含まれています。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  annotations:
    run.googleapis.com/launch-stage: ALPHA
    run.googleapis.com/cpu-throttling: 'false'
  name: my-cloud-run-service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/execution-environment: gen2
        run.googleapis.com/container-dependencies: '{"collector":["app"]}'
    spec:
      containers:
      - image: "%SAMPLE_APP_IMAGE%"
        name: app
        startupProbe:
          httpGet:
            path: /startup
            port: 8000
        livenessProbe:
          httpGet:
            path: /liveness
            port: 8000
        ports:
        - containerPort: 8000
      - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.1.1"
        name: collector

このファイルには、前の手順で作成したイメージのプレースホルダ値が含まれているため、Google Cloud プロジェクトの実際の値でプレースホルダを更新する必要があります。

次のコマンドを実行して、%SAMPLE_APP_IMAGE% プレースホルダを置き換えます。

sed -i s@%SAMPLE_APP_IMAGE%@REGION-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app@g run-service-simple.yaml

Cloud Run サービスをデプロイする

値で run-service-simple.yaml ファイルを更新したら、次のコマンドで Cloud Run サービスを作成してデプロイできます。

gcloud run services replace run-service-simple.yaml --region=REGION
   

このコマンドは、次のようなサービス URL を返します。

https://my-cloud-run-service-abcdefghij-ue.a.run.app

この URL は、アプリが実行されていることを確認するSERVICE_URL の値として使用します。

未認証の HTTP アクセスを許可する

サービス URL にリクエストを送信するには、未認証の HTTP アクセスを受け入れるように Cloud Run サービス ポリシーを変更する必要があります。run-gmp-sidecar リポジトリの policy.yaml ファイルには、必要な変更が含まれています。

サービス ポリシーを変更するには、次のコマンドを実行します。

gcloud run services set-iam-policy my-cloud-run-service policy.yaml --region=REGION

アプリが実行されていることを確認する

Cloud Run サービスがサンプルアプリを正しく実行していることを確認するには、curl ユーティリティを使用して、サービスの metrics エンドポイントにアクセスします。

  1. SERVICE_URL 環境変数に、前のステップの Cloud Run サービスの URL を設定します。

    export SERVICE_URL=SERVICE_URL
    
  2. 次のコマンドを実行して、サービス URL にリクエストを送信します。

    curl $SERVICE_URL
    

アプリが正常に起動すると、次のレスポンスが表示されます。

User request received!

Metrics Explorer でアプリの指標を表示する

サンプルの app コンテナは、次の指標を書き込みます。

  • foo_metric: 現在の時刻を浮動小数点値(ゲージ)で記録します。
  • bar_metric: 現在の時刻を浮動小数点値(カウンタ)として記録します。

これらの指標を Metrics Explorer で表示するには、次の操作を行います。

  1. Google Cloud コンソールで、[Metrics explorer] ページに移動します。

    Metrics Explorer に移動

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

  2. クエリビルダー ペインのツールバーで、[MQL] または [PROMQL] という名前のボタンを選択します。

  3. [言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定と同じツールバーにあります。

  4. 次のクエリをエディタに入力します。

    foo_metric
    
  5. [クエリを追加] をクリックします。

  6. クエリビルダー ペインのツールバーで、[MQL] または [PROMQL] という名前のボタンを選択します。

  7. [言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定と同じツールバーにあります。

  8. 2 番目のエディタペインに次のクエリを入力します。

    bar_metric
    
  9. [クエリを実行] をクリックします。

  10. 指標の詳細を表示するには、[Chart Table both] というラベルが付いた切り替えで、[Both] を選択します。

クリーンアップ

サンプルアプリのテストが完了したら、run-gmp-sidecar リポジトリの clean-up-cloud-run.sh スクリプトを使用して、サンプル用に作成した次のリソースを削除できます。

  • Cloud Run サービス。
  • Artifact Registry リポジトリ。
  • Cloud Build 用に作成されたサービス アカウント。

これらのリソースを削除することで、サンプル実行後の費用の発生を防ぐことができます。

サンプルアプリをクリーンアップするには、clean-up-cloud-run.sh スクリプトを実行します。

./clean-up-cloud-run.sh

Metrics Explorer でセルフ指標を表示する

Managed Service for Prometheus サイドカーは、次の指標を Cloud Monitoring に報告します。

  • agent_uptime: サイドカー コレクタの稼働時間(カウンタ)。
  • agent_memory_usage: サイドカー コレクタによって消費されているメモリ(ゲージ)。
  • agent_api_request_count: サイドカー コレクタからの API リクエストの数(カウンタ)。
  • agent_monitoring_point_count: サイドカー コレクタによって Cloud Monitoring に書き込まれた指標ポイントの数(カウンタ)。

Metrics Explorer でサイドカーのセルフ指標を表示するには、次の操作を行います。

  1. Google Cloud コンソールで、[Metrics explorer] ページに移動します。

    Metrics Explorer に移動

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

  2. クエリビルダー ペインのツールバーで、[MQL] または [PROMQL] という名前のボタンを選択します。

  3. [言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定と同じツールバーにあります。

  4. クエリする指標の名前をエディタペインに入力します。次に例を示します。

    agent_api_request_count
    
  5. [クエリを実行] をクリックします。

  6. 指標の詳細を表示するには、[Chart Table both] というラベルが付いた切り替えで、[Both] を選択します。

ログ エクスプローラでセルフログを表示する

Managed Service for Prometheus サイドカーは、Cloud Logging にログを書き込みます。サイドカーは、Logging のモニタリング対象リソースタイプ cloud_run_revision に対するログを書き込みます。

ログ エクスプローラでサイドカーのログを表示するには、次の操作を行います。

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

  2. リソースタイプで [Cloud Run のリビジョン] を選択するか、次のクエリを入力して [クエリを実行] をクリックします。

    resource.type="cloud_run_revision"
    

収集された指標について

サイドカーによって出力された指標が Cloud Monitoring に取り込まれると、Cloud Monitoring の prometheus_target モニタリング対象リソースタイプに対する指標が書き込まれます。このリソースタイプは、アプリケーション指標とサイドカーのセルフ指標の両方に使用されます。

指標を書き込むときに、サイドカーはリソースラベルを次のように設定します。

  • project_id: コンテナが実行されている Google Cloud プロジェクトの ID。
  • location: コンテナが実行されている Google Cloud リージョン。
  • cluster: __run__ 値。
  • namespace: 実行中の Cloud Run サービスの名前。K_SERVICE 環境変数から取得されます。
  • job: RunMonitoring 構成の名前。デフォルトは run-gmp-sidecar です。
  • instance: コンテナが指標を pull するように構成されているローカル ワークロードの faas.ID:PORT 値。faas.ID 値は、Cloud Run インスタンスのインスタンス ID です。

サイドカーは、次の指標ラベルも追加します。

  • instanceId: Cloud Run インスタンスの ID。
  • service_name: 実行されている Cloud Run サービスの名前。
  • revision_name: 実行されている Cloud Run リビジョンの名前。
  • configuration_name: 実行されている Cloud Run 構成の名前。

これらの指標ラベルはすべてデフォルトで追加されます。カスタム RunMonitoring 構成を使用する場合は、RunMonitoring 仕様の targetLabels オプションを使用して、service_namerevision_nameconfiguration_name ラベルを省略できます。カスタム構成を使用して、service_namerevision_nameconfiguration_name ラベルの値を割り当て直すこともできます。

取り込まれた指標と一緒に表示される他のラベルはすべてユーザーの指標から取得されます。ユーザー定義のラベルがシステム提供のラベルと競合する場合、ユーザー定義のラベルの先頭に文字列 exported_ が追加されます。たとえば、ユーザー指定のラベル namespace="playground" はシステム定義の namespace ラベルと競合するため、ユーザーラベルは exported_namespace="playground" と表示されます。

指標タイプ

サイドカーによって出力された指標が Cloud Monitoring に取り込まれると、指標は prometheus.googleapis.com 指標として書き込まれ、Prometheus 指標のタイプが名前の末尾に追加されます。たとえば、サンプルアプリは foo_metric という名前の Prometheus ゲージ指標を出力します。Cloud Monitoring で、この指標は指標タイプ prometheus.googleapis.com/foo_metric/gauge として保存されます。

PromQL で指標をクエリする場合は、Metrics Explorer でアプリの指標を表示するMetrics Explorer でセルフ指標を表示するに示すように、Prometheus での名前を使用できます。Metrics Explorer でクエリビルダーや Monitoring Query Language(MQL)などのツールを使用する場合は、Cloud Monitoring 指標タイプのほうが適しています。

課金

サイドカーによって出力された指標は、先頭に prometheus.googleapis.com が付き、Cloud Monitoring に取り込まれます。この接頭辞を持つ指標は、取り込まれたサンプル数に応じて課金されます。課金と Managed Service for Prometheus の詳細については、課金をご覧ください。