Cloud Logging で管理するログを監視するためには Cloud Monitoring を利用できます。基本的な使い方を記載します。
補足: Cloud Monitoring の監視対象は Cloud Logging に限りません。
組織は Cloud Logging を持ちますが Cloud Monitoring を持ちません。そのため、組織のログを監視するためには、あるプロジェクトの Cloud Monitoring を利用する必要があります。
Cloud Monitoring を利用するプロジェクト myproject-20210411 で Pub/Sub トピックを作成します。
組織の Cloud Logging における Sink を作成します。Destination として先程作成した Pub/Sub トピックを指定します。こちらのページと同様の設定です。
myproject-20210411 プロジェクトの Pub/Sub トピックに Publish できる権限を、Sink のサービスアカウントに付与します。
プロジェクトレベルではなく、トピックレベルで permission を与えることもできます。
Pub/Sub トピックを利用した Alerting Policy を作成します。
ある時刻において、過去一分間の範囲で Pub/Sub トピックへのメッセージ Publish がなされた count を計測して、それが 0 を越えていれば condition が満たされるような Alerting Policy を作成してみます。参考: Alerting behavior
pubsub.googleapis.com/topic/send_message_operation_count
を利用するのがポイントです。
通知先のメールアドレスも適宜登録します。以下のようなメールが通知されます。
アラートメールには Markdown でテンプレートを追加することができます。参考: Using Markdown and variables in documentation templates
組織と異なり、プロジェクトは Cloud Monitoring を持ちます。
Pub/Sub を用いずに直接 Alerting Policy を作成してログ監視することができます。
補足: 組織のログをプロジェクトのログバケットに Sink で入れ込んだとしても、上記 logs-based alert/metrics は利用できません。
Error Reportingは、Cloud Logging のエラーログを分類します。新しい分類先となるログが出力された際にアラートメールを送信することもできます。主な GCP のサービスのログについては初期設定が不要です。
Cloud Trace は、latency データを可視化するサービスです。SmokePing でネットワーク遅延を可視化するのと同様です。
関連資料:
Cloud Monitoring の機能として Uptime checks が存在します。Uptime を check される側のサーバにおいて、Cloud Monitoring からの Uptime check トラフィックであることは、以下の情報を確認することで判別できます。
接続元 IP
$ cat ~/Downloads/uptime-source-ips.txt | jq -C .
[
{
"ipAddress": "35.187.242.246",
"region": "ASIA_PACIFIC",
"location": "Singapore"
},
...
HTTP の場合、User-Agent ヘッダの値
GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)
参考資料: Reviewing uptime checks