Cloud Loggingの概念と仕組みをしっかり解説

記事タイトルとURLをコピーする

G-genの杉村です。Cloud Logging は Google Cloud (旧称 GCP) 上のシステム等が生成したログを収集・保管・管理する仕組みです。基本的な概念や仕組みを解説していきます。

Cloud Logging 概要

Cloud Logging とは

Cloud Logging (旧称 Stackdriver Logging) は Google Cloud 上のシステム等が生成したログを収集・保管・管理する仕組みです。

各 Google Cloud サービスが出力するログは自動的に Cloud Logging に集められるほか、API や VM 上のエージェントを通じて任意のログを収集させることができます。

収集されたログは ログバケット と呼ばれるストレージで保管され、期限が過ぎたら廃棄する等の設定を簡単に行うことができます。

ログはコンソールの ログエクスプローラ で閲覧・クエリすることができます。さらに、指定の文字列がログに出力された際にアラートを上げるような設定も可能です。

対象のログ

Cloud Logging が扱うログは 以下の4種類 です。

  1. Google Cloudサービスが生成するログ
    • BigQuery や Cloud Run、Cloud Functions 等、ほとんどの Google Cloud サービスのログ出力先が Cloud Logging
  2. ユーザーが生成するログ
    • VM のエージェント経由や API 経由でユーザーが Cloud Loggingに投入したログ
  3. セキュリティログ
    • 3-1. Cloud Audit Logs のログ
    • 3-2. アクセスの透明性ログ (Google サポート等がユーザのコンテンツにアクセスした際に出るログ)
  4. マルチクラウドとハイブリッド クラウドのログ
    • Microsoft Azure や Amazon Web Services (AWS) から取り込んだログやオンプレミスから取り込んだログ

ログの保存先

Cloud Logging の保存先ストレージは ログバケットCloud Storage バケットBigQuery データセット から選択できます。

ログバケット は「Cloud Storage バケット」と名称が似ていますが 全く別のもの であり、Cloud Logging の独自ストレージです。

ログバケットに保管されているログだけが、 Cloud Logging コンソールのログエクスプローラーから閲覧できます。

保管料金は Cloud Logging の料金概要 ページの ロギングのストレージ の通りであり、 Cloud Storage バケットの料金よりも 少し安い のがポイントです。

Cloud Storage バケットBigQuery データセットにログを保存する場合の保管料金はそれぞれの料金ページを参照ください。

料金

Cloud Logging の料金

Cloud Logging の料金は 取り込み処理量ストレージ の2軸で計算されます。

"取り込み処理量" は、Cloud Logging ログバケットに取り込むログの GB 数に応じて料金が発生します。

"ストレージ" はログバケットの保管ストレージにかかる料金です。

2023年5月現在の料金は以下です。

  • 取り込み料金: $0.50 / GiB
    • Cloud Logging ログバケットに投入されたログのサイズに応じて課金
    • 毎月プロジェクトごとに最初の 50 GiB は無料
  • ストレージ: $0.01 / GiB
    • 30 日以上保管するログバケット上のログにのみ適用。 30 日以内の保管なら無料
    • ログを BigQuery や Cloud Storage 等、他のサービスに転送する場合はそちらの料金が発生

最新の料金は以下のページを参照してください。

最初から存在するログバケットの料金

Google Cloud プロジェクトを作成すると、デフォルトで _Required_Default という二つのログバケットが存在しています。

_Required ログバケットに保存されるログは、取り込み料金もストレージ料金も発生しません。Google Cloud が必須で取得する監査系のログが投入されるログバケットだからです。

_Default は初期設定では保持期限が 30 日ですので、保持期限を変更していなければストレージ料金は発生しません。ただし取り込み処理料金は発生することに注意してください。

ただしプロジェクトごとに最初の取り込み 50 GB の無料枠がありますので、相当量が無料で取り込めることになっています。

ストレージ料金の課金開始

前述の料金のうち、後者の「ストレージ」料金は 2023/04/01 から課金開始されたものであり、それ以前は料金が発生していませんでした。経緯や対策などについては、以下の記事をご参照ください。

blog.g-gen.co.jp

取り込み料金の節約

$0.50 / GiB の取り込み料金は、ログのボリュームが大きくなるとコストとして重くのしかかってきます。この取り込み料金は Cloud Logging ログバケットに対して取り込むログサイズに対してのみ 発生します。

つまり、以下のログに対しては料金が発生しません。

  • シンク (後述) により Cloud Storage バケット / BigQuery データセット / Pub/Sub トピックにルーティングされたログ
  • シンクの除外フィルタで除外したログ

ログ量が莫大になり取り込み料金が多く発生している場合、除外フィルタで取り込むログをフィルタリングしたり、Cloud Storage や BigQuery に逃がすことで、料金を節約できます。ただし、ルーティング先の取り込み料金も発生しますので、そちらを確認する必要はあります。

例として Cloud Logging ログバケットへの取り込みと BigQuery へのエクスポートで料金を比較すると、以下の通りです。

BigQuery へログをエクスポートすると Streaming inserts 料金が発生しますが、Cloud Logging ログバケットへの取り込み料金と比較して、十分の一近くの料金設定となっています。

Cloud Logging が扱う4種類のログ

1. Google Cloudサービスが生成するログ

様々な Google サービスが、ユーザが意識しなくとも、Cloud Logging にログを出力しています。

これのおかげで、利用者はコンソール画面でいちいち各 Google サービスの画面へ飛ばなくても、 Cloud Logging で集中的にログを閲覧することができます。

2. ユーザーが生成するログ

ユーザーが明示的に Cloud Logging に投入したログです。

Google Compute Engine (GCE) の VM インスタンス等から Ops エージェント などを通して投入することができます。

Cloud Logging にログを投入することで以下のようなメリットを享受できます。

  • ログ閲覧の際にサーバにログインする必要がない
  • サーバ障害やスケールインした際にもログがロストしない
  • 分析目的で BigQuery に連携するなどが容易に実装できる
  • ログの保管と保管期限管理が容易に実装できる

VM に Ops エージェントをインストールすると Linux では /var/log/messages/var/log/syslog が、 Windows では System , Application , Security のイベントログが、デフォルトで収集されます。

デフォルトで収集されるログ以外にも、設定ファイルを変更することで、任意のアプリケーションのログを収集することができます。 詳細は公式 ドキュメント を参照ください。

Compute Engine の VM から Cloud Logging にログを送出する方法については、以下の記事もご参照ください。

blog.g-gen.co.jp

また Cloud FunctionsCloud Run 等の Google Cloud サービスで稼働するプログラムから Cloud Logging へログを出力できます。

これらのサービスでは何も設定しなくても、標準出力が Cloud Logging にログエントリとして連携されますが、適切なフォーマットで出力することで Severity (重要度) などを Cloud Logging で効果的に出力することができます。以下の記事も参考にしてください。

blog.g-gen.co.jp

3. セキュリティログ

Cloud Audit Logs サービスによって生成されるログです。

Cloud Audit Logs については以下の投稿で解説していますので、そちらを参照してください。

blog.g-gen.co.jp

4. マルチクラウドとハイブリッド クラウドのログ

マルチクラウドとハイブリッド クラウドのログ は便宜上、他クラウドやオンプレミスから取り込んだログを分類していますが、本質的には 2. ユーザーが生成するログ と同等です。

ログの閲覧

閲覧方法

Cloud Logging に保存されたログは Google Cloud の Web コンソールの ログエクスプローラ と呼ばれる画面で閲覧することができます。

ログエクスプローラ

また他にも gcloud コマンドラインツールを用いて ログを表示 することも可能です。

クエリ言語

ログエクスプローラや gcloud コマンドでは独自の クエリ言語 を用いて、ログをフィルタして表示させることができます。

以下は、クエリ言語の例です。my-project というプロジェクトにおける Cloud KMS 関連のログだけを抽出しています。

protoPayload.serviceName="cloudkms.googleapis.com"
resource.labels.project_id="my-project"

コンソール画面から GUI で直感的にクエリ言語を生成できますので、学習コストはそこまで高くはありません。

インデックス

Cloud Logging のエントリ (一つ一つのログデータ) には インデックス の概念があります。

以下のフィールドにはインデックスが貼られており、クエリに含めることで抽出を高速化できます。

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

またログバケットごとに カスタムインデックス をフィールドに対して明示的に指定することができます。

ログルーティングとログの保存

ログルーティングとは

Cloud Logging で特に大事な概念が ログルーティングシンク (sink) です。おおまかな概念を以下に図示します。

ログルーティングの概念

最上部が、ログの発生元です。ここからログが Cloud Logging API に向けて投入されます。

投入されたログは ログルーター により振り分け先を決定されます。

ログルーターは シンク という個別の設定を持っており、ログはシンクに定義された設定に応じて保存先に振り分けられます。

ログの振り分け先としてログバケットCloud Storage バケットBigQuery データセットPub/Sub トピック他の Google Cloud プロジェクトを指定することができます。

シンクとは

シンクは Cloud Logging に入ってきたログの振り分けをするコンポーネントです。

API を通じて Cloud Logging に入ってきたログは、シンクによって宛先であるログバケットや BigQuery などに振り分けられます。

シンクは設定値として 1. ログの保存先 , 2. 包含フィルタ , 3. 除外フィルタ を持ちます。

まず 1. ログの保存先 は前述の通り「ログバケット」、「Cloud Storage バケット」、「BigQuery データセット」、「Pub/Sub トピック」のいずれかを指定します。

そして 2. 包含フィルタ と 3. 除外フィルタ は、そのシンクがどのログを ログの保存先 に振り分けるかを決定するためのフィルタであり、 Logging query language で定義します。以下のようなものです。

resource.type="bigquery_dataset" AND
LOG_ID("cloudaudit.googleapis.com/activity") AND
protoPayload.methodName="google.cloud.bigquery.v2.DatasetService.UpdateDataset" 

上記は「BigQuery データセットが UpdateDataset により更新されたときに発生したアクティビティログをキャッチせよ」という意味です。

なお、複数のシンクでフィルタの設定が重複していて、同じログをキャッチするようになっている場合、それら全てのシンクにログが 複製されて振り分けられ ます。

たとえばシンクAはあるログをあるログバケットに転送する設定になっており、シンクBは同じログを BigQuery に投入する設定になっているとします。この場合は、ログバケットと BigQuery の両方に、同じログが投入されます。

初期設定で存在するシンク

初期設定で _Required_Default というシンクが存在しています。それぞれのシンクは同名の _Required_Default というログバケットにログをルーティングする設定になっています。

_Required ログバケット には「管理アクティビティ監査ログ」「システム イベント監査ログ」「アクセスの透明性ログ」が保存され、400日間保存されます。

なお「管理アクティビティ監査ログ」「システム イベント監査ログ」は Cloud Audit Logs という監査の仕組みによって取得されるログです。

_Default ログバケット には、初期設定では _Required に入らない全てのログが入ることになります。

これらのバケットに発生する料金は前述の 最初から存在するログバケットの料金 をご参照ください。

書き込み ID

シンクを作成した際、振り分け先が「そのシンクが所属するプロジェクトのログバケット 以外 」だった場合、 書き込み ID (Writer Identity) と呼ばれるサービスアカウントが生成されます。

この書き込み ID に対して、書き込み先への権限を付与する必要があります。

書き込み ID の名称はコンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行することで確認できます。

書き込み ID の確認

例えば書き込み先が BigQuery データセットの場合、当該の BigQuery データセットにおいて書き込み ID に BigQuery データ編集者 権限を付与する必要があります。

なおシンクと同じプロジェクト内のログバケットへログを送る際は、書き込み ID は不要であり、作成されません。

書き込み ID はシンクを作成するごとに一意に生成されます。後述する集約シンクを作成する際には組織レベルやフォルダレベルでシンクを作成しますが、シンクが作成されるレベルによって書き込み ID の命名規則が異なります。

No シンクのレベル 書き込み ID の名称
1 プロジェクトに作成されたシンクの書き込み ID p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com
2 フォルダレベルで作成されたシンクの書き込み ID f(フォルダ番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com
3 組織レベルで作成されたシンクの書き込み ID o(組織番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com

プロジェクトをまたいだログの集約

別プロジェクトのストレージにログを送る

Cloud Logging のシンクを使い、別のプロジェクトのログバケットや BigQuery データセットにログをルーティングすることができます。

この場合、シンクの書き込み ID が宛先のストレージに対して書き込み権限を持っている必要があります。

またシンクの宛先を「他の Google Cloud プロジェクト」にした場合、宛先プロジェクト内のログシンクに処理を委任することができます。次の項で説明するような組織構成を使わない場合でも、この方法でログの処理を1プロジェクトに集約することが可能です。

組織全体でログを集約する

以下のような理由で、組織全体でログを一つのプロジェクトのログバケットや BigQuery に集約したい要件が出てくるかもしれません。

  • 複数プロジェクトのログを集約してSIEMツール等で分析したい
  • 監査などの理由で監査ログを第三者に提出する必要がある
  • 複数プロジェクトでアプリケーションが稼働しておりログを横断して確認したい

その際は、シンクを組織やフォルダのレベルで作成し、配下の全てのプロジェクトのログを収集することが可能です。

このようなシンクを 集約シンク (Aggregated sinks) といいます。

シンクを作成する際に「このリソースとすべての子リソースによって取り込まれたログを含める」オプションを有効化することで、その組織/フォルダ配下の全てのプロジェクトに対してシンクが有効になり、ログ集約用のプロジェクトにログを収集できます。

詳細な手順は、以下を参考にしてください。

シンクによるログの集約

集約シンクの種類

集約シンクの作成時、非インターセプト型集約シンク(non-intercepting aggregated sink)とインターセプト型集約シンク(intercepting aggregated sink)の2種類から選択可能です。

前述の通り、組織の上流(組織のルートやフォルダ)で集約シンクを使用すれば、下流の子リソース(プロジェクト等)で発生するログを集約することが可能ですが、非インターセプト型集約シンクの場合は、親リソースの非傍受型集約シンクで収集したログは、子リソースでも収集することができます。一方のインターセプト型集約シンクの場合、上流のシンクで収集したログはそれより下流の子リソースでは収集できません。

インターセプト型シンクを使えば、子リソースでログを重複して収集し、ログ収集コストが肥大化することを避けることができます。逆に、子リソースでもログを自由に収集できるようにしたい場合は、非インターセプト型のシンクを利用します。

なおインターセプト型シンクは子リソース(プロジェクト)からも閲覧できます(コンソールのログルーター画面に表示されます)。

ログ監視

ログベースの指標

Cloud Logging でログの特定文字列を正規表現で検知し、その検知数を基準にして Cloud Monitoring に指標 (メトリクス) として送信することができます。これを ログベースの指標 と呼びます。

この指標を Cloud Monitoring の アラートポリシー 機能により検知・発報することで「XXログで Error という文字列を5分間で3個以上検知したらメール通知する」のようなログ監視が可能になります。

手順は以下をご参照ください。

ログベースのアラート

前述の発報方法は「ログベースの指標 + アラートポリシー」を組み合わせた方法ですが、より新しく利用可能になった方法として ログベースのアラート 機能が存在します。

この機能は、ログ文字列の検知数をいったん Cloud Monitoring の指標化する前述の方法とは異なり、特定文字列を検知すると直接、アラートを発報できます。

この「ログベースのアラート」は前述の「ログベースの指標 + アラートポリシー」とほとんど同じことが可能ではありますが、「ログベースのアラート」では文字列検知数を指標化しないため、数値として後から統計が取れない代わりに、より少ないステップで設定可能であるという違いがあります。

またその他の詳細な違いは以下もご参照ください。

Log Analytics

Log Analytics とは

Log Analytics は、Cloud Logging ログバケットに格納されているログに対して SQL でクエリすることができる機能です。

当機能リリース以前は、ログに対して SQL でクエリをかけるにはログルーター (シンク) を使って BigQuery へログをエクスポートする必要がありました。2023年1月に当機能が GA されて以降は、当機能により Cloud Logging ログバケットに直接 SQL を実行することが可能です。

またもう一つの機能としてログバケットを BigQuery データセットとリンク することができます。 BigQuery データセットとリンクされたログバケットは BigQuery 側からビューとして使うことができます。これにより BigQuery の他のデータと結合しての分析も可能になります。

利用方法

ログに SQL を実行するには、ログバケットごとに Log Analytics を有効化することが必要です。

有効化されたログバケットに対して Google Cloud コンソールの Log Analytics ページから BigQuery 標準 SQL を実行することができます。

コンソール画面

BigQuery データセットとのリンク

ログバケットごとに BigQuery データセットとのリンク を行うことができます。

リンクすると BigQuery に新規データセットが作成され、その中に _AllLogs というビューが生成されます。このビューに対してクエリを実行することでログを抽出できます。

またスキャンしたデータ量に応じて BigQuery の クエリ料金 が発生します。 一方で Log Analytics 画面からのクエリは無料です。

ユースケース

アプリケーションのトラブルシューティングや、アプリログを BigQuery の自社データやパブリックデータセット等と結合する等の用途が想定されます。

従来、こういった分析をするためにログルーター (シンク) を使って BigQuery にログをエクスポートして長期保存することもありました。

しかし Log Analytics 登場後は、事情が変わります。

Cloud Logging のログバケットの保存料金は、 BigQuery のストレージ料金 (アクティブ/長期保存) と同等あるいは安価です。

最終的に Cloud Logging ログバケットに保存したほうが安価になるのか、あるいは BigQuery の方が安価になるのか、については後述します。

制限

代表的な制限のみを記載します。制限の全体や最新情報は 公式ドキュメント をご参照ください。

  • クエリできるのは Log Analytics 有効化後に発生したログのみ
  • ログバケットが CMEK 暗号化されていない
  • ログバケットがロックされていない

Log Analytics の料金

Log Analytics では通常の Cloud Logging 以外に発生する追加料金はありません。 Log Analytics 画面からクエリした場合、クエリ料金も無料です。

一方でログバケットを BigQuery データセットとリンクして BigQuery からクエリした場合 BigQuery の クエリ料金 が発生します。

さて、ログをログバケットに保存するのと、BigQuery にエクスポートするのでは、最終的にどちらが安価になるのでしょうか。以下の要素が関わってきます。

  • ログ取り込み時の料金
  • クエリ時の料金
    • Cloud Logging (Log Analytics 画面) でのクエリ : 無料
    • BigQuery でのクエリ (オンデマンド料金) : $6 /TB (最初の 1TB は無料) (東京リージョン、2023年5月時点)

つまり、ログ取り込みの料金は BigQuery の方が安価ですが、クエリ時の料金は Cloud Logging (Log Analytics 画面) のほうが安価 (無料) ということで、一長一短です。利用実績を確認し、どちらのほうが安価になるかを判断してから決定することになります。

サービス間連携

Cloud Functions to Cloud Logging

以下は、Cloud Functions から Cloud Logging へログを投入する方法について解説した記事です。Cloud Functions では標準出力に文字列を出力するだけで Cloud Logging へログとして投入されますが、特定の設定をすることで 重要度 (Severity) 等を適切に Logging に適用することができます。

blog.g-gen.co.jp

Compute Engine VM (Windows) to Cloud Logging

以下は Compute Engine VM から Cloud Logging へ任意のログファイルを取り込むための方法を紹介した記事です。Ops Agent という Cloud Monitoring のエージェントソフトウェアをインストールすることで実現できます。

blog.g-gen.co.jp

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。