Cloud Observability(Logging・Monitoring) - Google Cloud
最終更新日: 2026-08-27
TOP(About this memo)) > 一覧(Google Cloud) > Cloud Observability
Google Cloud Observability
各サービス
- Cloud Monitoring
- Cloud Logging
- Cloud Trace
- Error Reporting
- Cloud Profiler
Cloud Logging
公式
参考
ログの種類
- https://cloud.google.com/logging/docs/overview#categories
- プラットフォームログ
- Google Cloudサービスによって書き込まれるログ。
- コンポーネントログ
- プラットフォームログに似ている。システム上で実行されるGoogle提供のソフトウェアコンポーネントによって生成されるログ。
- 監査ログ
- Cloud Audit Logs
- アクセスの透明性ログ(Googleのスタッフがデータにアクセスした際のログ)
- ユーザー作成のログ
- マルチクラウドログとハイブリッドクラウドログ
- 他のクラウドプロバイダのログや、オンプレミスインフラストラクチャのログ。
監査ログ(Cloud Audit Logs)
- https://cloud.google.com/logging/docs/audit
データアクセス監査ログは、サポートチームがアカウントの問題をトラブルシューティングするのに役立ちます。このため、有効にしておくことをおすすめします。
- (参考) https://hajimenoit.com/google-cloud08/
- 管理アクティビティ監査ログ
- リソースに対する重要な変更に関するログ。
- 常に、ログが生成されたプロジェクトの
_Requiredバケットに保存される。
- データアクセス監査ログ
- データサイズが非常に大きくなる可能性があるため、BigQueryのデータアクセス監査ログを除き、デフォルトでは無効になっている。
- 別の場所に転送しない限り、(
_Requiredではなく)_Defaultログバケットに保存される。
- システムイベント監査ログ
- システム自体が実行したアクションのログ。
- 常に、ログが生成されたプロジェクトの
_Requiredバケットに保存される。
- ポリシー拒否監査ログ
- セキュリティポリシー違反が原因で、Google Cloudサービスがユーザーやサービスアカウントへのアクセスを拒否した場合に記録される。
_Defaultログバケットに保存される。
Cloud Loggingの料金
Cloud Loggingの各プロパティ
構造化ログ
(IME) OpenTelemetryの採用を見送った話
- Cloud TraceはOpenTelemetryを利用することができる。
- ただ、アプリサーバー性能のボトルネックのトレースは、現時点では費用対効果の観点で不要と判断した。
- DB処理のボトルネックのほうが問題になりやすく、アプリサーバー側がボトルネックになるケースは少ないと考えたため。
- もし必要になっても、自分でトレース情報を埋め込むほうが手軽だと考えた。
- ライブラリの構成が複雑で好みに合わない、という点もある。
- 結果として、ログのJSONにトレース情報を埋め込みたいだけだったため、採用を見送った。
- https://opentelemetry.io/docs/languages/go/getting-started/
ログルーター・シンク・ログバケット
- https://cloud.google.com/logging/docs/routing/overview
- ログルーター
- Cloud LoggingはCloud Logging APIでログエントリを受信し、その過程でログエントリはログルーターを通過する。
- シンク
- ログルーターのシンクは、Cloud Loggingがログをルーティングする方法を制御する。
- シンクを使用すると、ログの一部またはすべてをサポートされている宛先に転送できる。
- デフォルトで作成されるシンク
_Required
_Requiredバケットへ転送する。- 無効化や動作の変更はできない。
_Default
_Defaultバケットへ転送する。- 無効化や動作の変更ができる。
- 転送先としてサポートされている宛先
- Cloud Loggingバケット
- BigQueryデータセット
- Cloud Storageバケット
- Pub/Subトピック
- Splunk
- Google Cloudプロジェクト
- ログバケット
- ログバケットはログをリアルタイムに分析するためのバケット。
- Cloud Loggingに保存したログはインデックスに登録されて最適化され、リアルタイムで分析できるように配信される。
- Cloud Loggingバケットは、似た名前を持つCloud Storageバケットとは異なるストレージエンティティ。
- 通常のCloud Storageバケットよりも高額。
- デフォルトで生成されるログバケット
- ユーザー定義のログバケット
(IMO) 良さそうなCloud Loggingの設定方針
- ログバケットの保持期間のデフォルト設定(30日)は変えない。
- Cloud Storageへ転送するようにしておく。
- Cloud StorageはAutoclassを有効にしておく。
- 参考
Cloud Storageへの転送
注意点: 途中から転送をはじめた場合
- 例えば、Cloud Loggingで
_Defaultへの保持期間を1年間にしておき、1年間運用したとする。
- その後、料金を安くするためにCloud Storageへの転送設定をしたとする。
- その際、Cloud Storageへ転送されるからといって、直後に
_Defaultの保持期間を1ヶ月に変更してはいけない。
- これは、転送設定は設定を行った直後のログから有効になるため、それ以前のログは転送されないためである。
- したがって、過去のログまで含めて1年間保存する要件を満たすのならば、転送設定後さらに1年経過してから
_Defaultの保持期間を1ヶ月にする、という対応が必要になる。
- 参考: 過去のログをCloud Storageへ保存する機能もある。
Cloud Storageに転送されたログの確認
ログバケットの保持期間の更新
Cloud Monitoring: ログベースのアラートポリシー
- Cloud Monitoringでは様々な指標に応じてポリシーを作成できる。ここではログをトリガーとした(ログベースの指標の)ポリシーの作成について記載する。
通知チャネルの作成
アラートポリシーの作成
- https://cloud.google.com/logging/docs/alerting/log-based-alerts#lba-edit
documentation
content: ドキュメントの内容。mimeType: 必須。有効な値は"text/markdown"のみ。
combiner
- 指標ベースのアラートポリシーで、複数の条件の結果を組み合わせる方法を指定する項目。
- ログベースのアラートポリシーは単一の条件のみ指定可能で、この値は固定で
"OR"とする必要がある。
alertStrategy
notificationRateLimit
- 通知の最低限の間隔。
- 例えば300sとした場合は、条件を満たすログがどれだけ発生しても、前回の通知から300s以上経過するまでは次の通知が送られない(と理解している(?))。
autoClose
- インシデントを自動的にクローズする期間。デフォルトは1週間(604800s)であり、最大値も1週間となる。
- テスト
フィルターの検証
- コンソール上で直接ポリシーを作成すると、フィルターの入力箇所で「Preview logs」により過去のログから検索をかけてくれる。
- これを確認することで、フィルターが適切に機能しているか確認できる。