なんとなく監視から組織による監視への移行
AIな世の中でこんな記事あまり流行らないかもですが、個人と組織の備忘も兼ねてコミットします。
元々属人化していた監視体制に対して、何を視るか、どう視るか、どう対処するかを整理しました。
その作業ログです。
Google Monitoringのダッシュボード設定とログアラートの通知設定手順をまとめます。
Google Monitoringダッシュボード作成と各プロダクト環境への配布
準備(プロファイルの設定)
gcloud config configurations create <PROJECT名(エイリアスでOK)>
gcloud config set project <PROJECT_ID>
gcloud config set account <ACCOUNT>
gcloud config configurations list
(option)プロファイルを切り替える時
gcloud config configurations activate <PROJECT名(エイリアスでOK)>
ダッシュボード作成
GUIでちょこちょこ作る。一旦ベーシックにこんなダッシュボードを作りました。
- Cloud Run
- Container CPU Utilization
- Container Memory Utilization
- Instance Count
- Request Latency
- Billable Instance Time
- Cloud SQL
- CPU utilization
- Memory utilization
- Disk utilization
- Deadlocks count
- Disk write IO
- Disk read IO
配布
こちらの記事を参考にいたしました。
gcloud monitoring dashboards list --format="table[box](displayName,name)"
# nameをDASHBOARD_RESOURCE_NAMEに指定する
gcloud monitoring dashboards describe <DASHBOARD_RESOURCE_NAME> --format="json" | jq "del(.etag,.name)" > ./dashboard.json
gcloud monitoring dashboards create --config-from-file ./dashboard.json
UPDATE
公式の手順どおり素直にupdateしようとするとetagの管理がめんどいので、updateはdelete -> createが良さそうです(jsonファイルが構成管理されるだろうし)。
# おそらくGUIで編集してgcloud monitoring dashboards describeして...
gcloud monitoring dashboards delete <DASHBOARD_RESOURCE_NAME>
gcloud monitoring dashboards create --config-from-file ./dashboard.json
ログアラート通知手順
通知チャネルの設定（Cloud Loggingからやるとリダイレクトがうまくいかない）
こちらから通知先を追加していきましょう。
あるいはこちら -> Edit Notification Channelsのリンクをたどる。
通知ルールの設定
- Cloud Logging -> 「操作」 ->「ログアラートの作成」を選択する
- 画面の案内に従ってどんどん進める
その他
効果について
弊社ではDatadogを導入していたのですが、まだ現場に浸透しきっていなかったため一旦取りやめました。
身近なGoogle Cloudを操作するようなことをして、step by stepで地道な布教活動から始めることにしました。
自分たちが直接触る環境でイメージしやすかったのか、結果的に理解が進んでいて、メンバーの中でスケールダウンなどチューニングが進んでいます。
Exception Architecture
どちらが先か議論の余地はありますが、アラート監視チャネルが整理されたため、今度は使いやすさにシフトしてくるのではないかと考えています。
そうなると例外設計など運用面での強化がなされるのではと期待しています(記事執筆時点でもうすでに発生しつつあります)。
活用してみたい機能
Error Reportをうまく利用するとヘルシーに運用できるでしょうか。今までAWS畑でGoogle Cloudは初なので色々試してみたいです。
Discussion