【GCP】Cloud Loggingをざっくり解説

こんにちは。SCSKの劉です。

Cloud Logging は GCP の各サービスを利用する際に、生成したログを収集・保管・管理する仕組みです。
記録可能なログの種類や保管期間などを知っておくと、非機能要件を設計する際に少ない実装で済むので、今回はそれについてざっくり解説していきたいと考えます。

ログの保存先

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

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

ログの保存先

ログバケット

Cloud Logging では、ログデータを保存して整理するためのコンテナとして、_Required と _Default という 2 つのログバケットを使用します。

_Required と _Default との保持期間がそれぞれ異なります。

ログバケット デフォルトの保持期間 カスタム保持 備考
_Required 400 日 構成不可 400日以上保存の場合、GCS・ユーザー定義ログバケットにエクスポート
_Default 30日 構成可能 最大10年間までカスタム可能
ユーザー定義 30日 構成可能 構成可能

 

Cloud Logging ログの種類

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

  1. GCPの監査ログ
    1. 管理アクティビティ監査ログ
    2. データアクセス監査ログ
    3. システム イベント監査ログ
    4. ポリシー拒否監査ログ
  2. 他のクラウドサービスのログ
  3. ユーザーがエクスポートしたログ

上記のログは、全てGCPコンソールの ログエクスプローラ より閲覧・クエリが可能です。

また、ログから特定の内容を検出し、指定されたユーザーにアラートメールを送信する機能(Cloud Monitoring)もあります。

GCPの監査ログ

GCPでの監査ログが自動的に相応のログバケットに収集されます。

  • _Required バケット
    • 管理アクティビティ監査ログ
    • システム イベント監査ログ
  • _Defaultバケット
    • データアクセス監査ログ
    • ポリシー拒否監査ログ

監査ログの概要を以下にまとめられます。

監査ログの種類 概要 デフォルト状態 デフォルト状態 料金
管理アクティビティ監査ログ VMやネットワーク、IAMの変更操作内容 有効(無効不可) 400日
(変更不可)
無料
データアクセス監査ログ BigQueryやCloud Storageのデータアクセス BigQueryのみ有効 30日 一定量超えると有料
システムイベント監査ログ Google Cloudのシステムイベント 有効(無効不可) 400日
(変更不可)
無料
ポリシー拒否監査ログ VPC Service Controlsによって拒否されたアクセス 有効(無効不可、除外可能) 30日 一定量超えると有料

他のクラウドサービスのログ

Cloud LoggingはGCPのログを収集・管理するほかに、他のクラウドサービスからログを取り込むことも可能です。

  • Microsoft Azure
  • AWS
  • Workspace

ユーザーがエクスポートしたログ

VMから、エージェントやAPI経由でCloud Loggingに投入したログです。

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

上記ログをCloud Loggingに収集すると、ログの一元管理が可能となり、システムに障害が発生するとき、ログの紛失を回避することが可能などのメリットがあります。

ログの一元管理

上記で説明したように、Cloud Loggingでは、数多くのログが収集されています。

GCPでは、プロジェクト単位でCloud Loggingがログの収集を行っているほか、組織もログを生成しています。

案件が大規模になると、プロジェクトも増えて、管理が困難になります。

この問題を解決するGoogleが推奨するベストプラクティスでは、ログ格納用のプロジェクトを別途用意し、シンクを用いて組織・組織下のプロジェクトのログを全てそこに集約することです。

Googleのベストプラクティス

ログの一元管理は、以下のケースが考えられます。

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

最後に

今回はCloud Loggingついて簡単にご紹介させていただきました。
GCPで非機能要件を設計する際の参考になれば幸いです。

最後まで読んでいただき、ありがとうございました!!!

タイトルとURLをコピーしました