モニターとアラート

モニターの種類 - しきい値比較だけではない

Datadog のモニターは、問題を事前に検知してリアルタイムに対応するための仕組みで、2026 年 8 月時点の公式ドキュメントには 29 種類のモニタータイプが列挙されています (出典: Monitor Types)。中心になるのはメトリクスの値をしきい値と比較する Metric モニターですが、ほかにもログの件数を見張る Logs、トレースの指標を見張る APM、ホストからの報告が途絶えたことを検知する Host、プロセスの生存を見る Live Process、複数のモニターを式で組み合わせる Composite、SLO のエラーバジェットを見張る SLO Alerts などがあります。「どのデータ源にも、それを見張るモニターの型がある」という構造を頭に入れておくと、監視したい事柄から逆引きで型を選べます。個々の概念の整理は用語辞典のモニターの項も参照してください。

しきい値設計 - warning・alert・recovery の 3 点で考える

しきい値には必須のアラートしきい値と、任意の警告 (warning) しきい値があり、警告は本アラートより手前の通知として別扱いになります。さらに任意で回復しきい値を設定でき、未設定ならしきい値を下回った (上回った) 時点で自動的に回復扱いになります (2026 年 8 月時点・出典: Configure Monitors)。設計のこつは、この 3 点をひとつの物語として決めることです。警告は「営業時間内に人が計画的に対処する水準」、アラートは「今すぐ誰かを呼ぶ水準」、回復しきい値は「しきい値付近を行き来して通知が振動しないための余白」です。回復をアラートと同じ値にしておくと、境界線上の値の揺れがそのまま通知の点滅になります。アラートと回復の間に意図的な差を置くことが、後述するアラート疲れ対策の最初の一手になります。

通知の書き方 - 受け取った人が次に動けるか

通知はメールや Slack へ送ることができ、グラフのスナップショットを添付したり、テンプレート変数で発生対象や値を本文へ差し込んだりできます。通知を適切な担当者へ振り分けるルーティングも公式ドキュメントで案内されています (2026 年 8 月時点・出典: Datadog Monitors ドキュメント)。本文の品質は仕組みではなく書き方で決まります。役に立つ通知は「何が・どこで・どれくらい」に加えて「まず何を確認するか」まで書いてあるものです。深夜に受け取る人を想定し、調査の入口 (見るべきダッシュボードや直近の変更の確認先) を通知文へ埋め込んでおくと、対応の初動が数分単位で縮みます。逆に、条件式をそのまま貼っただけの通知は、受け取るたびに解読コストを払わせます。

アラート疲れを防ぐ道具立て

公式ドキュメント自体が「アラート疲れを減らし、重要なときに対応へ集中できるようにする」ことを掲げており、そのための道具が揃っています (2026 年 8 月時点)。第 1 に集約の単位で、グループ化したクエリでは対象ごとに個別通知する Multi Alert と、全体を 1 件に束ねる Simple Alert を選べ、通知のグルーピング次元を絞ることでノイズを減らせます。第 2 にダウンタイムで、メンテナンス中のアラートを計画的にミュートできます。第 3 に評価遅延で、遅れて届くデータを誤検知しないよう評価を最大 86,400 秒まで遅らせられます (クラウド事業者由来のメトリクスには 15 分の遅延が推奨されています)。第 4 にデータ欠落 (No data) 時の扱いを、ゼロとして評価・直前の状態を維持・欠落として通知するなどから明示的に選べます。道具の使い分け以前の原則として、「鳴っても誰も動かないアラートは消すか警告に下げる」を定期的に実行することが、アラート疲れ対策の本体です。

異常検知系モニターの使いどころ

静的なしきい値が決めにくいメトリクスには、履歴や集団との比較で判定する型が用意されています。

便利な半面、異常検知系は「なぜ発報したか」の説明が静的しきい値より難しく、学習元の履歴が汚れていると判定も汚れます。まず主要な値は素直なしきい値で張り、周期性のせいで誤報が続く箇所だけを異常検知系へ置き換える順番が、運用の説明可能性を保ちやすい進め方です。

「何を監視すべきか」への答え方

監視項目の一覧表から埋めていく進め方は、項目数の割に肝心の障害を拾えないことがあります。先に決めるべきは「利用者に見える症状」の監視です。応答が遅い・エラーが返る・処理が終わらないといった症状側をまずAPM やログの件数で見張り、CPU やメモリなどの資源側は、症状の原因調査に使う二次的な監視と位置づけます。資源側のアラートだけを大量に張ると、利用者影響のない夜中の CPU スパイクで人を起こし、本当の障害では鳴らない、という逆転が起きがちです。そのうえで、ホストからの報告途絶 (Host モニター) やプロセスの生存 (Live Process) のような「監視自体が生きているか」を少数加えると、監視の土台が締まります。インフラ監視とログ管理のどちらを見張るかで迷ったら、「その通知を受けた人が最初に開く画面はどちらか」で決めるのが実用的です。

運用に乗せる - 命名規約と棚卸し

モニターは作った瞬間より、半年後の姿で価値が決まります。数が増えても管理が破綻しないよう、最初に名前の規約を決めてください。対象システム・環境・症状が名前だけで読める形 (どのサービスの何が悪いのか) にしておくと、通知の一覧がそのまま状況報告になります。また、四半期に一度の棚卸しで「この期間に一度も鳴らなかったモニター」と「鳴ったが誰も行動しなかったモニター」を洗い出し、前者はしきい値の見直し、後者は削除か警告への降格を検討します。ダウンタイムを使わずに手動ミュートで黙らせたままのモニターは棚卸しの主要な捜索対象です。監視は張ることより、鳴る意味を保ち続けることの方が難しい、という前提で運用を設計してください。