GCP のログ大全2019
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 5 日目の記事です。
GCPにおけるログのライフサイクル
GCPにおけるログのライフサイクルは、収集・集約・活用・保管の大きく4つのフェーズに分類できると考えております。まずそれぞれのフェーズの中でどのようなことができるのか、皆様に知っておいておきたいことについて説明します。
収集フェーズ
ログを発生させる元のシステムから集めてくるフェーズです。ログの発生元がどこであれ、最終的には Stackdriver の Logging API にログを送ることで収集を行います。もちろんGCPのサービスで発生するログは自動的に収集されますが、GCP上のユーザアプリケーションのログや、オンプレミスや他クラウド環境からのログは、Logging エージェントかLoggin APIのクライアントライブラリ経由で送ることが一般的です。GCPのサービスで発生するログについての詳細は後述します。
集約フェーズ
Stackdriver Loggingに集約されたログは、LogEntryという型のオブジェクトで保存されており、様々なログに共通するログのメタデータの一貫性を担保することができます。
保存されたログを確認するには、GCPコンソールからログビューアを使う方法、gcloudコマンドを使う方法、APIを直接コールする方法があります。いずれの方法もログの発生源であるリソース、重大度、期間、ログの内容でフィルタをかけて必要なログを絞り込んでいくことができます。
活用フェーズ
Stackdriver Logging上で絞り込んで確認していく以外にも、Stackdriver Loggingから他のサービスに連携してさらに高度な活用を行っていくことが可能です。
Stackdriver Monitoringへ連携し、指標化して活用
ログベースの指標という機能を使うことで、フィルタに合致したログからカウンタ指標や分布指標を作ることができます。ここで作られた指標はStackdriver Monitoringの通常の指標と同じように扱うことができるので、グラフ化したり、Stackdriver Monitoringで提供されている通知機能を活用することができます。
Cloud Pub/Sub経由で他システムとの連携
Stackdriver Loggingのエクスポート機能を使うことで、フィルタに合致したログをPub/Subにエクスポートすることができます。Cloud Pub/Sub経由で特定のログに応じた処理を他のアプリケーションで実行することができます。
BigQueryへエクスポートして活用
Stackdriver Loggingのエクスポート機能を使うとCloud Pub/Subと同様にBigQueryへログをエクスポートすることができます。ログがBigQueryへ入ったあとはBigQueryのパワーを使い様々な活用が可能です。
保管フェーズ
GCSへエクスポートし保管
Stackdriver Loggingのエクスポート機能はGCSへのエクスポートもサポートしております。アーカイブ目的でログを長期保存する必要がある場合はGCSのコールドラインストレージを活用することでコストを最小化することができます。また、GCSのバケットロック機能を活用することで、GCSをWORMストレージとして利用し、法的要件などにより一定期間ログの内容が変更されていないことを担保する必要がある場合にも容易に対応が可能です。
BigQueryへエクスポートし保管
活用フェーズでBigQueryへのエクスポートを紹介しましたが、もちろん保管観点でもBigQueryへのエクスポートは有効です。Stackdriver Loggingでのログの保持期間は多くが30日となっているため、30日以上過去のログを確認することがあり得る場合はBigQueryへエクスポートをしておくことをおすすめします。
GCP上で発生するログについて知っておいてほしいこと
GCPのサービスの各動作ログは自動的にStackdriver Loggingへ収集されますが、いくつかのログは明示的に有効にする必要があります。また、皆様のアプリケーションのログもアプリケーションを動かすサービスごとにStackdriver Loggingへ送る方法についての約束事があります。ここではGCP上で発生するログについて皆様に知っておいていただきたいことをまとめたいと思います。
監査ログ
GCP横断の仕組みとして監査ログがあります。監査ログには大きく3種類あり、管理アクティビティログ、データアクセスログ、システムイベント監査ログがあります。
管理アクティビティログはGCPリソースの構成の変更などの管理操作が行われた際に記録されます。最初から有効になっており、無効にすることはできません。Stackdriver Logging上に400日保持されますが、Stackdriver Loggingの課金対象からは除外されます。
データアクセスログは、データを保持するGCPサービスについてデータの読み込みや書き込みがされた際に記録されます。BigQueryを除くサービスはデフォルトでは無効です。有効にするとStackdriver Logging上に30日保持され、Stackdriver Loggingの課金対象になります。有効にするとデータ量が非常に多くなる場合が多いので、必要に応じて個別に有効にしていくことをおすすすめします。
システムイベント監査ログはホストメンテナンスやライブマイグレーションといったGCEに対してGoogle側で自動的に行った操作について記録されます。最初から有効になっており、無効にすることはできません。Stackdriver Logging上に400日保持されますますが、Stackdriver Loggingの課金対象からは除外されます。
それぞれのサービスでどの種類の監査ログが記録されるかはこちらのページをご覧ください。
アクセス透明性ログ
監査ログが基本的にユーザの皆様の操作に関するログであるのに対し、アクセス透明性ログはGoogleのスタッフがトラブルシューティングの過程などで皆様のリソースにアクセスした際に記録されるログです。このログを有効にするには加入しているサポートに条件があります。条件を満たしている場合、組織全体に対して有効にすることができます。
各サービス固有のログ
各サービスの動作ログは自動的にStackdriver Loggingに集められます。どのような種類のログがあるかというのはモニタリング対象リソースのページにまとまっています。
ここからはサービス固有のログで明示的に有効にしないといけないログやログについて知っておくと役立つことをまとめます。
HTTP(S)ロードバランサーのログ
HTTP(S)ロードバランサーのログは、ロードバランサ自体のみでなく、ロードバランサに追加する機能である、Cloud Armor や Cloud CDN のログも含まれます。一般的なL7レイヤーの情報に加え、リクエストに対するレスポンスが成功した場合はキャッシュから返したのか、バックエンドから返したのかが記録され、失敗した場合は失敗した理由が記録されます。
デフォルトは有効になっておりますが、無効にすることもできますしサンプリングレートを設定して流量を減らすことができます。
内部HTTP(S)ロードバランサーのログ
一般的なL7レイヤーの情報に加え、バックエンドサービスの名前が記録されます。デフォルトは無効になっております。
ファイアウォールルールログ
VPCのファイアウォールのログは設定されたファイアウォールルールに合致して通信を許可したり拒否したことが記録されます。ファイアウォールルール単位で設定することができます。デフォルトは無効です。
VPCフローログ
VPCフローログはインスタンスによって送受信されるネットワークフローを記録します。5タプルで表現された通信内容とその通信量などが記録されます。デフォルトは無効でサブネット単位で有効にできます。
Cloud NATのログ
Cloud NATのログはCloud NAT経由で外部に出た通信について5タプルに加えてNATのIPとNATする際につかったポート番号を加えた情報とNATが成功したか失敗したかなどの情報が記録されます。デフォルトは無効です。
Cloud DNSのログ
Cloud DNSのログはVPC内部で行われた名前解決のログを記録します。デフォルトは無効です。
Cloud SQL for MySQLのログ
MySQL上のslow_query_logやクエリログであるgeneral_logのフラグを有効にすることができます。
Cloud SQL for PostgreSQLのログ
PostgreSQLのどのようなクエリについてログをするかをコントールするlog_min_duration_statementやlog_statementのフラグを有効にすることができます。
GCEの仮想シリアルポートの出力
GCEインスタンスには仮想シリアルポートがついており、その出力をStackdriver Loggingへ送ることもできます。インスタンスレベルかプロジェクトレベルのメタデータで設定します。デフォルトは無効です
GCSのアクセスログとストレージログ
GCSには監査ログとは別にアクセスログとストレージログを取得することができます。アクセスログには特定のバケットに対してアクセスがあったリクエストの情報が記録されます。ストレージログには前日のストレージ使用量が記録されます。どちらもデフォルト無効です。このログはStackdriver Loggingへは送られずに設定時に指定したGCSバケットに保存されます。
Cloud Data Fusionのログ
Cloud Data Fusion上で実行するパイプラインのログを取得するには、Data Fusionのインスタンスを作成する際に有効にする必要があります。
Cloud Dataflowのログ
Cloud Dataflow上で実行するパイプラインからログを収集したい場合は各言語で対応したライブラリにログを書くような処理を追加することで、収集することができます。
Cloud IoT Coreのログ
Cloud IoT Coreで管理しているデバイスのイベントを記録することができます。デフォルトは無効です。まずレジストリ単位の設定ができ、デバイス単位ではその設定をそのまま使用することも、デバイスごとに上書きすることもできます。
Identity Platformのログ
Identity Platformで管理しているユーザの作成、変更、削除のログや認証をどの手法で行ったかについてのログを記録することができます。デフォルトは無効です。
AI Platformのオンライン予測のログ
AI Platformでオンライン予測をさせる際、アクセスログ、ストリームログ、リクエスト/レスポンスログを活用することができます。アクセスログとストレージログはモデル作成時に、リクエスト/レスポンスログはモデルのバージョンを作成する際に有効にできます。
アプリケーションログ
最後に皆様のアプリケーションをGCP上で動かす際に、簡単に、スムーズにStackdriver Loggingへログを送る方法をまとめます。どのサービスでもアプリケーション内でStackdriver Logging クライアントライブラリを使ってログを送ることも可能です。
GAE 2nd Gen (リンクは例としてGo1.12) / Cloud Functionsのログ
第2世代のGAEおよび、Cloud Functions上のアプリケーションからは標準出力と標準エラー出力へログを出すことでStackdriver Loggingへログを送ることができます。
Cloud Runのログ
Cloud Runにはリクエストログとコンテナログの2種類のログがあります。リクエストログはCloud Runのエンドポイントに対してどのようなリクエストが来ているという内容が含まれ、自動的に記録されます。コンテナログは皆様のアプリケーションから書き出すログで、標準出力、標準エラー出力、 /var/log、 /dev/logに書かれたものが自動的にStackdriver Loggingに収集されます。
GCEのログ
Stackdriver Logging AgentをインストールすることでGCEインスタンス上のログをStackdriver Loggingに送ることができます。デフォルトでsyslogとWindowsイベントログを含むいくつかのアプリケーションのログを自動的に送る様に設定されているので、そのままでよいケースもあると思います。デフォルトの構成に含まれていないアプリケーションのログを送りたい場合には、fluentd ベースの構成ファイルを変更することで対応が可能です。
GKEのログ
GKE上のアプリケーションのログをStackdriver Loggingに送るには、Kubernetes Engine Monitoringをクラスタレベルで有効にする必要があります。これにより、各Nodeにカスタマイズされたfluentdがdaemonsetとして展開され、コンテナ内部から標準出力と標準エラー出力に出されたログが自動的にStackdriver Loggingへ送られます。
