Cloud Monitoringとは？Google Cloudの監視機能・料金とOps Agentで指標が出ないときの確認点

Cloud Monitoringは、Google Cloud（GCP）が提供する標準の監視サービスです。仮想マシン・コンテナ・マネージドサービスの指標を自動で集め、グラフ・アラート・外形監視・SLOまでを1か所で扱えます。IBMなど他社にも同名の製品がありますが、本記事はGoogle CloudのCloud Monitoringを対象に、機能の使い分け、2026年10月時点の料金、導入でつまずく箇所を公式ドキュメントに沿って整理します。

まとめ｜Cloud Monitoringの料金・機能の要点とGCP中心構成での採用判断

Google Cloudの標準指標は設定なしで無料収集され、課金はおもにカスタム指標・Ops Agent指標の取り込み量（月150 MiBまで無料）、API読み取り、合成モニタリングの実行回数です。アラートポリシーの課金は「2027年9月1日より前には始まらない」と公式料金ページに書かれており、2026年10月時点では無料で使えます。

VMのメモリやディスク使用率は標準指標に含まれないため、Ops Agentを入れます。入れても指標が出ないときは、API到達性・サービスアカウントのロール・アクセススコープの3点を疑います。新規のクエリにはPromQLを推奨します。MQLは2025年7月22日にカスタマーサポートとコンソールでの新規作成機能が終了しましたが、既存のMQL資産は引き続き利用できます。ワークロードの大半がGoogle Cloudにあるなら第一候補で、AWSやオンプレを同じ画面で突き合わせる要件があるならDatadogなど統合監視SaaSと比べて決めます。

Cloud Monitoringの役割｜Google Cloud Observabilityでの位置づけと対象範囲

Cloud Monitoringは、旧称Stackdriver（その後オペレーションスイート）の後継であるGoogle Cloud Observabilityの中核サービスです。Compute Engine、GKE、Cloud Run、Cloud SQLなどの指標を時系列データとして保存し、可視化・アラート化します。プロジェクトを作った時点から標準指標は取り込まれているため、最初の作業は「何を見るか」を決めることです。監視項目の決め方はシステム監視の監視項目と死活監視・性能監視の違いで整理しています。

Cloud Logging・Cloud Traceとの分担｜指標・ログ・トレース

Cloud Monitoringが担うのは指標（メトリクス）で、ログはCloud Logging（ログルーターとシンクによるログ管理）、分散トレースはCloud Traceが担当します。障害対応では、Monitoringのアラートで異常に気づき、Loggingでエラー内容を、Traceで遅い区間を特定する流れになります。

指標の種類と保持期間｜24か月残る指標と6週間で消える指標

指標は、Google Cloudが自動で出す標準指標（無料）と、アプリケーション固有の値を送るカスタム指標・Ops Agentの指標（取り込み量で課金）に分かれます。公式の割り当てと上限のページによると、カスタム指標・エージェント指標とCompute Engine・GKE・Cloud SQL・BigQueryなど主要サービスの指標は24か月保持されます（6週間を過ぎると10分間隔へ間引き）。それ以外のGoogle Cloud指標と、ログベース指標は6週間です。前年同月と比べたい値をログベース指標で作っているなら、元のログをログシンクでBigQueryへ送って集計するなど、別の保存先が必要です。

指標スコープで複数プロジェクトを監視する構成と上限375件

本番・ステージングのようにプロジェクトを分けている場合は、監視用プロジェクトの指標スコープに各プロジェクトを追加すると、1つの画面で横断して見られます。アラートとダッシュボードは監視用プロジェクト側に保存されます。公式サポートは1スコープあたり375プロジェクトまでで、追加自体は3,500プロジェクトまでできますが、375を超えるとクエリとグラフの性能は保証されません。

Cloud Monitoringの主要機能｜Metrics Explorerからアラート・外形監視・SLOまで

指標の読み取り、カスタム指標の書き込み、ダッシュボードやアラートの管理は、いずれもCloud Monitoring APIからも操作できます。画面で作った設定を後からコード管理に移せる前提で、各機能を見ていきます。

Metrics Explorerで指標を探すときの選び分けとVM名での表示

Metrics Explorerは、リソースと指標を選んでフィルタ・集計・グループ化を指定すると、その場でグラフ化できる探索ツールです。作ったグラフはそのままダッシュボードやアラート条件に流用できます。

つまずきやすいのは、似た名前の指標が複数あることです。VMのCPU使用率は、ハイパーバイザが測るcompute.googleapis.com/instance/cpu/utilizationと、Ops AgentがVM内部から測るagent.googleapis.com/cpu/utilizationの2本があり、公式の指標一覧も両者は値が異なりうると明記しています。前者は通常0.0〜1.0の小数で記録されますが、一部のマシンタイプではバーストにより1.0を超えます。60秒ごとにサンプリングされ、サンプリング後、表示まで最大240秒かかります。グラフの凡例が数字のインスタンスIDになって読みにくいときは、指標ラベルinstance_nameでグループ化するとVM名で表示されます。

ダッシュボードの定義済みテンプレートとJSONでの持ち運び

Compute EngineやCloud SQLなど主要サービスには定義済みダッシュボードがあり、複製して自分用に直せます。カスタムダッシュボードの定義はJSONでエクスポート・インポートできるため、本番とステージングで同じ画面を再現するときはJSONをGitで管理します。

アラートの条件3方式（しきい値・指標なし・予測）と通知チャネル

アラートポリシーは条件と通知先の組み合わせです。条件は、値がしきい値を超えたら発火する「しきい値」、一定時間データが届かないと発火する「指標なし（absence）」、将来の値がしきい値を超えると予測された時点で発火する「予測（forecast）」が基本です。予測条件の公式ページによると、コンソールでは予測期間を1時間から2.5日まで指定でき、ディスク容量の枯渇のように「超えてからでは遅い」指標に向きます。

VMが停止してCPU指標が途絶えると、しきい値条件は発火しません。VMの停止を検知するには、稼働時間チェックの失敗を監視するアラートを設定します。停止・削除済みリソースの指標は、原則として指標なし条件の評価対象から除外されます。通知チャネルはメール、SMS、Slack、PagerDuty、Google Chat、Pub/Sub、Webhookなどから選べます。Pub/Subに流してCloud Run functionsで再起動を自動実行する構成も組めます。条件を増やしすぎると肝心の通知が埋もれるので、絞り方はアラート疲れの原因と監視実装での対策を参考にしてください。

ログベース指標とログベースアラートの使い分け

ログをきっかけに通知する方法は2つあります。「特定のエラーメッセージが1件でも出たら知らせたい」ならログベースアラート（ログ一致条件）で、Logs Explorerのクエリからそのまま作れます。通知の間隔はnotificationRateLimitで制御し、公式例は300秒（5分に1回）です。

一方、「5分間にエラーが10件を超えたら」のように件数で判定したい場合、ログベースアラートの公式ページは、ログベースアラートでは件数を数えられず、ログベース指標を使うよう案内しています。ログベース指標はCloud Monitoringの指標になるため、しきい値条件やダッシュボードで扱えますが、保持期間は6週間です。

稼働時間チェック（公開・非公開）と合成モニタリングの使い分け

稼働時間チェック（Uptime check）は、URLやTCPポートへ複数リージョンから定期的にリクエストを送り、応答コードと応答時間を確かめる外形監視です。インターネットに出ていない社内向けのVMや内部ロードバランサを確かめるには、非公開の稼働時間チェックを使います。非公開の稼働時間チェックの公式ページでは、対象をService Directoryに登録し、ファイアウォールで送信元35.199.192.0/19からのTCPを許可する手順になっています。

注意点は、この公式ページが非公開の稼働時間チェックの対象として挙げるのが「プライベートネットワーク上のVM」と「L4内部ロードバランサ」の2つだけであることです。Cloud SQLは対象に含まれていないため、プライベートIPをService Directoryに登録して疎通を確かめる構成は前提にしないでください。Cloud SQL自体が動いているかは、標準指標cloudsql.googleapis.com/database/up（サーバーが稼働中かを示す値）で確認します。

合成モニタリング（Synthetic monitoring）は、Cloud Run functions上でMochaなどのテストを動かし、ログインから購入までのような複数ステップを定期実行します。「応答は200だが画面が壊れている」状態はこちらで拾います。外形監視の設計は外形監視と内部監視の違いと監視項目の実装で扱っています。

SLO監視によるエラーバジェットの追跡

SLO機能では、「直近30日で成功率99.9%」のような目標をサービスに紐づけ、エラーバジェットの消化速度にアラートを置けます。リクエスト成功率99.9%の目標なら、エラーバジェットは対象リクエスト数の0.1%です。時間ベースの稼働率99.9%を30日間に適用する場合は、停止時間に換算すると43.2分になります。バジェットが尽きかけたらリリースを止める、という判断の材料になります。用語の違いはSLAとSLO・SLIの違いと稼働率の決め方で整理しています。

PromQLとMQLの選び方｜Managed Service for Prometheusとの関係

新規に書くクエリはPromQLです。Google Cloud Managed Service for Prometheusを通じて、標準指標・Kubernetes指標・ログベース指標・カスタム指標のすべてをPromQLで照会でき、アラート条件にも使えます。同じ指標名・ラベル構成で収集していれば、Grafanaで使っていたPromQLクエリを再利用できます。Cloud Monitoring固有の指標名や未対応の関数を使う場合は、クエリの調整が必要です。

Google独自のMQLは、MQLの公式ページによると2025年7月22日にカスタマーサポートが終了し、コンソールでチャート・ダッシュボード・アラートを作る際に選べなくなりました。既存のMQL資産は動き続け、APIからは作成もできますが、新しく増やす理由はありません。GKEの監視設計はKubernetes監視のメトリクス・ログ・アラート閾値の設計、Prometheusを自前で組む場合はPrometheusで監視を構築する手順と比べてください。

Ops AgentでVMの詳細指標を集める手順と指標が届かないときの確認点

Compute Engineの標準指標はハイパーバイザから見える値なので、メモリ使用率・ディスク使用率・スワップは含まれません。これらはVM内で動くOps Agentを入れて集めます。Ops Agentは指標とログを1本で扱い、かつてのMonitoring agentとLogging agentを置き換えたものです。

Ops Agentのインストールコマンドとconfig.yamlの設定例

Linuxの単体VMなら、公式のインストール手順にある次の2行で導入でき、エージェントは自動で起動します。

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

ホスト指標の既定の収集間隔は60秒です。変えるにはLinuxなら/etc/google-cloud-ops-agent/config.yamlに上書きを書きます。Ops Agentの設定リファレンスにある30秒化の例は次のとおりです。

metrics:
  receivers:
    hostmetrics:
      type: hostmetrics
      collection_interval: 30s

変更はsudo systemctl restart google-cloud-ops-agentで反映します。NginxやMySQLの指標を収集するには、アプリケーション側の監視用設定を整え、同じファイルにレシーバーと、それを参照するパイプラインを追加します。間隔を半分にすると取り込み量もほぼ倍になるため、無料枠150 MiBとの兼ね合いで決めてください。

指標が出ないときの3条件｜API到達性・ロール・アクセススコープ

インストールは成功したのに数分待ってもagent.googleapis.comの指標が出ない場合は、まず次の3点を確認します。解決しない場合は、エージェントの稼働状態、設定エラー、APIの有効化、取り込み上限も調べます。

1. VMからGoogle APIに到達できない：外部IPもCloud NATも無いVMは、サブネットで限定公開のGoogleアクセスを有効にします。VMからGoogle APIへの送信通信（egress）で、宛先TCP 443番ポートをファイアウォールが拒否している場合も届きません。
2. サービスアカウントのロール不足：VMに付けたサービスアカウントに「モニタリング指標の書き込み（Monitoring Metric Writer）」と「ログ書き込み（Logs Writer）」が必要です。
3. アクセススコープの制限：Ops Agentの認可ページによると、新しいVMは既定のスコープで足りますが、古いVMやスコープを変えたVMでは不足しえます。VMを停止して、Stackdriver Logging APIとStackdriver Monitoring APIを書き込み可能にします。

指標送信の切り分けでは、Linuxでsudo journalctl -u 'google-cloud-ops-agent*'を実行してエージェントのログを確認します。ログ収集モジュールのファイルログは/var/log/google-cloud-ops-agent/subagents/配下にあり、403エラーならロールかスコープ、接続タイムアウトなら経路の問題です。コンソールのエージェント状態が「Pending」のままでも、実際には送信できていることがあるため、Metrics Explorerで指標が届いているかで判断してください。

Cloud Monitoringの料金体系｜無料枠・課金対象とアラート課金の開始時期

おもな課金対象と無料枠は次のとおりです（Google Cloud Observabilityの料金ページを2026年10月27日に確認。単価は改定されうるため、最新は公式で確認してください）。

コストが増える主因はカスタム指標の取り込み量です。ラベルの組み合わせが多い指標ほど時系列が増えるので、ユーザーIDのような値はラベルにせず、環境名・サービス名など種類が限られる値に絞ります。API読み取りの課金は2025年10月2日から適用されています。コンソールからの閲覧は対象外ですが、Grafanaなど外部ツールが頻繁に時系列を引く構成では無料枠を超えることがあります。稼働時間チェックは3リージョンから実行すると3回と数えます。

アラート課金の単価と対象外になるポリシー

アラート課金は、以前は「2026年9月1日以降」と告知されていましたが、現在の料金ページは「2027年9月1日より前には始まらない」に変わっています。予定単価は、アラート条件に含まれる指標参照1件ごとに月$0.35と、条件のクエリが返す100万ポイントごとに$0.50です。開始の90日前と30日前に通知が届くこと、2026年5月31日時点で有効な割引付きコミット契約がある場合は、その契約の満了・更新・延長・置換のいずれかが生じるまで適用されないことも明記されています。

対象外になるものもあります。稼働時間・請求・割り当て（Quota）の指標を使うメトリクスアラートポリシーは、参照料とポイント課金の対象外です。ログ一致条件はポイントを返さないため、ポイント課金がかかりません。試算すると、指標参照1件のポリシーを20本運用すれば参照料は月$7.00（0.35×20）です。フィルタ式のしきい値条件・指標なし条件は、条件ごとに1参照と数えます。PromQL・MQL条件はクエリ内の指標参照数で数えるため、1条件でも複数参照になることがあります。

Cloud Monitoringの始め方｜最初の設定3ステップとgcloudでのアラート作成

1. コンソールでMonitoringを開き、指標スコープに監視対象のプロジェクトが入っているか確認する。
2. メモリやディスクを見たいVMにOps Agentを入れ、Metrics Explorerでagent.googleapis.comの指標が届いたことを確かめる。
3. 重要指標にアラートポリシーと通知チャネルを設定し、外部公開のURLには稼働時間チェックを足す。

アラートはJSONで定義してコマンドで登録でき、Gitで管理すれば環境ごとに再現できます。次は公式のサンプルポリシー集にある、VMのCPU使用率が90%を15分超えたら発火する定義です。

{
  "displayName": "Very high CPU usage",
  "combiner": "OR",
  "conditions": [
    {
      "displayName": "CPU usage is extremely high",
      "conditionThreshold": {
        "aggregations": [
          {
            "alignmentPeriod": "60s",
            "crossSeriesReducer": "REDUCE_MEAN",
            "groupByFields": ["project"],
            "perSeriesAligner": "ALIGN_MAX"
          }
        ],
        "comparison": "COMPARISON_GT",
        "duration": "900s",
        "filter": "metric.type=\"compute.googleapis.com/instance/cpu/utilization\" AND resource.type=\"gce_instance\"",
        "thresholdValue": 0.9,
        "trigger": { "count": 1 }
      }
    }
  ]
}

このファイルをcpu-policy.jsonとして保存し、gcloud monitoring policies createで登録します。通知先は--notification-channelsで指定します。

# PROJECT_IDとCHANNEL_IDを実際のプロジェクトIDと既存の通知チャネルIDに置き換える
gcloud monitoring policies create --project=PROJECT_ID --policy-from-file=cpu-policy.json --notification-channels=CHANNEL_ID

thresholdValueの0.9は使用率90%、durationの900sは15分継続を意味します。この例はgroupByFieldsがプロジェクト単位なので、全VMの平均が90%を超えたときに発火します。VMごとに知りたい場合はresource.label.instance_idなどでグループ化してください。

AWS CloudWatch・Azure Monitorとの機能対応と他クラウドの取り込み

他クラウドの経験者がつまずくのは用語の読み替えです。指標とアラートはCloud Monitoring＝CloudWatch＝Azure Monitor、ログはCloud Logging＝CloudWatch Logs＝Log Analytics、トレースはCloud Trace＝X-Ray＝Application Insights、VMエージェントはOps Agent＝CloudWatchエージェント＝Azure Monitor Agentに対応します。Azure側はAzure Monitorの仕組みとLog Analytics・Application Insightsの関係で解説しています。

AWSの指標を取り込む経路は変わりました。AWS CloudWatch指標の収集ページによると、従来のAWS Connectorプロジェクトは2024年8月21日に取り込みを停止し、現在はPrometheus CloudWatch exporterとOps Agentを動かす中継VMを自分で運用する方式です。

Datadog・Zabbix・Prometheusとの比較｜監視要件別の使い分け

Google Cloud内の標準指標の可視化と通知だけが要件なら、まずCloud Monitoringで構成し、Datadogの導入は追加機能が必要になった段階で検討します。逆に、AWS・Azure・Google Cloudを1枚のダッシュボードで見たい場合や、トランザクション単位の追跡まで1製品で求める場合はCloud Monitoring単独では足りません。DatadogをIaCで管理するならTerraformでDatadogを管理する方法、オンプレを自前で監視するならZabbixの仕組みと監視できることを参照してください。

Cloud Monitoringを採用する条件と見送る場面｜失敗しやすい構成

採用すべきなのは、ワークロードの大半がGoogle Cloud上にあり、GKE・Cloud Run・Cloud SQLなどマネージドサービス中心の構成です。Compute Engine・GKE・Cloud SQLなどの主要な標準指標は無料で24か月保持されます。標準指標の可視化と通知が中心で、追加のAPM機能や運用支援が不要なら、まずCloud Monitoringで要件を満たせるか確認する方針を勧めます。

見送るべきなのは、AWSやオンプレに主要システムが残り、障害時に複数基盤の指標を同じ時間軸で突き合わせる必要がある場合です。AWS指標を取り込むには中継VMとexporterの運用が増えるため、それを担う体制が無ければ統合監視SaaSを優先します。

失敗しやすい構成は3つあります。カスタム指標にユーザーIDをラベルとして付け、無料枠をすぐに使い切る。VMの停止を指標なし条件で拾おうとして、停止したVMが評価対象から外れるため通知が来ない。Cloud SQLの疎通を非公開の稼働時間チェックで組もうとして、公式手順の対象外のまま設定を重ねる。いずれも本記事の各章の手当てで避けられます。監視設計をインフラ構築と一緒に固めたい場合はインフラ構築（AWS・Google Cloud・Azure）で支援範囲をご確認いただけます。GKEの構成を検討中ならGKEのAutopilotとStandardの違いも参考になります。

よくある質問

Cloud Monitoringとは何ですか？

Google Cloudが提供する標準の監視サービスで、GCPリソースの指標を自動収集し、グラフ・アラート・稼働時間チェック・SLO監視を一元的に扱えます。Cloud Logging・Cloud Traceと合わせてGoogle Cloud Observabilityを構成し、旧称はStackdriverです。

Cloud Monitoringの料金はいくらですか？

標準指標は無料です。課金はおもにカスタム・Ops Agent指標の取り込み（月150 MiBを超えた分が$0.2580/MiB〜）、API読み取り（月100万時系列を超えた分）、合成モニタリング（月100回を超えた分が$1.20/1,000回）です。アラートポリシーは2026年10月時点で無料で、課金は2027年9月1日より前には始まりません。

GCPで監視すべき項目は何ですか？

VMならCPU使用率に加え、Ops Agentで取るメモリ・ディスク使用率を監視します。停止の検知には稼働時間チェックを使い、その失敗をアラート条件にします。Cloud SQLはdatabase/upと接続数、外部公開のURLは稼働時間チェックで応答コードと応答時間を見ます。

Metrics Explorerの使い方は？

コンソールのMonitoringからMetrics Explorerを開き、リソース種別と指標を選んでフィルタ・集計を指定するとグラフが出ます。VM名で並べたいときはinstance_nameラベルでグループ化し、作ったグラフはダッシュボードやアラート条件にそのまま保存できます。

PromQLとMQLはどちらを使うべきですか？

新規ならPromQLです。MQLは2025年7月22日にサポートが終了し、コンソールで新しいチャートやアラートを作る際には選べません。既存のMQL資産は動き続けます。

関連記事

• Cloud Loggingとは？Google Cloudのログ管理の仕組み・ログルーター/シンクとCloudWatch Logsとの違いを実装者目線で解説
• Cloud Traceとは？Google Cloudの分散トレーシングの仕組み・OpenTelemetry連携・料金と導入判断を実装者目線で解説
• オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説
• 外形監視とは？内部監視との違いと監視項目・実装、導入判断を実装目線で解説
• Prometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積り