CloudLogging 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 Logging クエリチートシート｜障害調査でよく使う検索例まとめ

Wed, 23 Sep 2026 00:00:00 +0900

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

障害調査では「この Pod のログだけ見たい」「誰がこのリソースを消したか知りたい」といったクエリを何度も書きます。書くたびにフィールド名を調べ直すと、そこで手が止まります。

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

前提と基本形は、あとから読めば足ります。

Logs Explorer を使ったことがあり、検索式を素早く引きたい人向けです。Cloud Logging の入門やログ収集の設定、Log Router・シンク・ログベースの指標は扱いません。

件数や割合がいつから増えたかは、メトリクスで見るほうが速く分かります。そのためのクエリはCloud Monitoring メトリクスチートシートにあります。

書き方の前提
#

クエリは Logs Explorer のクエリエディタにそのまま貼れる形で書きます。同じ構文は Logging API と gcloud logging read でも使えます（Logging query language）。

gcloud logging read のオプションや、0件だったときの切り分けは解説編にあります。ここでは繰り返しません。

次の表にある語はプレースホルダーで、自分の環境の値に置き換えます。AND・OR・NOT や ERROR などの演算子・定数は、そのまま使います。

プレースホルダー	置き換えるもの
`PROJECT_ID`	プロジェクト ID
`CLUSTER_NAME` / `NAMESPACE` / `POD_NAME`	GKE のクラスタ名・Namespace・Pod 名
`INSTANCE_ID` / `INSTANCE_NAME`	Compute Engine の VM の ID・名前
`SERVICE_NAME`	Cloud Run のサービス名
`APP_LABEL`	Pod に付けた `app` ラベルの値
`RESOURCE_NAME`	監査ログで探すリソース名の一部
`TRACE_ID`	トレース ID
`USER_EMAIL`	操作したユーザーやサービスアカウントのメールアドレス
`SUBNET_CIDR`	`10.0.0.0/24` のような CIDR 表記の範囲

確認環境とクエリの区分
#

Logs Explorer は SaaS なので、読者が照合できる版番号がありません。代わりに、公式ドキュメントを確認した日付を書きます。

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回ぶんを並べています。

IAP経由のSSHはどこまで監査できるのか。OS LoginとVMログを実測した

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

概要
#

外部IPを付けず、tcp/80 も開けずに、VM 上の HTTP を見たい。IAP の SSH ポートフォワードでできます。許可するのは IAP の範囲からの tcp/22 だけです。

ただ、そのあとに困ることが2つあります。

誰に何の権限を渡せばいいのか。 公式の手順どおりに書いたつもりで、自分では繋がるのに他の人が繋がらない、ということが起きます。

誰が何をしたか、どこまで残るのか。 踏み台を置かない構成なので、監査の材料がどこにあるのか分かりにくくなります。

この2つを実測します。接続手順そのものはサンプルの README にあるので、ここでは扱いません。

Google Cloud の Compute Engine を触ったことがある人向けです。外部IPなしの VM への接続経路を決めようとしている場面を想定しています。IAP の Web アプリ向け機能と、Organization Policy による追加要件は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0
Ops Agent 2.70.0、Debian 12

使用するコードは Advanced-Examples/07-iap-ssh-port-forwarding です。

Cloud Armorで送信元IPを拒否したら、リクエストはバックエンドに届かなかった

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

概要
#

Cloud Armor で送信元を絞ったとき、拒否されたリクエストはどこまで来ているのか。 バックエンドのログに出ないのは「届いていないから」なのか、「出していないだけ」なのか。

見えないものを「無い」と決めるのは危ないので、クエリ文字列に識別子を入れたリクエストを送って確かめます。同じ1回のリクエストを、クライアント・LBのログ・バックエンドのログの3か所で追えます。

あわせて、プレビューの動作も確かめます。ルールを有効にする前に「もし有効だったら何が止まるか」を見る仕組みです。

プレビューにしたルールは判定するだけで、実際には止めません。判定はログと専用メトリクスに残ります。

3つの状態で、応答・ログ・メトリクスの見え方を並べます。

Google Cloud のロードバランサを触ったことがある人向けです。構成の作り方は前々回で扱っており、ここでは Armor の差分だけを見ます。WAF ルールやレート制限は扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0

使用するコードは Advanced-Examples/09-regional-alb-cloud-armor です。

cd Advanced-Examples/09-regional-alb-cloud-armor
cp terraform.tfvars.example terraform.tfvars
# project_id / allowed_src_ips（自分のグローバルIPを /32 で）/ iap_member を書く
terraform init
terraform apply
terraform apply   # 2回目。理由は後述

create_deny_client = true にすると、許可リストに載っていない送信元として使える検証用 VM も作られます。access_config {} でエフェメラルな外部IPが付くので、そのIPで出ていきます。

proxy-onlyサブネットを塞ぐと、リージョンALBはHEALTHYのまま504を返した

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

概要
#

ロードバランサのトラブルは「ヘルスチェックが赤い」から入ることが多く、そこを直せば通ります。リージョン外部 Application Load Balancer には、緑のまま通らない入り方があります。

バックエンドから見ると、同じロードバランサからの通信がヘルスチェックと実トラフィックの2つに分かれています。片方だけを塞ぐと、こうなります。

今回測ったのは、IPv4のVMを GCE_VM_IP_PORT 型のゾーンNEGに登録した構成です。ハイブリッドNEGやバックエンドバケットでは経路が変わるので、そのまま当てはめられません。

何が来るか	送信元
ヘルスチェック	`35.191.0.0/16`
実トラフィック	proxy-only サブネットの範囲

ファイアウォールを片方しか開けていないと、片方だけ通ります。ヘルスチェックだけ開けていれば、バックエンドは HEALTHY のまま、クライアントには 504 が返ります。

ファイアウォールを1本だけ外す対照実験で、これを実際に起こします。

Google Cloud のロードバランサを触ったことがある人向けです。ALB の種類の選び方や、Cloud Armor・セッションアフィニティは扱いません。

検証環境
#

Terraform v1.14.3、hashicorp/google v7.46.0
Google Cloud SDK 562.0.0

使用するコードは Advanced-Examples/08-regional-external-alb-neg です。

cd Advanced-Examples/08-regional-external-alb-neg
cp terraform.tfvars.example terraform.tfvars   # project_id と iap_member を書き換える
terraform init
terraform apply

Apply complete! Resources: 33 added, 0 changed, 0 destroyed.

Outputs:
vip = "34.146.203.171"

バックエンドVMに外部IPはありません。インターネットからの入口はロードバランサだけです。

よく使うCloud Loggingクエリまとめ（絞り込みから「出ない」ときの確認まで）

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

概要
#

Cloud Loggingは、書き方さえ合っていれば目的のログにすぐ着きます。困るのは0件が返ったときです。ログが無いのか、クエリが違うのか、そもそも収集していないのか、返ってきた空行からは区別がつきません。

しかも綴りを間違えてもエラーになりません。 resource.type="k8s_containers" と複数形で書けば、静かに0件が返ります。

自分が検証で実際に打ったクエリを、実行結果とセットでまとめます。忘れたときに引けることと、0件の理由をたどれることを目的にします。

Google Cloudのコンソールかgcloudを触ったことがある人向けです。Cloud Loggingをこれから使い始める人の入門ではありません。ログ設計そのものや、Cloud Logging以外への転送は扱いません。

やりたいことから Logs Explorer に貼れるクエリだけを引きたいときは、チートシートを使います。

検証環境
#

Google Cloud SDK 562.0.0

出力例は、このブログのTerraform/Google Cloudシリーズで作った検証環境のログを実際に読んだ結果です。

リソースはすべて削除済みですが、ログは残っています。保持期間は保存先のバケットで決まります。この環境では _Default が30日、_Required が400日でした。

$ gcloud logging buckets list --location=global \
    --format='table(name.basename():label=BUCKET_ID,retentionDays,description)'
BUCKET_ID  RETENTION_DAYS  DESCRIPTION
_Default   30              Default bucket
_Required  400             Audit bucket

リソースを消しても、しばらくは調べ直せます。検証の片付けを終えたあとに「あれはどうだったか」となったとき、この30日が効きます。

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

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

terraform applyが成功してもVMの中は設定されていなかった話

Sat, 05 Sep 2026 00:00:04 +0900

概要
#

「Terraformはマシンを作る、中で動くものはAnsible」という分担はよく聞きます。ところがその受け渡しは自動では繋がりません。

実際に、terraform applyが35 addedと出た一方で、VMの中ではAnsibleが失敗していました。terraform planも差分なしのままです。Terraformから見ると、この失敗はどこにも現れません。

GCEにOps AgentとNginxを入れる最小構成で、この境界を実測します。

対象読者は、TerraformでGCEを作ったことがあり、Ansibleを書いたことがある人です。それぞれの入門は扱いません。

Ansible制御ノードからのpush型実行、Ansible Vaultは扱いません。今回はVM上でのlocal実行です。

検証すること
#

startup scriptはいつ走るのか（初回だけか、毎回か）
Terraformの「成功」は中身を保証するか
playbookを更新したとき、既存のVMにどう反映するか
サービスが「正しく」動いているとどう確認するか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GCE、GCS、IAPを操作できるGoogleアカウント
VM内でsudoを実行できること。掲載した手動再実行やログ確認に要る。roles/compute.osLoginだけでは足りず、roles/compute.osAdminLoginが要る
検証時のバージョン：Terraform 1.14.5、google 7.46.0、Debian 12、nginx 1.22、Ansible 2.14（Debian 12 の apt が入れる版）、Ops Agent 2.x

Ansible と Ops Agent の細かい版は記録していません。挙動が変わりうるので、再現するなら ansible --version と google_cloud_ops_agent_engine --version を控えておきます。

標準出力に1行JSONを書くだけなら、GKEではFluentdサイドカーが要らなかった

Sat, 05 Sep 2026 00:00:03 +0900

概要
#

構造化ログをCloud Loggingに送りたいとき、Fluentdをサイドカーに置く構成があります。GKEでそれが要るのかを確かめました。

さらに、fluent.confに書いたtagやrecord_transformerが、Cloud Logging上のどのフィールドになるのかも対応が分かりません。サイドカーを入れたのに期待したキーで検索できない、という状態になりがちです。

実際に測ってみると、GKEの収集エージェントが既にJSONを解釈していました。 アプリが標準出力に1行JSONを書くなら、サイドカーは要りません。しかも挟み方を誤ると、逆に構造を失います。

ファイルに書く場合は別です。 GKEの標準収集が拾うのはコンテナの標準出力と標準エラーなので、ファイル出力を届けるには何かが要ります。

対象読者は、GKEでPodを動かしたことがあり、Cloud Loggingでログを見たことがある人です。Kubernetesの入門は扱いません。

Log Routerによる転送、Log-based metrics、Autopilotクラスタは扱いません。

検証すること
#

素のテキストとJSONで、入るフィールドが変わるか
構造化ログにFluentdサイドカーは必要か
fluent.confの設定がCloud Loggingのどのフィールドになるか
スタックトレースが1エントリにまとまるか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GKE、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.5、google 7.46.0、GKE 1.35.7-gke.1027000、fluentd v1.16-debian-1

使用するTerraformコード
#

Advanced-Examples/24-gke-fluentd-log-format

READMEの手順でTerraformを適用し、k8s/配下の4つのマニフェストを当てます。クラスタはプライベートエンドポイント構成なので、以下のkubectlは踏み台VMから実行します。

CloudLogging on LIFELOG

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

概要 #

検証環境 #

Cloud Logging クエリ チートシート｜障害調査でよく使う検索例まとめ

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

書き方の前提 #

確認環境とクエリの区分 #

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

概要 #

検証環境 #

IAP経由のSSHはどこまで監査できるのか。OS LoginとVMログを実測した

概要 #

検証環境 #

Cloud Armorで送信元IPを拒否したら、リクエストはバックエンドに届かなかった

概要 #

検証環境 #

proxy-onlyサブネットを塞ぐと、リージョンALBはHEALTHYのまま504を返した

概要 #

検証環境 #

よく使うCloud Loggingクエリまとめ（絞り込みから「出ない」ときの確認まで）

概要 #

検証環境 #

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

概要 #

対象読者 #

扱わないもの #

terraform applyが成功してもVMの中は設定されていなかった話

概要 #

検証すること #

前提環境 #

標準出力に1行JSONを書くだけなら、GKEではFluentdサイドカーが要らなかった

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

概要
#

検証環境
#

Cloud Logging クエリチートシート｜障害調査でよく使う検索例まとめ

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

書き方の前提
#

確認環境とクエリの区分
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

検証環境
#

概要
#

対象読者
#

扱わないもの
#

概要
#

検証すること
#

前提環境
#

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#