DATADOG コース · CHAPTER 12

Monitorで異常を検知しSlackへ通知する — この章で何を学ぶか

この章は「ログ・Error Tracking・メトリクスの監視を使い分ける」「検知条件と通知先を実務の行動に結びつける」「アラート疲れを避ける閾値設計を学ぶ」を、設定だけで終わらせず確認可能な理解へつなぐ。

TL;DR

  1. ログ・Error Tracking・メトリクスの監視を使い分ける。
  2. 検知条件と通知先を実務の行動に結びつける。
  3. アラート疲れを避ける閾値設計を学ぶ。

01ログ・Error Tracking・メトリクスの監視を使い分ける

まず、章の操作が解決しようとしている問いを決める。

ログ・Error Tracking・メトリクスの監視を使い分けるを示す図
中央から外側へ伸びる矢印を追うと、観測したい対象と収集元の対応が分かる。

ログモニターは既知メッセージ、Error Trackingは未知の例外、メトリクスモニターは量的な異常に向く。

学ぶポイント: ログモニターは既知メッセージ、Error Trackingは未知の例外、メトリクスモニターは量的な異常に向く。

02検知条件と通知先を実務の行動に結びつける

次に、構成要素を置く順序と責務の境界を確認する。

検知条件と通知先を実務の行動に結びつけるを示す図
上段から下段へ読み、設定値ではなく各コンポーネントの責務がどこで切り替わるかを見る。

検知条件、評価時間、Slack通知文を結び、受け取った人が最初の調査を始められる状態にする。

学ぶポイント: 検知条件、評価時間、Slack通知文を結び、受け取った人が最初の調査を始められる状態にする。

03アラート疲れを避ける閾値設計を学ぶ

最後に、完成条件を観測データや応答から判定できるようにする。

アラート疲れを避ける閾値設計を学ぶを示す図
左から右へ進む矢印は、確認操作が実際の結果へ到達するまでの切り分け順を表す。

通知が多すぎる時は閾値だけでなく、監視対象が行動可能な異常かを見直す。

学ぶポイント: 通知が多すぎる時は閾値だけでなく、監視対象が行動可能な異常かを見直す。

結論

  1. Monitorで異常を検知しSlackへ通知するの目的を一文で説明できる。
  2. 収集・設定・確認の境界を切り分けられる。
  3. 次の章で使う観測データと運用判断につなげられる。