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

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

#

障害調査では「この 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 などの演算子・定数は、そのまま使います。

確認環境とクエリの区分

#

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

Google Cloud Console / Cloud Logging Query Language   2026-09-23 確認
Google Cloud SDK 562.0.0                              補助確認

SDK の版は、実ログの出力を引用した既存記事で使ったものです。

クエリごとに、確認した範囲も示しています。

「仕様」のクエリは、ログにそのフィールドが入っていることが前提です。 jsonPayload・protoPayload・labels の中に無いフィールドは、比較してもエラーにならず一致しません（NOT で否定した場合は一致します）。

httpRequest など LogEntry に定義されたフィールドは、無ければ既定値として比べられます。存在しないフィールド名はエラーです（Missing fields）。

公式例・仕様のクエリでも、一部の条件を実ログで確かめたものは、その範囲を添えています。

まず覚える基本形

#

比較は FIELD OP VALUE

#

resource.type = "k8s_container"

AND / OR / NOT は大文字、混ぜるなら括弧

#

論理演算子は大文字で書きます。 小文字の and or not は、検索語として扱われます（Boolean operators）。

優先順位は NOT、OR、AND の順です。OR のほうが AND より先に結び付きます。 次の2つは同じ意味になります。

severity>=ERROR AND resource.type="k8s_container" OR resource.type="gce_instance"
severity>=ERROR AND (resource.type="k8s_container" OR resource.type="gce_instance")

読み手が評価順を取り違えないよう、AND と OR を混ぜるときは常に括弧を付けます。同じフィールドなら値の側でまとめられます。

resource.type = ("k8s_container" OR "gce_instance")

severity

#

severity>=ERROR

ERROR 以上（CRITICAL・ALERT・EMERGENCY を含む）に一致します。深刻度の段階は LogSeverity にあります。

timestamp

#

timestamp>="2026-09-23T00:00:00Z" AND timestamp<"2026-09-23T01:00:00Z"

クエリに timestamp を書くと、時間範囲セレクタは使えなくなります。 その条件がそのまま検索期間になります（Sample queries）。

Z は UTC を表し、+09:00 を付ければ JST のまま書けます。日付だけの "2026-09-23" は 2026-09-23T00:00:00Z として扱われます（Searching by time）。

SEARCH()

#

SEARCH("connection refused")

語（トークン）単位で探し、大文字小文字は区別しません。上の例は connection と refused の両方を含むエントリに一致し、順序や同じフィールドかどうかは問いません。語順どおりの句にしたいなら、句をバッククォートで囲みます（SEARCH("`connection refused`")）。

語の一部では一致しません。 SEARCH("world") は worldwide に当たりません。文字列を含むかどうかで探すなら、フィールドを指定した : を使います（SEARCH function）。

正規表現

#

textPayload =~ "timeout|deadline exceeded"

構文は RE2 で、既定では先頭や末尾に固定しません。固定するなら ^ と $ を書きます。

正規表現は大文字小文字を区別します。 区別したくないときは (?i) を先頭に付けます（Using regular expressions）。

まず対象を絞ってからログ本文を探す

#

最初に、インデックスが効くフィールドで対象を絞ります。 常にインデックスされるのは次のフィールドです（Use indexed fields）。

resource.type   resource.labels.*   logName   severity   timestamp
insertId   operation.id   trace   httpRequest.status   labels.*   split.uid

対象を絞ってから、ログ本文を SEARCH() かフィールドを指定した比較で探します。インデックスされたフィールドでも、: の部分一致ではインデックスが使われません。OR もインデックスを使えないので、できるだけ AND で組みます。

どのフィールドも指定しない検索（"error" だけ、など）は遅くなります。 全フィールドへの部分一致になるためです。

log_id()

#

log_id("cloudaudit.googleapis.com/activity")

logName を projects/PROJECT_ID/logs/... のフルパスで書かずに済みます。引数は URL エンコードしません。 log_id("cloudaudit.googleapis.com%2Factivity") はどのログにも一致しません（log_id）。

目的から探す

#

クエリ本体はサービスから探すに置いています。ここは行き先の一覧です。

サービスから探す

#

GKE / Kubernetes

#

コンテナのログは k8s_container に入ります。Kubernetes の Event は、対象の粒度に応じて k8s_cluster・k8s_pod・k8s_node に入ります（Sample queries）。コントロールプレーンの監査ログは k8s_cluster で確認します。

特定 Pod のログ

#

resource.type="k8s_container"
AND resource.labels.cluster_name="CLUSTER_NAME"
AND resource.labels.namespace_name="NAMESPACE"
AND resource.labels.pod_name="POD_NAME"

resource.labels.* はすべてインデックスされます。Pod を作り直すと名前が変わるので、追い続けるならラベルで絞ります。

確認: 公式例（namespace_name・pod_name）。cluster_name の絞り込みは実ログでも確認済み（GKE のログ形式の検証）

Namespace のエラー

#

resource.type="k8s_container"
AND resource.labels.namespace_name="NAMESPACE"
AND severity>=ERROR

アプリが JSON で severity を出していないと、ERROR として記録されないことがあります。どう振り分けられるかはGKE のログ形式の検証で測りました。

確認: 公式例（公式例は severity=ERROR）

Pod のラベルで絞る

#

resource.type="k8s_container"
AND labels."k8s-pod/app"="APP_LABEL"

Pod のラベルはエントリ直下の labels に k8s-pod/ 付きで入ります。キーに / を含むので、引用符で囲みます。

確認: 実ログ（GKE のログ形式の検証）

Evicted になった Pod

#

resource.type="k8s_pod"
AND log_id("events")
AND jsonPayload.reason="Evicted"

Kubernetes の Event は events ログに入ります。クラスタを消したあとも、ログの保持期間内なら検索できます。

確認: 公式例。log_id("events") を除いた形は、実ログで4件一致（Pod 退避の検証）

Pod を削除した操作

#

resource.type="k8s_cluster"
AND log_id("cloudaudit.googleapis.com/activity")
AND protoPayload.methodName="io.k8s.core.v1.pods.delete"
AND protoPayload.resourceName="core/v1/namespaces/NAMESPACE/pods/POD_NAME"

Kubernetes API への書き込み操作は、Admin Activity 監査ログに残ります。リソースの種類は k8s_cluster です（GKE の監査ログ）。誰が実行したかは protoPayload.authenticationInfo.principalEmail で見ます。

確認: 公式例（公式例は create|delete の正規表現と、resourceName で Pod を指定する形）

Compute Engine

#

Ops Agent で集めたログ

#

resource.type="gce_instance"
AND log_id("nginx_access")

Ops Agent で集めたログは、通常は config.yaml に書いたレシーバ ID がログ ID になります。fluent_forward では、受信したタグが RECEIVER_ID.TAG の形で付きます（Ops Agent の設定）。自分の環境のログ ID は、1件開いて logName で確かめます。

確認: 公式例（resource.type と log_id() で絞る形）。log_id("nginx_access") だけの条件は実ログでも確認済み（解説編）

VM を削除した操作

#

resource.type="gce_instance"
AND log_id("cloudaudit.googleapis.com/activity")
AND protoPayload.methodName:"compute.instances.delete"
AND protoPayload.resourceName:"INSTANCE_NAME"

確認: 公式例

VM が止まった理由（プリエンプト・ゲスト OS からの停止）

#

resource.type="gce_instance"
AND log_id("cloudaudit.googleapis.com/system_event")
AND protoPayload.methodName=~"compute\.instances\.(guestTerminate|preempted)"
AND resource.labels.instance_id="INSTANCE_ID"

Google Cloud 側が行った操作は、System Event 監査ログに入ります。利用者の操作が入る Admin Activity とは別のログです（Cloud Audit Logs）。

確認: 公式例

Cloud Load Balancing

#

グローバル外部 ALB とリージョン外部 ALB では、resource.type が違います。 片方の種別で書くと、もう片方のログはエラーにならず検索対象から外れます。

グローバル外部 ALB の 5xx

#

resource.type="http_load_balancer"
AND httpRequest.status>=500

確認: 公式例

リージョン外部 ALB の 5xx

#

resource.type="http_external_regional_lb_rule"
AND httpRequest.status>=500

確認: 仕様。resource.type は実ログでも確認済み（セッションアフィニティの検証）。httpRequest.status>=500 を含むクエリ全体は未実行

特定パスの 4xx

#

resource.type="http_load_balancer"
AND httpRequest.status>=400 AND httpRequest.status<500
AND httpRequest.requestUrl:"/api/"

httpRequest.requestUrl にはスキーム・ホスト・パス・クエリ文字列がまとめて入ります（HttpRequest）。パスだけを = で比べても一致しないので、: で探します。

確認: 仕様

失敗の理由で絞る

#

resource.type="http_load_balancer"
AND jsonPayload.statusDetails="backend_timeout"

resource.type="http_external_regional_lb_rule"
AND jsonPayload.proxyStatus:"http_response_timeout"

ステータスコードだけでは、ロードバランサが返したのかバックエンドが返したのかが分かりません。理由のフィールドを見ます。値の一覧は各ロードバランサのログの資料にあります。

確認: 仕様。statusDetails の値はグローバル外部 ALB の公式資料で確認済み。proxyStatus の http_response_timeout は実ログでも確認済み（proxy-only サブネットの検証）

遅いリクエスト

#

resource.type="http_load_balancer"
AND httpRequest.latency>"1s"

httpRequest.latency は Duration 型なので、"1s" や "500ms" と大小比較できます（Comparison operators）。

確認: 仕様

Cloud Audit Logs

#

Admin Activity は cloudaudit.googleapis.com/activity、Google Cloud 側の操作は cloudaudit.googleapis.com/system_event に入ります。監査ログの種類と既定の有効・無効は解説編にまとめてあります。

削除操作

#

log_id("cloudaudit.googleapis.com/activity")
AND protoPayload.methodName:"delete"

結果は protoPayload.authenticationInfo.principalEmail（誰が）、protoPayload.methodName（何を）、protoPayload.resourceName（どれに）の順に見ます。create や update も探すなら protoPayload.methodName:("create" OR "delete" OR "update") と書きます。

確認: 公式例（Resource creation, modification, or deletion）

特定ユーザーの操作

#

log_id("cloudaudit.googleapis.com/activity")
AND protoPayload.authenticationInfo.principalEmail="USER_EMAIL"

サードパーティ ID で認証した呼び出しでは、principalEmail が空で principalSubject のほうが入ります（AuditLog）。

確認: 公式例（Kubernetes pod requests from users の principalEmail 条件）

特定リソースへの操作

#

log_id("cloudaudit.googleapis.com/activity")
AND protoPayload.resourceName:"RESOURCE_NAME"

resourceName はサービスごとに書式が違いますが、: なら名前の一部だけでも絞り込めます。=~ にすると値が正規表現として解釈されるので、名前に . などを含むときは注意します。

確認: 公式例（VM Instance Deleted with Name の resourceName:）

IAM ロールを付与した操作

#

log_id("cloudaudit.googleapis.com/activity")
AND resource.type="project"
AND protoPayload.methodName="SetIamPolicy"
AND protoPayload.serviceData.policyDelta.bindingDeltas.action="Add"
AND protoPayload.serviceData.policyDelta.bindingDeltas.member:"USER_EMAIL"

ロールを外した操作を探すなら、action="Remove" にします。

確認: 公式例（Role granted to principal）

PERMISSION_DENIED になった呼び出し

#

logName:"cloudaudit.googleapis.com"
AND protoPayload.status.code=7

7 は google.rpc.Code の PERMISSION_DENIED です。ログ ID を1つに決めず、監査ログ全体から探します。

確認: 仕様

IAP 経由の SSH 接続

#

protoPayload.serviceName="iap.googleapis.com"
AND protoPayload.methodName="AuthorizeUser"

AuthorizeUser は、IAP の TCP 転送を通した接続の試行で記録される methodName です（SSH 監査の資料）。gcloud compute ssh --tunnel-through-iap の記録を探すときに使います。serviceName を加えて、IAP のエントリだけに絞ります（IAP の監査ログ）。

IAP の Data Access 監査ログを有効にしていないと出ません。 参照した検証では、ADMIN_READ・DATA_READ・DATA_WRITE の3種類を有効にしたあとで記録されました。どの種類が必要かまでは切り分けていません。

確認: 実ログ（IAP 経由の SSH の検証）。methodName で一致した2件は、いずれも serviceName="iap.googleapis.com"

VPC Flow Logs

#

VPC Flow Logs を有効にしていなければ記録されません。どの API で設定したかで、resource.type とログ ID が変わります（Access VPC Flow Logs）。

以下の例は Compute Engine API で設定した場合です。Network Management API で設定した場合は、resource.type とログ ID を表の値に置き換えます。どちらか分からなければ、1件開いて resource.type と logName を見ます。

絞ったあとは、jsonPayload.connection にある送信元・宛先の IP とポート、プロトコルの5つで探します（レコードの形式）。

宛先のサブネットで絞る

#

resource.type="gce_subnetwork"
AND log_id("compute.googleapis.com/vpc_flows")
AND ip_in_net(jsonPayload.connection.dest_ip, "SUBNET_CIDR")

ip_in_net() は、フィールドの IP が範囲に入っていれば真になります。フィールドが無い、または IP として読めない値のときは偽です（ip_in_net）。

確認: 公式例

ポートとプロトコルで絞る

#

resource.type="gce_subnetwork"
AND log_id("compute.googleapis.com/vpc_flows")
AND jsonPayload.connection.dest_port=443
AND jsonPayload.connection.protocol=6

protocol は IANA のプロトコル番号で、TCP は 6、UDP は 17 です。tcp のような名前では一致しません。

確認: 公式例（公式例は src_port）

Cloud Run

#

サービスは cloud_run_revision、ジョブは cloud_run_job です（Cloud Run のログ）。

サービスのエラー

#

resource.type="cloud_run_revision"
AND resource.labels.service_name="SERVICE_NAME"
AND severity>=ERROR

確認: 公式例（公式例は service_name の条件まで）

5xx を返したリクエスト

#

resource.type="cloud_run_revision"
AND log_id("run.googleapis.com/requests")
AND httpRequest.status>=500

リクエストログはサービスにだけあり、ジョブにはありません。

確認: 公式例（Cloud Run のログのリクエストログの例）

構造化ログを探す

#

ペイロードは textPayload（テキスト）・jsonPayload（JSON）・protoPayload（監査ログなど）のどれか1つです。jsonPayload と labels のキーは、大文字小文字を区別します。 jsonPayload.endTime と jsonPayload.end_time は別のフィールドです（Field path identifiers）。

JSON のフィールドで絞る

#

resource.type="k8s_container"
AND jsonPayload.order_id="1234"

キーに . や / を含むときは、jsonPayload."http.req.method" のようにそのキーだけを引用符で囲みます。

確認: 仕様。別の条件（jsonPayload.msg:）での絞り込みは実ログでも確認済み（GKE のログ形式の検証）

テキストに文字列を含む

#

resource.type="k8s_container"
AND textPayload:"connection refused"

確認: 仕様。textPayload: の部分一致は、別の文字列（"PLAIN"）で実ログでも確認済み（GKE のログ形式の検証）

フィールドを指定して SEARCH()

#

resource.type="k8s_container"
AND SEARCH(jsonPayload.message, "timeout")

SEARCH() にフィールドを渡すと、そのフィールドだけを語単位で探します。テキスト以外のフィールドには使えません（SEARCH function）。

確認: 仕様

正規表現・除外・複数条件

#

Pod 名の前方一致

#

resource.type="k8s_container"
AND resource.labels.pod_name=~"^api-"

Deployment 配下の Pod 名にはハッシュなどの生成された文字列が付くため、完全一致では追いにくくなります。前方一致で、同じ Deployment の Pod をまとめて見ます。大文字小文字を無視するなら "(?i)^api-" です。

確認: 仕様

ヘルスチェックを除外する

#

resource.type="http_load_balancer"
AND NOT httpRequest.requestUrl:"/healthz"

httpRequest は LogEntry に定義されたフィールドなので、無いエントリも既定値で比べられ、除外されずに残ります。

ペイロードや labels の中のフィールドでは、NOT と != で結果が変わります。 NOT jsonPayload.x="foo" は x の無いエントリも含み、jsonPayload.x!="foo" は含みません。どちらが欲しいかを決めて書きます（Missing fields）。

確認: 仕様

よく使う組み合わせ

#

障害の時間帯だけを見る

#

resource.type="k8s_container"
AND resource.labels.namespace_name="NAMESPACE"
AND severity>=WARNING
AND timestamp>="2026-09-23T10:00:00+09:00" AND timestamp<"2026-09-23T10:30:00+09:00"

発生時刻の前後だけに絞ると、平常時から出ている警告と区別しやすくなります。この形にすると時間範囲セレクタは使えません（Sample queries）。

確認: 仕様

トレース ID で1リクエストを追う

#

trace="projects/PROJECT_ID/traces/TRACE_ID"

trace は常にインデックスされるため、この条件だけでもインデックスを使って絞り込めます。対象のサービスが分かっていれば、resource.type も加えると検索範囲をさらに狭められます（Optimize your queries）。ロードバランサとアプリが同じトレース ID を記録していれば、両方のログが並びます。

確認: 公式例（公式例は resource.type="gae_app" との組み合わせ）

クエリで出ないときは

#

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

何を疑う順に確かめるかは解説編の「0件だったときに疑う順」にまとめてあります。--freshness の既定値、収集していないログ、保持期間、除外フィルタを扱っています。

まとめ

#

• インデックスの効くフィールドで先に絞る。 resource.type・resource.labels.*・logName・severity・timestamp から書き始める
• AND と OR を混ぜたら括弧を付ける。 OR が AND より先に結び付く。小文字は検索語になる
• ロードバランサは種類で resource.type が違う。 グローバルとリージョンで失敗理由のフィールドも違う
• log_id() の引数は URL エンコードしない
• クエリに timestamp を書くと、それが検索期間になる。 時間範囲セレクタは使えなくなる
• 「仕様」のクエリはフィールドが入っていることが前提。 ペイロードや labels に無ければ、エラーにならず一致しない

参考資料

#

• Logging query language
• Sample queries
• LogEntry
• AuditLog
• Cloud Audit Logs overview
• External Application Load Balancer logging and monitoring
• Regional external Application Load Balancer logging and monitoring
• About VPC Flow Logs records
• Access VPC Flow Logs
• GKE audit logging
• IAP audit logging
• Best practices for auditing SSH access
• Ops Agent configuration
• Logging and viewing logs in Cloud Run
• google.rpc.Code
• Monitored resource types
• Cloud Logging クエリの解説編