まーぽんって誰がつけたの?

iOS→Scala→インフラなおじさん技術メモ

Datadogの効果的なモニタリングとAlertについてシリーズを読んだ

狼少年

少年が繰り返し同じ嘘をついたので、本当に狼が現れた時には大人たちは信用せず、誰も助けに来なかった。そして村の羊は全て狼に食べられてしまい、死亡した。 Wikipedia

サーバーの監視でalertやwarningが増えすぎると、 だんだん暗黙の了解みたいのが入ってきてこんな状態になってしまうことはないでしょうか? 🤔

  • 最近の人 「なんかwarnがいっぱい出てるけど大丈夫でしょうか?」
  • 昔からいる人 「あーこれは大丈夫なやつ」

ぼくはどっちかというとそういう暗黙の了解側にいてしまうので、モニタリングというのは何をするべきなのかというのを勉強とまではいかないけど、Datadogが出しているMonitoring 101というシリーズ記事があるのでそれを読んでみみた。

  1. Collecting the right data
  2. Alerting on what matters
  3. Investigating performance issues

f:id:masato47744:20171118023127p:plain

alertすべきはWork metrics

metricsの種類

metricsには、Work metricsResource metricsEventに分かれる。

Work metrics

Work metricsはシステムが正常に動いてるかどうかを判断できるメトリクスのこと。Work Metricsはさらに4つに分かれていて、throughput, success, error, performanceとなる。 例えばウェブサーバーのWork metricsはこういう値

f:id:masato47744:20171114165101p:plain

DBだったらこう

f:id:masato47744:20171114165127p:plain

Resource metrics

Resource metricsはDisk IOやCPU使用率などのメトリクスの事を指す。同様にutilizationsaturationerrorsavailabilityの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に該当するものはなんだろう

この記事で紹介されている例

f:id:masato47744:20171114165143p:plain

実際の現場でいうと、このあたりになるのかなと考えてみた。本当に失敗してはいけないバッチとかって今ってjenkinsの結果見るだけしかやってなくて、それだと埋もれてしまうのでそういうのも本来は別途通知しないといけないなと思った。

  • 外形監視でのヘルスチェックに失敗した
  • LBのヘルスチェック成功しているインスタンスの数が0になった
  • LBのレスポンスタイムが平均xxxms以上になっていないか
  • サーバーのHTTPのステータスコードの5xx系の全体に占める割合がxx%を超えていないか
  • バッチが失敗した