Datadogの効果的なモニタリングとAlertについてシリーズを読んだ
狼少年
少年が繰り返し同じ嘘をついたので、本当に狼が現れた時には大人たちは信用せず、誰も助けに来なかった。そして村の羊は全て狼に食べられてしまい、死亡した。 Wikipedia
サーバーの監視でalertやwarningが増えすぎると、 だんだん暗黙の了解みたいのが入ってきてこんな状態になってしまうことはないでしょうか? 🤔
- 最近の人 「なんかwarnがいっぱい出てるけど大丈夫でしょうか?」
- 昔からいる人 「あーこれは大丈夫なやつ」
ぼくはどっちかというとそういう暗黙の了解側にいてしまうので、モニタリングというのは何をするべきなのかというのを勉強とまではいかないけど、Datadogが出しているMonitoring 101というシリーズ記事があるのでそれを読んでみみた。
alertすべきはWork metrics
metricsの種類
metricsには、Work metrics、Resource metrics、Eventに分かれる。
Work metrics
Work metricsはシステムが正常に動いてるかどうかを判断できるメトリクスのこと。Work Metricsはさらに4つに分かれていて、throughput, success, error, performanceとなる。 例えばウェブサーバーのWork metricsはこういう値
DBだったらこう
Resource metrics
Resource metricsはDisk IOやCPU使用率などのメトリクスの事を指す。同様にutilization
、saturation
、errors
、availability
の4つに分かれる。
ついついぼくが設定してしまっていたのは、CPU使用率が90%overです。みたいなalert。これは実はalertとしては筋が悪い。別にCPU使用率が高くてもレスポンスタイムなどが遅くなっていなければ問題ないのだ。
Event
eventはPRがmergeされたとか、deployされたとかバッチが失敗したとかそういう出来事のことを指す。
効果的なモニタリングとAlert
Alertは緊急度によって3種類に分けられる。
- 夜だろうがなんだろうがすぐに対応しないといけない
Page
- すぐではないけどいずれやらないといけない
Notification
- とりあえず記録しておいて通知はしなくてよいOKな
Record
という分類。
そして、Page
に分類されるものとして通知をするときに、本当にすぐに対応しなければならないのか、緊急度がとても高いものかどうかということを考える。
ちなみにPager
が英語でポケベルみたいなもののことを指すので、多分Page
っていうんだと思う。
なので効果的なAlert、モニタリングとしては以下のようなやり方になる。
- 緊急度が高いWork Metricsが想定外の値であれば
Page
(電話やSlack通知) - 残りディスク容量が少ないなどのResource Metricsは
Notification
(Warning的なSlack通知) - Pageの場合はいったい何が起きているのかをResource MetricsやEventを使って調査していく
Page
に該当するものはなんだろう
この記事で紹介されている例
実際の現場でいうと、このあたりになるのかなと考えてみた。本当に失敗してはいけないバッチとかって今ってjenkinsの結果見るだけしかやってなくて、それだと埋もれてしまうのでそういうのも本来は別途通知しないといけないなと思った。
- 外形監視でのヘルスチェックに失敗した
- LBのヘルスチェック成功しているインスタンスの数が0になった
- LBのレスポンスタイムが平均xxx
ms
以上になっていないか - サーバーのHTTPのステータスコードの5xx系の全体に占める割合がxx%を超えていないか
- バッチが失敗した