G-gen の杉村です。Google Cloud のリソースモニタリングのためのプロダクトである、Cloud Monitoring を解説します。

Cloud Monitoring の概要
- Cloud Monitoring とは
- Cloud Monitoring の料金
リソースモニタリング
Ops エージェント
ダッシュボード
アラート
稼働時間チェック
Prometheus Query Language（PromQL）

Cloud Monitoring の概要

Cloud Monitoring とは

Cloud Monitoring は Google Cloud（旧称 GCP）の Google Cloud Observability と呼ばれるサービス群の1つで、各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービスです。データ収集元として、Google Cloud の各種サービスのほか、オンプレミスや Amazon Web Services （AWS）上の仮想サーバなども対象にすることができます。

参考 : Cloud Monitoring の概要

Cloud Monitoring では、デフォルトで収集するデータ（後述の「Google Cloud の指標」など）に対しては課金されず、基本機能は無料で使用することができます。

なお Google Cloud Observability はかつてはオペレーションスイート、その前は Google Stackdriver と呼称されていましたが、改称されました。

参考 : Google Cloud のオブザーバビリティ

Cloud Monitoring の料金

Cloud Monitoring は、多くの場合で無料で利用することができます。

Google Cloud がデフォルトで収集する指標（メトリクス）については、課金は発生しません。ユーザーが Ops Agent で収集する追加指標やカスタム指標は、収集したバイト数あるいはサンプル数に応じて課金されます。

課金対象メトリクスも、最初の 150 MB は毎月無料ですが、それ移行は $0.2580/MB が発生します（2025年4月現在の単価）。数台〜十数台の VM の Ops Agent 追加指標程度であれば、無料範囲内に収まる可能性があります。

また、Cloud Monitoring API にリクエストした階数や、稼働時間チェック機能などにも、料金が設定されています。

最新の料金は、以下のドキュメントを参照してください。

参考 : Google Cloud Observability の料金

リソースモニタリング

Google Cloud の指標

Cloud Moniitoring は、Compute Engine や Cloud SQL、 Cloud Storage のバケットなど、あらゆる Google Cloud リソースから指標（メトリクス）を収集します。

取得できる指標は、Compute Engine や Cloud SQL の場合、CPU 使用率やネットワーク I/O、Cloud Storage ならば API リクエスト数や総使用バイト数などです。

標準的な指標は、利用者が何も設定しなくても、自動的に収集されます。自動的に収集される指標については、課金は発生しません。このような自動的に収集される指標を、Google Cloud の指標といいます。

収集された指標は、Cloud Monitoring コンソール画面の Metrics Explorer 画面や、各サービス側のリソースの画面等で閲覧することができます。

参考 : Metrics Explorer でグラフを作成する

Google Cloud の指標の一覧は、以下の公式ドキュメントを参照してください。

参考 : Google Cloud metrics

カスタム指標

ユーザー独自の指標としてカスタム指標を収集して、Cloud Monitoring API に送信することができます。

Google Cloudの指標や Ops エージェントの指標は画一的なものであり、アプリケーションの負荷やユーザー体験の状況を正確に反映していない可能性があります。

CPU 使用率やメモリ使用率が上がっているからといって、ユーザーが処理を待たされていることを確実に示しているわけではないですし、逆に CPU 使用率やメモリ使用率に余裕があっても逆のことがありえます。システムのパフォーマンス実態を示す独自の指標があれば、正確に状況を反映し、スケールアクションなどに繋げることができます。

カスタム指標を収集するには、Cloud Monitoring の Web API に直接データを送信する方法と、オープンソースのライブラリである OpenCensus を使って Cloud Monitoring に送信する方法があります。詳細は以下のドキュメントをご参照ください。

参考 : ユーザー定義指標の概要

複数のプロジェクトの指標を表示する

指標スコープを構成することで、複数のプロジェクトの指標を単一の画面で表示することができます。

ある Google Cloud プロジェクトを、複数プロジェクトの Cloud Monitoring 指標を横断して表示するためのハブとして決めて、そのプロジェクトの指標スコープに、監視対象のプロジェクトを追加することで、複数プロジェクトの指標を横断して閲覧できます。このとき、ハブとなるプロジェクトをスコーピングプロジェクトと呼びます。また、監視対象となる個々のプロジェクトをリソースコンテナと呼びます。

参考 : 指標スコープの概要

指標を閲覧する Google アカウント（グループ）は、スコーピングプロジェクトに対してのみ、モニタリング閲覧者（roles/monitoring.viewer）ロール等の IAM ロールを持つことで、監視対象となるすべてのプロジェクトの指標を閲覧できるようになります。個々の監視対象プロジェクトに対する IAM 権限は必要ありません。

参考 : 指標スコープの概要 - Cloud Monitoring へのアクセス権を付与する

公式ドキュメントでは、スコーピングプロジェクトとして専用のプロジェクトを作成し、そこにはリソースを何も作成しないことを推奨しています。そのほうが権限管理上もシンプルですし、スコーピングプロジェクト自体で指標が生成されないため、管理が容易になるためです。

参考 : 指標スコープの概要 - ベストプラクティス

Ops エージェント

Ops エージェントの指標

Compute Engine VM に、Ops エージェントをインストールすると、Google Cloud の指標の他に、追加の指標を収集できます。

参考 : Ops エージェントの概要

Compute Engine の場合、Google Cloud の指標では、メモリ使用率、ディスク使用率、スワップ利用率などの重要な指標は収集されません。これは、Google Cloud の指標は、VM のハイパーバイザから取得できる情報をもとに構成されているからだと考えられます。

Ops エージェントは、VM のゲスト OS 上で稼働し、情報を収集して、Cloud Monitoring の API エンドポイントに対してその情報を送信します。これにより、メモリ使用率、ディスク使用率、スワップ利用率などの指標が取得できます。

Ops エージェントによって収集される指標の一覧は、以下の公式ドキュメントを参照してください。

参考 : Ops エージェントの指標

なお、Ops エージェントの指標は取り込みボリュームに応じて料金が発生します。インスタンス数が数台〜十数台といったレベルでは無料枠に収まるか、安価になる可能性が高いですが、数百台のインスタンスを管理する場合は、コストに関する試算も重要になります。

Ops エージェントのセットアップ

エージェントのインストール手順は、以下の公式ドキュメントを参照してください。

参考 : Ops エージェントをインストールする

VM の要件

Ops エージェントが稼働する VM では、以下の条件1〜3をすべて満たしている必要があることに注意してください。どれか1つでも満たせていない状態だと、Ops エージェントは指標の送信に失敗します。エージェントが稼働してから数分が経つと、Memory Utilization（agent.googleapis.com/memory/percent_used）といった Ops エージェントの指標が VM の詳細画面等で確認できます。エージェントのインストール後には、正しく指標が収集できているかを確認しましょう。

条件1 : VM が Cloud Monitoring の API エンドポイントに到達できる

例1
- ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている
- VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている
- VM が外部 IP アドレスを持っている
例2
- ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている
- VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている
- VM が Cloud NAT でインターネットへアクセスできる
例3
- サブネットで限定公開の Google アクセスが有効になっている
- VM が限定公開の Google アクセス経由で Google Cloud API にアクセスできる設定ができている

限定公開の Google アクセスについては、以下の記事も参照してください。

参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 - G-gen Tech Blog

条件2 : VM にアタッチされているサービスアカウントがプロジェクトレベルで以下のロールを付与されている

モニタリング指標の書き込み（roles/monitoring.metricWriter）ロール

条件3 : VM のアクセススコープ設定で Cloud Monitoring への書き込みが許可されている

"デフォルト" もしくは "全て許可" になっていれば問題ない

アクセススコープについては、以下の公式ドキュメントや、当社記事も参照してください。

トラブルシューティング

指標が表示されない場合は、何らかのエラーが出力されている可能性があります。Linux インスタンスであれば、以下のようなパスにエージェントのログが出力されているので、ログを確認して原因を調査します。

/var/log/google-cloud-ops-agent/subagents/logging-module.log

以下はエラーの例です。この例では、VPC ファイアウォールルールでインターネットへのアウトバウンドの 443/TCP 通信が拒否されていたため、エージェントは API エンドポイントにリーチできず、エラーになっていました。

[2021/10/14 10:07:46] [error] [upstream] connection #272 to logging.googleapis.com:443 timed out after 10 seconds

なお上記のエラーメッセージで logging.googleapis.com と出ていることからもわかるように、Ops エージェントは Cloud Logging にログを送信するエージェントの役割も兼務しています。かつては Monitoring エージェントと Logging エージェントの2つの異なる役割のエージェントソフトウェアがありましたが、現在では Ops エージェントに統合されています。

ダッシュボード

Cloud Monitoring 指標を閲覧するには、Metrics Explorer の他、ダッシュボード機能を使うこともできます。ダッシュボードはカスタマイズ可能で、さまざまなチャート（グラフ）を配置して、運用上必要なリソースの指標を閲覧することができます。

ダッシュボードは運用の要件に合わせて自在に作成が可能であることに加えて、Google Cloud プロダクトごとにプリセットで用意されているダッシュボードをそのまま利用したり、複製してカスタマイズして利用することもできます。また、ダッシュボード定義は JSON 形式でエクスポートしたり、インポートすることができます。

参考 : ダッシュボードの概要
参考 : カスタムダッシュボードの作成と管理

アラート

概要

Cloud Monitoring では、指標にしきい値を設定して、しきい値を超過した際にメールを発信するなど、アラートの設定が可能です。アラート機能で作成された個々の設定を、アラートポリシーと呼びます。

参考 : アラートの概要

例えば、以下のようなアラートポリシーが作成可能です。

指標 : CPU使用率
対象 : あるインスタンスグループ全体
期間 : 5分間
しきい値 : 80%を超過
アクション : E メールを送信

通知チャネル

Cloud Monitoring のアラートでは、以下の通知先への通知が可能です。これらのような通知先のことを通知チャンネル（notification channels）と呼びます。

Eメール
Google Cloud のモバイルアプリ
Google チャット
PagerDuty Services
PagerDuty Sync
Slack
Webhook（HTTP エンドポイント）
SMS
Pub/Sub

通知先チャンネルを使った運用の例として、指標のしきい値超過をトリガーにして Pub/Sub にメッセージを送信し、Pub/Sub トリガの Cloud Run functions を起動して、対処アクションを自動実行するといったことが実現可能です。

参考 : 通知チャンネルを作成して管理する

設定方法

アラートポリシーは、しきい値超過時の発報のほか、指標が収集できなくなった時や、指標がある数値に到達されると予測される際に発報させることもできます。アラートポリシーの設定方法は、以下の公式ドキュメントを参照してください。

また、以下の記事もご参照ください。

blog.g-gen.co.jp

稼働時間チェック

稼働時間チェックとは

稼働時間チェック（uptime checks）とは、一般的に URL 監視、あるいは外形監視等と呼ばれる監視を設定できる機能です。

HTTP、HTTPS、TCP（任意のポート）のいずれかのトラフィックを Google から対象リソースに送信し、そのレスポンスが想定状態と異なっていればアラートを発報することができます。

インターネットからアクセス可能なエンドポイントを対象とする公開の稼働時間チェック（Public uptime checks）と、VPC ネットワーク内のプライベートなエンドポイントを対象とする非公開の稼働時間チェック（Private uptime checks）の2種類があります。

チェックが失敗した際の通知先として、Cloud Monitoring の通知チャンネルが選択できます。

参考 : 公開の稼働時間チェックを作成する
参考 : 非公開稼働時間チェックを作成する

稼働時間チェックには、チェック実行回数あたりの料金が発生します。料金単価は、1,000 回の実行ごとに $0.30 です（2025年4月現在）。また、Google Cloud プロジェクトあたり、月に100万回までが無料です。

参考 : Google Cloud Observability の料金

公開の稼働時間チェック

公開の稼働時間チェック（Public uptime checks）は、インターネットからアクセスできるエンドポイントを対象とする稼働時間チェックです。

以下を監視対象として設定できます。

URL
Compute Engine VM
App Engine アプリケーション
Kubernetes サービス
Amazon EC2 インスタンス
Amazon Elastic Load Balancers
Cloud Run リビジョン

監視対象が Google Cloud の VPC ネットワーク内のリソースの場合、稼働時間チェックが正しくエンドポイントに到達できるようにするためには、VPC ネットワークのファイアウォール等を適切に設定する必要があります。0.0.0.0/0 からのトラフィックが許可されていれば問題ありませんが、稼働時間チェックが利用する接続元 IP アドレスだけを許可することもできます。IP アドレスのリストは、Google Cloud コンソールからダウンロードしたり、API 経由で取得することができます。

参考 : 稼働時間チェックサーバーの IP アドレスを一覧表示する

上記で取得した接続元 IP アドレスの範囲だけを VPC ファイアウォールルールで許可することも可能ですが、クラウドサービスの IP アドレス範囲は変更される可能性もあるため、変更を定期的に検知してファイアウォールルールに反映するような仕組みを用意することが望ましいでしょう。

公開の稼働時間チェックの設定手順の詳細は、以下の公式ドキュメントを参照してください。

参考 : 公開の稼働時間チェックを作成する

非公開の稼働時間チェック

非公開の稼働時間チェック（Private uptime checks）は、インターネットに公開されていない、 VPC ネットワーク内部のリソースのエンドポイントを対象とする稼働時間チェックです。

社内向けシステムをホストする Compute Engine VM や、自組織の内部ネットワーク向けの API エンドポイント等を監視する目的で利用できます。

非公開稼働時間チェックでは、ターゲットとして Service Directory リソースと呼ばれるリソースを作成する必要があります。Service Directory リソースには、エンドポイント、サービス、名前空間といったリソースが含まれます。これらのリソースにより、Compute Engine VM や、Cloud Load Balancing の IP アドレスを抽象化し、稼働時間チェックはそれに対してチェックを行います。

詳細な設定手順は、以下の公式ドキュメントを参照してください。