当記事の目的
- Google Cloud Platform（以下 GCP）にてアラートポリシーを作成することで、実際に ERROR や WARNING の通知を送るよう設定を行います。
- インシデントへの迅速な対応のため。
- メール及び Slack に通知が飛んでくることを確認します。
アラートポリシーとは
GCP の Cloud Monitoring という監視サービスで、アラートの①通知先、②通知条件を指定すると、指定した条件を満たしたとき、指定した通知先に通知を送ってくれるという仕組み。（ドキュメント）
流れ
- 通知先を設定しておく。
-
Select a Metricで監視対象を決める。 -
トリガーの設定でアラート通知を出す条件を決める。 -
通知と名前でアラート内容を記述する。 - 作成したアラートポリシーの通り、アラート通知が飛んでくることを確認する。
1. 通知先の設定
アラートポリシーを作成する前に、以下の準備が必要である。
Slack チャンネル作成
通知を受け取る用の Slack チャンネルを作成しておく。（ # つきのチャンネル名は通知チャネル設定で使うので、控えておく）
以下のように、検証環境と本番環境、アラートの深刻度（ERROR か WARNING か等）に応じてチャンネルを分けるとよい。
- 検証環境 - WARNING
- 検証環境 - ERROR
- 本番環境 - WARNING
- 本番環境 - ERROR
通知チャネル設定
GCP の Monitoring の通知チャネル （ Manage Channels ）画面にて、アラート通知先の設定を行う。基本的に、画面に出る指示に従えばよい。（ドキュメント）
Slack
Slack のワークスペースを選択して連携する。
↓
# つきのチャンネル名及びそのチャンネルの GCP 上での表示名を入力。
↓
テスト通知を送信する でテスト接続し、Slack で This is a test alert notification from Stackdriver という通知が確認できたら成功。
メール
メールアドレスと GCP 上での表示名を入力。
2. Select a metric
ここからはアラートポリシー作成画面での作業。
Monitoring → アラート → CREATE POLICY へ移動。
その中の Select a metric 画面で以下の操作をする。
Metrics（指標）を選択
監視対象、及びその中でも何を監視したいかによって、Metrics を決める。選択画面に出てくる説明を読みつつ選択。
主な監視対象の GCP Metrics 一覧での表示名は以下のようになっている。
| 監視対象 | Metrics での表示名 |
|---|---|
| BigQuery | BigQuery Project |
| GAE | GAE Application |
| GCE | VM Instance |
| GKE | Kubernetes |
| SQL | Cloud SQL Database |
| ロードバランサ | Google Cloud HTTP/S Load Balancing Rule |
よく使うであろう Metrics は以下の通り。（Metrics 詳細）
-
log_entry_count（ログの数） -
http/server/response_count（HTTP レスポンスの数） -
cpu/utilization（CPU 使用率）
※ちなみに GCE に関しては、使用する VM インスタンスに Ops Agent をインストールすると、もっと色々な Metrics を使って監視できるようになる。（Ops Agent インストール方法）
フィルタリング
フィルタの追加 にて、監視対象を絞り込む。（例：ログレベルが ERROR であるログの数を見たい場合、 log severity = ERROR であるログのみ取得）
以下でフィルタリングすることが多いと思われる。
- project_id（プロジェクト指定）
- severity（ERROR や WARNING などのログレベル）
- instance_id（GCE の場合）
- database_id（Cloud SQL の場合）
- cluster_name（GKE の場合）
ちなみにフィルタリングは、できる限り細かくしておいた方が良い。あまりフィルタリングをしないとアラート通知がとてもうるさくなり、本当に大切なアラートを見逃す可能性があるためである。
データ計測間隔決定
Transform Data の ローリングウィンドウ にて、監視する時間の間隔を決める。（例：5分に設定→過去5分間のデータを取得して異常を検知する）
基本1分単位で計測するのが良い。
計測する数値の種類決定
同じく Transform Data の ローリングウィンドウ関数 にて、どんな数値をみたいのかを決める。（例：CPU の最大使用率によってアラートを出したい場合、最大値を見る）
以下を用いることが多いと思われる。
- 合計値（sum）
- 最大値（max）
- 平均値（mean）
- 変化率（percent change）
また、その下の Across time series の「時系列集計」でも、上記で選んだものと同様のものを選択しておく。
3. トリガーの設定
「トリガーの設定」画面へ進む。
条件指定
「境界値を上回った（or 下回った）場合アラートを出す」「データがない場合にアラートを出す」といったアラート条件を決める。
Condition Type
以下のどちらかを選択。
- 境界値を上回った（or 下回った）ときにアラートを出す場合は
Threshold - データがないときにアラートを出す場合は
Metric absence
恐らく Threshold を使うことが多いため、以下ではこちらを想定して説明する。
Alert Trigger
基本的に 任意の時系列の違反 を選択するのがよいと思われる。これは「1回でも設定した条件に当てはまった場合にアラートを出す」という意味。
しきい値の位置
以下のどちらかを選択。
- しきい値を上回った場合にアラートをだすならば「しきい値より上」
- しきい値を下回った場合にアラートをだすならば「しきい値より下」
しきい値
境界値を決める。
例：「ログレベルが ERROR であるログが1個でもある場合アラートを出す」
→「しきい値の位置」では「しきい値より上」、「しきい値」では「0」を入力。
再テストウィンドウ
本当はアラート条件に当てはまらないのに「アラートを出す条件に当てはまったぞ！」と判断されてしまうのを防ぐためのもの。
こちらはデフォルトのまま「0秒」、または「1分」など短い期間で設定しておけばよいと思われる。
条件名
飛んでくる通知にも書かれるものなので、一目見て分かりやすい条件名を指定する。
ちなみにデフォルトでは Metrics 名が入っている。
4. 通知と名前
通知チャネル指定
通知を送りたい先を指定する。
1で設定しておいた Slack のチャンネルやメールアドレスから選択する。
インシデントのクローズに関する設定
Notify on incident closure にチェックを入れると、インシデント解消時にも通知が来るようになる。
インシデントの自動クローズ期間はデフォルトのまま「7日」でよいと思われる。
アラート名と説明を記述
アラート名とその説明を書く。これらも通知が飛んできた際に表示されるものなので、一目見て分かりやすいように書いておく。
ポリシーを作成 を押したら作成完了。
5. 通知確認
実際に通知が届くことを確認する。
Slack
インシデント発生時
インシデント発生時には、 Incident Ongoing などと書かれ赤色の線が付いた通知が届く。
（ Incident 〇〇 is Ongoing のインシデント ID をクリック→ VIEW LOGS で該当のログを参照できる。）
インシデント解消時
インシデント解消時にも通知するよう設定しておいた場合は、 Incident Stopped などと書かれ緑色の線が付いた通知が届く。
メール
Alert firing と書かれたメールが届く。
まとめ
画面をポチポチすれば基本的なアラート設定ができてしまう、というのはありがたいです。
アラートポリシーは作成・編集・削除・オンオフが気軽にできるので、とりあえず作って試してみるのがよいと思います。
参考
公式ドキュメントが豊富なので比較的分かりやすいと思います。