GCPを活用していく上で必要なのは当然ながらログ。
ヘルスチェックであったりエラーになった際にすぐ原因究明をするためにはログを残すことが必須ですが、GCPではさまざまなソリューションが一度に動いています。
それらをしっかりログとして処理内容やエラー内容を残せるように、GCPのログの管理機能であるLoggingについてまとめてみたいと思います。
Contents
GCPのCloud Audit Logs(監査ログ)の種類
GCPではさまざまなログのデータ、つまりLoggingのデータがCloud Storageに保存されます。
そのため、Cloud Storageにログがどんどん溜まっていくので、Cloud Storageに溜まっているログに対して課金が発生します。
Loggingというリソースに対しての課金はないですが、それを保存する別リソースであるCloud Storageにお金がかかります。
まずGCPで取れるログにはさまざまなものがあります。
| ログの種類 | 説明 |
|---|---|
| 1. 管理アクティビティ監査ログ | Access Context ManagerなどユーザーがGCPのリソースやプロジェクトにアクセスした際にエラーになった場合に記録されるログ。 |
| 2. システムイベント監査ログ | 各GCPのリソースを稼働した際のログ。デフォルトではBigQueryのみ自動的にログを計測しますが、他のリソースでも自動的に取りたい場合は設定が必要。 |
| 3. データアクセス監査ログ | |
| 4. ポリシー拒否監査ログ | VP |
1. 管理アクティビティ監査ログ
管理アクティビティ監査ログには、リソースの構成またはメタデータを変更する API 呼び出しやその他の管理アクションに関するログエントリが含まれます。これらのログは、たとえば、ユーザーが VM インスタンスを作成したときや Identity and Access Management 権限を変更したときに記録されます。
2. システム イベント監査ログ
システム イベント監査ログには、リソースの構成を変更する Google Cloud アクションのログエントリが含まれます。システム イベント監査ログは、直接的なユーザーのアクションによってではなく、Google システムによって有効化されます。
システム イベント監査ログは常に書き込まれます。構成したり、除外したり、無効にしたりすることはできません。
BigQueryはデフォルトで監査ログを取得します。
それ以外のGCPのリソースで監査ログを自動的に取得したい場合は、以下の
IAMと管理 > 監査ログで自動的にログ収集したいリソースにチェックをします。
3. データアクセス監査ログ
データアクセス監査ログには、リソースの構成やメタデータを読み取る API 呼び出しや、ユーザー提供のリソースデータの作成、変更、読み取りを行うユーザー主導の API 呼び出しが含まれます。
データサイズが非常に大きくなる可能性があるため、BigQuery データアクセス監査ログを除き、データアクセス監査ログはデフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを書き込むには、明示的に有効にする必要があります。ログを有効にすると、追加のログ使用量についてプロジェクトに対して課金される可能性があります。
4. ポリシー拒否監査ログ
ポリシーなので権限周りなどで拒否になった時、ログを生成する。IAMの権限周りでユーザーがアクセスできなかった時や、VPCでアクセスできなかった（VPC Service Control）時とかにログ生成する
そしてLoggingのデータを用いてアラートを出すような仕組みを実装することも可能です。
何らかのLogでerrorという赤いものの通知が来たら、それを検知してアラートとしてメールを送るなどの仕組みを実装することができます。
なのでいろんなLogが上がってきて、そしてLogの中身を見てエラーならメール通知、Logのある値を検知したらメールなどができる。（ログベースの指標）
Logging設定
→ デフォルトですでにGCPが定義しているメトリクス
→ 自分で作成するメトリクス
すべてのログには以下の情報があります。エラーレベル、、、なので、その情報を元にメトリクスを作成することができ、ある期間で1件エラーレベルがエラーになったのがあればメールやslackへ通知するといった処理の構築が可能になります。
Loggingにも複数あり、
・各リソース独自でとられている監視ログ（BigQueryはデフォルトでログ生成、他のソリューションはデフォルトでは生成しないので、自分で取得する設定をチェックして行います。）
・自分でnode.jsであればconsole.log()、pythonであればprint()のように標準出力するような処理をプログラム内に構築→ Loggingの中に表示されます。
ログデータの吐き出し口
ログルーティングとは、その名の通りログのルーティングです。
ログが出力された時、そのログの内容によって、そのログの保存先を変えて転送するというものです。
こう見ると、シンクはLogData→シンク→ストレージというように流れ込む形かなと思います。
デフォルトでは、①と②は_Require、③と④は_Defaultに吐き出されます。
ユーザーが吐き出すログについて、ログの名前を定義して吐き出し先のバケットを指定できます。
ログルーティング
https://cloud.google.com/logging/docs/export?hl=ja
https://cloud.google.com/logging/docs/routing/overview?hl=ja
以下のようにLogging > ログルーターを見ると、
以下のようにLogging > ログストレージには_Requireと、_Defaultのストレージが作成されています。
ここにログデータが吐き出されます。
