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

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

G-genの杉村です。

Cloud Logging は Google Cloud (GCP) 上のシステム等が生成したログを収集・保管・管理する仕組みです。
かつては Stackdriver Logging と呼称されていました。
使いこなすことで情報システムの非機能要件のうち大きなテーマである ログ管理 を少ない実装で行うことができます。

Cloud Logging の基本的な概念や仕組みを解説していきます。

f:id:ggen-sugimura:20211026164949p:plain
Cloud Logging

Cloud Logging 概要

Cloud Logging とは

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

Cloud Logging は API や VM にインストールしたエージェントを通じてログを収集できます。
また、収集されたログを ログバケット と呼ばれるストレージで保管したり、期限が過ぎたら廃棄する設定を簡単に行うことができます。
コンソールの ログエクスプローラ でログを閲覧・クエリしたり、ダッシュボードで管理したり、指定の文字列が検知された際にアラートを上げるような設定も可能です。

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

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

Cloud Logging の料金

Cloud Logging の料金は 取り込み処理量ストレージ の2軸で計算されます。
"取り込み処理量" は、取り込むログの GB 数に応じて料金が発生します。
"ストレージ" はログの保管ストレージにかかる料金です。

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

ログの保存先

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

ログバケット は Cloud Storage バケットと 名前が似ていますが別のものです
ログバケットに保管されているログだけが、 Cloud Logging コンソールのログエクスプローラーから閲覧できます。
保管料金は Cloud Logging の料金概要 ページの ロギングのストレージ の通りであり、 Cloud Storage バケットの料金よりも 若干安い のがポイントです。

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

Cloud Logging が扱う4種類のログ

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

様々な Google サービスが (ユーザが意識しようとしなかろうと) Cloud Logging にログを出力しています。
これのおかげで、利用者はコンソール画面でいちいち各 Google サービスの画面へ飛ばなくても、 Cloud Logging で集中的にログを閲覧することができます。

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

ユーザーが明示的に Cloud Logging に投入したログです。
Google Compute Engine (GCE) の VM インスタンス等から Ops エージェントなどを通して投入することができます。
Cloud Logging にログを投入することで以下のようなメリットを享受できます。

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

3. セキュリティログ

Cloud Audit Logs サービスによって生成されるログです。
Cloud Audit Logs については以下の投稿で解説しています。

blog.g-gen.co.jp

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

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

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

ログルーティングとは

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

f:id:ggen-sugimura:20211023183105p:plain
ログルーティングの概念

最上部が、ログの発生元です。ここからログが Cloud Logging API に向けて投入されます。
投入されたログは ログルーター により振り分け先を決定されます。

ログルーターは シンク という設定を持っていて、シンクに定義された設定に応じて、ログの保存先が決まります。
ログの保存先は ログバケットCloud Storage バケットBigQuery データセットPub/Sub トピック を指定することができます。

シンクとは

シンクは Cloud Logging に入ってきたログの振り分けを決定する設定です。
シンクは ログの保存先 包含フィルタ 除外フィルタ を設定として持ちます。

ログの保存先 は前述の通り、ログバケット 、Cloud Storage バケット、BigQuery データセット、 Pub/Sub トピックのいずれかです。
包含フィルタ 除外フィルタLogging query language で定義します。以下のようなものです。

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

上記の例の Logging query language が含有フィルタに設定されている場合、そのシンクは BigQuery データセットの更新によるログをキャッチします。

なお同じログをキャッチするシンクが複数あっても、相互に干渉しません。
たとえばシンクAはあるログを XXX というログバケットに転送し、シンクBが同じログを BigQuery に投入する設定になっているとします。
この場合は、ログバケットにも BigQuery にも同じログが入ることになります。

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

初期設定で _Required_Default というシンクが存在しています。

_Required ログバケット には「管理アクティビティ監査ログ」「システム イベント監査ログ」「アクセスの透明性ログ」が保存され、400日間保存されます。
_Required ログバケットに保存されるログは、取り込み料金もストレージ料金も発生しません。

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

_Default ログバケット には、初期設定では _Required に入らない全てのログが入ることになります。
_Default ログバケットのログはデフォルトで30日間保存されます。 Cloud Logging では30日間以内に削除されたログには保管料金がかかりませんが、取り込み処理料金は発生することに注意してください。
※ただしプロジェクトごとに最初の取り込み 50 GB の無料枠がありますので、相当量が無料で取り込めることになっています。

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

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

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

シンクを作成するとそのシンク用のサービスアカウントが自動的に生成されるため、このサービスアカウントに権限を付与する必要があります。
このサービスアカウントは 書き込みID と呼ばれ、シンクの詳細情報を describe するとサービスアカウント名が分かります。

なお自プロジェクト内のログバケットへログを送るシンクを作成した際には、書き込みID (サービスアカウント) は作成されません (不要です) 。
自プロジェクト内の BigQuery データセット等のリソースにログを送るシンクを作成した際には、書き込みID (サービスアカウント) が自動作成され、自動的に権限が付与されます。

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

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

  • 複数プロジェクトのログを集約してSIEMツール等で分析する必要がある場合
  • 監査などの理由で監査ログを第三者に提出する必要がある場合
  • 複数プロジェクトを横断して監査ログをクエリする必要がある場合

その際は、以下の手順でシンクを組織やフォルダに作成することができます。
このようなシンクを 集約シンク (Aggregated sinks) といいます。

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

f:id:ggen-sugimura:20211013183540p:plain
シンクによるログの集約

ログベースの指標 (ログ監視)

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

これにより「XXログで Error という文字列を5分間で3個以上検知したらメール通知する」のようなログ監視が可能になります。

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

杉村 勇馬 (記事一覧)

クラウドソリューション部 部長

クラウド管理運用やネットワークに知見あり。AWSの全12資格をコンプリートしたので、次はGoogle Cloudの認定資格を狙っている。現在、Google Cloud認定資格は3冠。

2021年12月現在、ハマっているものはマーベル (遅い)