はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。
Google Cloud で好きなサービスは、圧倒的に Cloud Run です！

この投稿は AoTo Advent Calendar 2024 15日目の記事です。

皆さんは　Cloud Run の監視、きちんと行えているでしょうか？

Cloud Run は Google Cloud のマネージドサービスであり、デフォルトで Cloud Logging, Cloud Monitoring, Cloud Trace と統合されています。

ということは、Cloud Run service のメトリクス監視は Cloud Monitoring で自動的にできるから設計を考える必要がないのでしょうか？
いやいや、まだまだメトリクス監視は奥深いんです！

…ということで、Cloud Run service を利用されるすべての方に向けて、Google Cloud で利用できるデフォルト・オプションそれぞのメトリクス監視とを体系的にまとめてみました🐶

ちなみに Cloud Run 監視の基本は、「Cloud Run Advent Calendar 2023」で Google Cloud Japan の諏訪さんがまとめられています。

Cloud Run のリソースモデルと組み込みメトリクス

Cloud Run service はシンプルなマネージドコンテナホスティングサービス(Container as a Service, CaaS) です。Cloud Run service を頂点として、①サービス -> ②リビジョン -> ③インスタンス -> ④コンテナのように階層構造のリソースモデルを持ちます。

Cloud Monitoring では、Cloud Run service のそれぞれのリソース階層を対象にしたメトリクスを提供しています。

①サービス: リクエスト数・リクエストレイテンシー・リクエスト/レスポンスサイズ・クォータ
②リビジョン: リクエスト数・リクエストレイテンシー・リクエスト/レスポンスサイズ
③インスタンス: 課金対象の時間・起動数・コンテナ最大同時実行数・コンテナ起動時のレイテンシ
④コンテナ: CPU/メモリ割り当て時間・CPU/メモリ/GPU メモリ使用率・送受信バイト

ざっくりと各リソース階層に分類すると、このようになります。各リソースにおいて重要なメトリクスは概ね何も設定しなくても取得されるのが、Cloud Run がマネージドサービスである利点です。

これらのメトリクスは Google Cloud 公式ドキュメントでも「組み込み指標」として紹介されています。提供されているすべての「組み込み指標」は Google Cloud metrics(run) ページから確認できます。

Cloud Run のカスタムメトリクス監視

ここからは、追加のカスタムメトリクス監視として「Prometheus 指標」と「OpenTelemetry 指標」を詳しく解説します。どちらも Cloud Native Computng Foundation(CNCF) から生まれた、メトリクスを扱うオープンソースプロジェクトです。

Google Cloud Managed Service for Prometheus

メインアプリケーションコンテナから生成されたそれぞれのカスタムメトリクスは、サイドカー(マルチコンテナ)デプロイメントで用意された監視エージェントコンテナにより収集・転送され Cloud Monitoring 上で可視化できます。

Google Cloud Managed Service for Prometheus(Google Managed Prometheus, GMP) は Cloud Monitoring ingest API を利用して、Prometheus 形式のメトリクスを受け取ることができます。こうしたメトリクスは Monarch と呼ばれる分散型インメモリ時系列データベースに保管され、堅牢で高効率なインフラストラクチャーによる Prometheus マネージドサービスが提供されています。

GMP は Cloud Monitoring と緊密に統合されているため、利用時にはサービスの存在を意識することはありません。Google Cloud Console 上での Cloud Monitoring や、Cloud Monitoring API の利用時に Prometheus 形式のメトリクスや PromQL クエリを利用する場合に、内部的に GMP や Monarch が用意されています。

Prometheus メトリクス

`RunMonitoring` の構成

Prometheus メトリクスを収集する場合には、既存のアプリケーションコンテナからサイドカーコンテナが pull 型でメトリクスエンドポイントからメトリクス情報をスクレイピングして取得します。

こうした Prometheus メトリクスエンドポイントの構成を行うのが RunMonitoring です。これは、Kubernetes PodMonitoring から Kubernetes 固有のオプションを除外し、Cloud Run で必要な構成だけをサポートしたサブセットです。

Cloud Run は kind: Service で Knative Serving 互換構成のコンテナのみを扱います。そのため、この kind: RunMonitoring 構成は監視エージェントコンテナの /etc/rungmp/ に config.yaml として配置して、コンテナ構成の定義として直接参照する必要があります。特に指定がない場合、RunMonitoring は /metrics のポート 8080 から30秒ごとにメトリクスをスクレイピングします。

カスタム RunMonitoring 構成により、スクレイピング用のエンドポイントとポートなどの構成をカスタムで定義できます。構成できるオプションは『Cloud Run で GMP を利用する際の注意点』で解説しています。

カスタム RunMonitoring 構成ファイル config.yaml を作成したら、Google Cloud Secret Manager シークレットとして config.yaml を格納します。そのシークレットを、Cloud Run のrun-service.yaml に直接 volumes: としてマウントし、Cloud Run の RunMonitoring 構成ファイルとして使用します。¹

run-service.yaml

spec:
  template:
    metadata:
      annotations:
        (中略)
+       run.googleapis.com/secrets: 'mysecret:projects/PROJECT_ID/secrets/mysecret'
    spec:
      containers:
      　(中略)
+     volumes:
+     - name: config
+       secret:
+         items:
+         - key: latest
+           path: config.yaml
+         secretName: 'mysecret'

監視エージェントコンテナの構成

前述の RunMonitoring 構成に従って Prometheus メトリクスを取得する監視エージェントコンテナは、cloud-run-gmp-sidecar/collector として公開されています。

cloud-run-gmp-sidecar/collector で構成されている内容を確認すると、Prometheus メトリクスは OpenTelemetry Collector の Prometheus Receiver によって取得されます。その後、同じく OpenTelemetry Collector の Google Managed Service for Prometheus Exporter が GMP への転送を担います。

OpenTelemetry メトリクス

OpenTelemetry メトリクスを取得する際は、OpenTelemetry Collector の構成とデプロイのみで一連の収集・制御・転送が実現できます。Googl Cloud 公式サンプルでは、カスタム OpenTelemetry Collector をビルドする案内があります。

このカスタム OpenTelemetry Collector は、OTLP Receiver, Batch Processor, Google Managed Service for Prometheus Exporter を基本に、Memory Limiter, Resource Detection, ResourceMemory Limiter, Resource Detection, Resource などの Processor を構成しています。

カスタム OpenTelemetry Collector を作成したことない場合は、逆井(@k6s4i53rx)さんの『OpenTelemetry Collector Builder (ocb) を使ってお好みの OTel Collector を作る』をご参考ください。

番外編: ログベースメトリクス

Cloud Run に限った話ではないですが、Cloud Monitoring では収集したログをもとにログベースメトリクスを作成できます。

この機能では、特定の条件に合致するログを集計しメトリクス化することで、特定の期間における特定のログの発生頻度を可視化できます。また、ログベースメトリクスを条件としたグラフやアラートを簡単に設定できる点も大きなポイントです。

ログベースメトリクスは Logging のクエリ言語に基づいてフィルタリングされたログの数を対象の時間範囲に対して測定するカウンタメトリクスと、フィルタリングされたログ内のフィールドの数値の分布を記録する分布メトリクスを作成できます。

Cloud Run の特定のサービスを対象としたログを元にメトリクスを作成する場合は、以下のようにフィルタリングできます。

logging.ebnf

resource.type = "cloud_run_revision"
resource.labels.service_name = "<SERVICE_NAME>"
resource.labels.location = "<REGION_NAME>"
 severity >= DEFAULT

おわりに

Cloud Run service で利用できるメトリクス監視の様々なオプションを、図解されたアーキテクチャと具体的な実装方法に触れながら解説しました。

Cloud Run service はマルチコンテナ対応によって Prometheus, OpenTelmetry メトリクスの Google Managed Service for Prometheus への連携ができるようになりました。これらの実装方法を詳しく知っておくことで、今後 Cloud Run 上でメトリクスを測定・収集しサービスの信頼性を向上することができるはずです🐶

Cloud Run 第二世代では、マウントされたボリュームは Cloud Run コンテナインスタンスの root が所有します。 ↩