はじめに
担当しているWebサービスでアラート疲れがおきていたので、モニタリング周りを見直してみた。
効果があったことをまとめておく。
ちなみにモニタリングツールは Datadog。
抱えていた問題
アラート対応に疲れ果て、通常の業務に支障をきたいていた。
下の要因が重なっていたのが原因。
- アラートが多い（一日数件）
- ほぼ無視していいアラート
- アラートの調査や対応が職人芸
監視対象
- 利用者に決済APIを提供している SaaS
- AWS の EKS で稼働
- 内部はマイクロサービスアーキテクチャ
- マイクロサービス間のやりとりは同期的な HTTP 通信もあれば、 SNS/SQS を使ったイベント通信もある
改善方針
- Webサービス の利用者から見て 動いていること を監視する
- 緊急対応が必要だと思われるときだけアラートする
- 誰でもアラートに対応できるようにする
改善内容
Datadog モニターの整理
利用者から見てサービスが動いていることを監視するため、ワーキングメトリクス を監視することにした。
:::message ワーキングメトリクス サービスを提供するためにフロントに出るメトリクス （スループット / 成功 / 失敗 / パフォーマンス） :::
また 重要な リソースメトリクス に絞って監視することにした。
:::message リソースメトリクス システム・サービスのバックエンドのメトリクス （使用率 / 飽和度 / エラー / 可用性） :::
この方針に従って、モニターを作り直した。
ノイズの原因になっていたモニターはすべて削除した。
Datadog モニターの優先度を設定
Datadog のモニターには優先度をつける事ができる。
優先度ごとに目標解決時間を決めて、アラートの温度感がわかるようにした。
| 優先度 | 目標解決時間 | 対応目安 |
|---|---|---|
| P1 | 1時間以内 | 何を差し置いても対応する |
| P2 | 4時間以内 | P1ほどではないがすぐに対応が必要 |
| P3 | 24時間以内 | その日のうちに対応できればいい 休日で外出中の場合は、家に帰って対応でもOK |
| P4 | 72時間以内 | 勤務時間中に確認する 土日の間は置いておいて、月曜日に対応でOK |
| P5 | なし | 障害ではないが知っておくべき情報 確認のみでOK |
とにかくアラート減らす
いつも出るアラートで、アラートが起きないように根本対応は可能だが、なんとなく放置されていたものが多かった。時間が許す限り根本対応して、アラートを減らした。
ノイズの原因になっていたモニターはばっさり消して、アラートの数を減らした。
対応しやすいアラートにする
- アラートのタイトルや本文を見直して、何が起きているのか症状がひと目で分かるようなタイトルや説明文にした
- アラート対象のマイクロサービスのログやAPMへのリンクを付けて、すぐにログやAPMを確認できるようにした
- 関連するダッシュボードのリンクをつけた
Runbook の作成
誰でもアラート対応できるように、アラートごとにRunbookを作り、アラート本文に Runbook へのリンクをつけることにした。
まだ完全に対応できていないが、重要なところは徐々に追加している。
Datadog ダッシュボードの整理
今現在、Webサービスの利用者から見て 動いていること がひと目で分かるようなダッシュボードを作成した。
機能ごとのワーキングメトリクスを一覧できるダッシュボード
- 成功率・失敗率
- 成功数・失敗数
- APIのレイテンシー
重要なリソースメトリクスを一覧できるダッシュボード
- ELBごとの200/4xx/5xxの遷移
- DBのCPU使用率、利用可能なメモリー、レイテンシー、レプリラグなど
- EKSの利用ノード数、利用可能なIP数
- Lambdaの成功数・失敗数
- AWS利用料の遷移
これによって、アラートが起きたときに、どのくらい悪い状態なのか、すぐに分かるようになった。
状態がわからずに調査しつづけるのは精神衛生に悪いので、このダッシュボードがあることで精神的にも楽になった。
オンコール担当のローテーション
チームメンバー全員で対応していると無駄だし、結局詳しい人が対応するので知見が広まらないし、疲弊する。
アラート対応するオンコール担当者を2〜3人に絞って決めて、１週間毎にローテーションすることにした。
担当が変わる日の朝会で、引き継ぎ会を実施している。
モニタリングレポートの生成
毎週自動的にその週に起きたアラートや、エラーログ数をカウントしてレポートするようにした。
このレポートを引き継ぎ会で利用していた。
結果
数字的にみると大きな成果があった。
- アラートのノイズが1/4に減った
- アラート対応の工数が、半分以下になった
体感的にも、アラート対応がかなりマシになって、まぁ許せるレベルになった気がする。
まとめ
モニタリングの改善は単発で終わるものでなく継続的な取り組み。
継続的に改善して、ユーザに価値を届ける本来の仕事に集中したい。