Zenn
📝

【Cloud Logging】ログの絞り込み方の基本

に公開
Google Cloud
error
Google
log
Cloud Logging
tech

はじめに

エラー調査のために Cloud Logging を使う機会がありました。
実際に使ってみると、対象のログをどう絞り込むかで少し悩んだため、今回は Cloud Logging 初心者でもすぐに使える「ログの絞り込み方の基本」をまとめてみました！

これだけ知っておけば最低限困らない！ という基礎的な内容です。
ログの見方がよくわからない…という方の参考になれば嬉しいです。

Cloud Loggingとは

Cloud Logging は、Google Cloud Platform（GCP）のログ収集・検索・分析ツールです。
https://console.cloud.google.com/logs/

エラー調査・運用監視・APIトレース・監査ログ確認などの用途で用いられます。

クエリでログを絞り込む基本

Cloud Logging では独自のクエリ言語を使ってログをフィルタできます。以下に実用的な絞り込み方を紹介します。

① 時刻の指定

期間指定

timestamp >= "2025-06-01T00:00:00Z"
timestamp < "2025-06-02T00:00:00Z"

このようにISO形式で書きます。
>= 開始 と < 終了 をセットで使うことで期間指定することができます。
このクエリは、「日本時間の 6月1日 午前9時 〜 6月2日 午前9時」までのログを取得していることになります。

この時刻以降のログを取得（開始だけ指定）

timestamp >= "2025-06-01T00:00:00Z"

→ 2025年6月1日0時（UTC）以降のすべてのログが対象。

この時刻より前のログを取得（終了だけ指定）：

timestamp < "2025-06-01T00:00:00Z"

→ 2025年6月1日0時（UTC）より前のすべてのログが対象。

GUIから指定

画面右上の「期間を選択」から

② ログレベル（severity）で絞る

severity >= ERROR

上から緊急度が高い順に9種類のログレベルが存在します。
このクエリはERROR以上でフィルタしています。

  • EMERGENCY
  • ALERT
  • CRITICAL
  • ERROR
  • WARNING
  • NOTICE
  • INFO
  • DEBUG
  • DEFAULT
GUIから指定

デフォルト+のところから指定できます。

③ リソースタイプ／サービス名で絞る

resource.type = "cloud_run_revision"
resource.labels.service_name = "xxx-app-xxx"

resource.typeはCloud Logging におけるリソースの種別（type）です。

resource.type 対象サービス
cloud_run_revision Cloud Run
k8s_container GKE（Google Kubernetes Engine）
gce_instance Compute Engine（VM）
cloud_function Cloud Functions
pubsub_topic Pub/Sub

https://cloud.google.com/monitoring/api/resources#tag_cloud_run_revision

resource.labels.service_name の 値はたとえば Cloud Run 作成時に設定したサービス名で、プロジェクト固有の値です。

④ JSON構造化ログのフィールド指定

Cloud Logging では、アプリケーションから出力されたログが JSON 形式で構造化されている場合、ログの本文は jsonPayload に格納されます。
そのため、JSON内の特定のフィールドを指定してログを絞り込むことができます。

jsonPayload.user_id = "abc-123-456-789-123"
jsonPayload.path = "/api/v1/login"

jsonPayloadの中のuser_idやpathなどのキーおよび値はプロジェクトのログの出し方によって異なるため、あくまでも一例です。

⑤ 全文検索（どこかに含まれる文字列）

("abc-123-456-789-123")

プレーンテキストや構造化ログのどこかに含まれていればヒットします。
とりあえずこのIdで絞り込み！というときにわりと使える...

⑥ AND / OR を使う

jsonPayload.status="FAILED" OR jsonPayload.error_code=500

複雑な条件を組み合わせて詳細に絞り込み可能。

⑧ 不要なクエリはコメントアウト

-- ("不要なクエリはコメントアウトできる")

少しクエリを調整したいとき、消す必要はなく--でコメントアウトすることができます。

おまけ：エラー調査を行うときの考え方

エラー調査を行うときは、いきなりログ全文を見るのではなく、「何を手がかりにログを絞り込むか」を考えることが大切です。

たとえば「この不具合の原因を調査してほしい」と依頼された場合、以下のような観点でログを絞っていくとスムーズです。
また、これらの観点で必要な情報が足りない場合は、事前に依頼者からヒアリングしておくことも大切です。

  • いつ発生した事象か？
    → timestamp を使って、対象の期間を絞ります。

  • どのサービスで発生したのか？
    → resource.type や resource.labels.service_name を指定することで、ログの発生元となるサービスを特定できます。特にマイクロサービス構成では、サービスごとにログが分かれていることが多いため、どのマイクロサービスで発生したエラーかを絞り込むことが特に重要です。

  • 操作していたユーザーは誰か？
    → jsonPayload.user_id など、ユーザーIDをログに出力している場合は、それを手がかりにフィルタできます。※ログの構造はプロジェクトの実装に依存します。

  • どんなリクエストをしたのか？
    → jsonPayload.request や jsonPayload.body に含まれるリクエスト内容を確認し、不正なパラメータや想定外の値が送られていないかを見ます。※こちらもログ出力の実装に依存します。

  • どのAPIで発生したのか？
    → jsonPayload.path や jsonPayload.procedure によって、どのエンドポイントに対する処理かを絞り込むことができます。※こちらもログ出力の実装に依存します。

まとめ

このように、「誰が・いつ・どこで・何をしたか」を軸に考えていくと、ログの調査はぐっと効率的になります。
Cloud Logging の絞り込み機能を使って、迷子にならずに原因にたどり着けるようにしましょう〜！

Discussion