CloudMonitoring on LIFELOG

Cloud Monitoring ダッシュボード実践｜既存ダッシュボードの活用からCustom Dashboard・Terraform管理まで

Thu, 24 Sep 2026 00:00:00 +0900

概要
#

障害の連絡を受けて Cloud Monitoring を開くと、ダッシュボードが何十も並んでいます。Google Cloud が自動で用意したもの、テンプレートから入れたもの、誰かが作ったもの。どれを開けばよいのか、足りないときに自分で作るべきなのかが分かりません。

作ると決めても迷います。コンソールで作ったダッシュボードも JSON で取り出せます。ただ、作っただけでは Git などのソース管理に載りません。Terraform で管理しようとすると、今度はコンソールで触ってよいのかが分からなくなります。

この記事では、次の順で進めます。

Google Cloud が用意したダッシュボードとテンプレートで足りるかを見る
足りない分を Custom Dashboard にまとめる
フィルタと変数で、対象を切り替えられるようにする
共有・権限・履歴など、運用に要るものを押さえる
JSON を取り出し、gcloud と Terraform で管理する

ステップ2では、メトリクスに加えてログ・Incident・変更イベントも同じ画面に置きます。

Metrics Explorer を開いたことがある人向けです。Terraform の基本操作（init / plan / apply）は前提とします。

扱わないものもあります。

メトリクスの意味と集計の選び方。メトリクスの解説編に任せます
アラートポリシー・通知チャネル・SLO の設計
Cloud Logging のクエリの書き方。クエリ集に任せます
サードパーティ製ダッシュボード、Grafana からの取り込み、Managed Service for Prometheus の構築
すべてのウィジェットとサービスを網羅すること

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.1
Google Cloud SDK 562.0.0、kubectl v1.35.2（GKE v1.35.8-gke.1036000）
リージョン asia-northeast1

サンプルコードは次にあります。

Cloud Monitoring メトリクスチートシート｜障害調査でよく使うPromQLまとめ

Thu, 24 Sep 2026 00:00:00 +0900

このチートシートの使い方
#

障害調査では「CPU が張り付いている VM はどれか」「5xx はいつから増えたか」といったクエリを何度も書きます。書くたびにメトリクス名とラベルを調べ直すと、そこで手が止まります。

このページは、調べたいことから貼り付けられるクエリへすぐたどり着くための早見表です。急いでいるときは、目的から探すへ直接進んでください。 そこからサービスから探すのクエリへ飛べます。

Metrics Explorer を開いたことがあり、クエリを素早く引きたい人向けです。Cloud Monitoring の入門とメトリクス収集の有効化は扱いません。アラートポリシー・SLO・ダッシュボードの設計も範囲外です。

集計やラベルの仕組みは解説編に、メトリクスが取れるかどうかの調べ方は確認編にあります。ここでは繰り返しません。

クエリを入力する場所
#

PromQL も Monitoring filter も Metrics Explorer に入力します。ただし入口が違います（Metrics Explorer の資料）。

種類	入力する場所
PromQL	クエリペインのツールバーで PromQL ボタンを選び、エディタに貼る
Monitoring filter	Metric 要素の Help から Direct Filter Mode を選び、Filters の欄に貼る

見出しに「（Monitoring filter）」と付いたクエリ以外は、すべて PromQL です。 入力欄を切り替えると、入力中のクエリは破棄されます。

Cloud Monitoringで取れるか調べる手順（定義はあるのに時系列は0件だった）

Sat, 19 Sep 2026 00:00:00 +0900

概要
#

監視項目を決めるとき、最初に詰まるのは名前ではありません。「そもそも取れるのか」が分からないことです。

メモリ使用率が見つからない。GKEのAPIサーバの指標が無い。Metrics Explorerを開いてもグラフが出ない。

原因が、収集していないのか、名前が違うのか、そもそも存在しないのか、画面からは区別がつきません。

この記事で扱うのは調べ方です。どの一覧を開き、何を読み、見つからなかったら次に何をするか。

メトリクスの一覧そのものは載せません。一覧はGoogle側で増減するので、写した記事はすぐ古くなります。

対になる記事があります。

記事	役割
この記事	調べ方。取れるかどうかを自分で判定する
よく使うCloud Monitoringメトリクスまとめ	具体例。 GCE・GKE・Cloud Run・LBなどの実測値つき早見表と、集計・ラベル・取り方
Cloud Monitoring メトリクスチートシート	クエリ集。障害調査で使う PromQL と Monitoring filter を、目的とサービスから引く

Google Cloudのメトリクスを一度は触ったことがある人向けです。集計やPromQLの書き方、アラートポリシーの設計は扱いません。ログについてはクエリ集の記事があります。

検証環境
#

Google Cloud SDK 562.0.0、Monitoring API v3
公式ドキュメントの確認日は2026年9月19日
APIの実行は2026年9月19日、asia-northeast1 のリソースを対象

この記事の断定には2種類あります。公式ドキュメントを根拠にしたものと、実際にAPIを呼び出して確かめたものです。混ざらないように、実測した箇所には出力を載せています。

Cookieに backend-a と書いても backend-a2 へ届く。ALBのセッションアフィニティを実測した

Sun, 13 Sep 2026 00:00:00 +0900

概要
#

ログイン状態をサーバ側のメモリに置いている。ロードバランサが毎回違うバックエンドへ振ると、数リクエストごとにログアウトする。同じクライアントを同じバックエンドへ送りたい。

Google Cloud のロードバランサには session_affinity があります。リージョン外部ALBで選べるのは6種類です。

NONE / CLIENT_IP / GENERATED_COOKIE / HEADER_FIELD / HTTP_COOKIE / STRONG_COOKIE_AFFINITY

この記事で比べるのは Cookie を使う2つです。違いは「誰が発行するか」ではありません。

GENERATED_COOKIE はLBが発行した Cookie を使います。一方 HTTP_COOKIE が使うのは、名前を指定した Cookie の値です。その名前の Cookie が無ければLBが生成します。

後者を使うとき、こう書きたくなります。

self.send_header("Set-Cookie", "ROUTE=backend-a; Path=/")

これはバックエンドの指定になりません。 固定はされますが、backend-a という綴りがバックエンド backend-a を指すわけではありません。実測では、ROUTE=backend-a を送ったリクエストが10回とも backend-a2 に届きました。

あわせて、固定が外れる条件と、効いていることをどこで確かめられるかも測ります。後者は予想と違いました。

Google Cloud のロードバランサを触ったことがある人向けです。構成の作り方はリージョンALBの回で扱っており、ここではアフィニティの差分だけを見ます。gRPC やステートフルなセッション管理の設計は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.44.0
Google Cloud SDK 562.0.0、curl 7.81.0
初回検証は2026年9月13日、再検証は2026年9月19日、いずれも asia-northeast1

初回・再検証は別デプロイです。AFFLOG の Cookie 関連の記録（6件のログなど）は9月13日、request_count・backend_request_count の94件／30件を含む指標系の集計は9月19日の再検証結果です。断りのない数値は、それぞれの取得時点のデプロイでの集計としてください。Cookie の対応だけは、作り直す前と後の2回ぶんを並べています。

よく使うCloud Monitoringメトリクスまとめ（集計を変えたら同じCPU使用率が3倍になった）

Fri, 11 Sep 2026 00:00:00 +0900

概要
#

Metrics Explorerは、メトリクス名さえ分かれば絞り込めます。厄介なのはその先です。同じメトリクス・同じ期間でも、集計の選び方で値が変わります。

実際にこうなりました。

同じVM、同じ1時間の枠での CPU 使用率です。

集計	値
1時間平均（`ALIGN_MEAN`）	0.14
1時間最大（`ALIGN_MAX`）	0.4251

3倍です。 どちらも正しく、見たいものが違うだけです。ここを意識しないまま閾値を決めると、鳴らないアラートか鳴りっぱなしのアラートになり、あとから原因が追えなくて困ります。

自分が検証で実際に取ったメトリクスと値を、まとめて置いておきます。Cloud Loggingのクエリ集と対になるリファレンスです。貼り付けて使うクエリは、Cloud Monitoring メトリクスチートシートに目的別・サービス別でまとめています。

Google Cloudのコンソールを触ったことがある人向けです。監視の設計論やSLOの立て方は扱いません。

検証環境
#

Google Cloud SDK 562.0.0

値は、このブログのTerraform/Google Cloudシリーズで作った検証環境から実際に取得したものです。

リソースは削除済みですが、メトリクスは残っています。 ログと同じで、片付けたあとでも調べ直せます。

ただし解像度は下がります。

種別	保持	解像度
Compute Engine・GKE・Cloud SQL など、公式表が挙げる指標	24か月	6週間は元の頻度、以降は10分間隔
カスタム・外部・エージェント	24か月	同上
Managed Service for Prometheus・OTLP	24か月	1週間は元の頻度、次の5週間は1分間隔、以降は10分間隔
それ以外	6週間	—

6週間を過ぎた分は10分間隔にダウンサンプリングされます。細かい変化を見たい検証結果は、その場で保存しておきます。

GKEでPodの退避を起こしたら、監視に必要なメトリクスがCloud Monitoringに来なかった

Sun, 06 Sep 2026 00:00:01 +0900

概要
#

ノードのメモリやディスクが逼迫すると、kubelet が Pod を退避（Eviction）します。退避された Pod は Failed として API 上に残り、PodGC が片付けるまで一覧に並び続けます。

監視していなければ、原因の分からない Failed Pod が増えていくだけです。

そこで退避を監視しようとして、最初につまずきました。kube_pod_status_reason{reason="Evicted"} を Cloud Monitoring で引いても、何も返ってきません。

これは kube-state-metrics が出すメトリクスで、Pod の status.reason をそのままラベルにしたものです。退避された Pod には reason="Evicted" のラベルが付きます。

Gauge なので、sum() で分かるのは現在 API 上に残っている Evicted の Pod 数です。累積の退避回数ではありませんが、退避を検知するアラートなら、まず候補に挙がります。

sum(kube_pod_status_reason{reason="Evicted"}) > 0

収集そのものは動いていました。Managed Service for Prometheus（GMP）は有効で、up{job="kube-state-metrics"} は 1 を返します。それでも、退避を数えるためのメトリクスだけが Cloud Monitoring に入っていません。

この状態でどこを見れば退避に気づけるのか。GKE で実際に退避を起こして確かめました。

対象読者
#

GKE でワークロードを動かしたことがある
kubectl describe で Pod の状態を読める

扱わないもの
#

Kubernetes と GKE の入門
Pod Disruption Budget、kubectl drain による退去（今回はノード逼迫による退避）
HorizontalPodAutoscaler、Cluster Autoscaler

退避が起きたときに、何をどこで観測できるかに絞ります。

CloudMonitoring on LIFELOG

Cloud Monitoring ダッシュボード実践｜既存ダッシュボードの活用からCustom Dashboard・Terraform管理まで

概要 #

検証環境 #

Cloud Monitoring メトリクス チートシート｜障害調査でよく使うPromQLまとめ

このチートシートの使い方 #

クエリを入力する場所 #

Cloud Monitoringで取れるか調べる手順（定義はあるのに時系列は0件だった）

概要 #

検証環境 #

Cookieに backend-a と書いても backend-a2 へ届く。ALBのセッションアフィニティを実測した

概要 #

検証環境 #

よく使うCloud Monitoringメトリクスまとめ（集計を変えたら同じCPU使用率が3倍になった）

概要 #

検証環境 #

GKEでPodの退避を起こしたら、監視に必要なメトリクスがCloud Monitoringに来なかった

概要 #

対象読者 #

扱わないもの #

概要
#

検証環境
#

Cloud Monitoring メトリクスチートシート｜障害調査でよく使うPromQLまとめ

このチートシートの使い方
#

クエリを入力する場所
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

対象読者
#

扱わないもの
#