モニター

概要

Datadog のモニターは、対象を絞り込む検索クエリ、複数の値をひとつに畳む集約方法、値を見る時間の幅、そして違反と判断するしきい値をまとめた評価の定義です。そこに通知先と通知本文の設定が結び付き、条件が満たされた時点でアラートとして送り出されます。評価の定義と通知の設定が別の層に分かれている点がモニターの設計上の要点で、条件をそのままにして宛先だけを差し替えたり、宛先を保ったまま条件だけを厳しくしたりできます。監視の入り口である収集や可視化と違い、モニターは「人の手を動かす」ための仕組みなので、鳴らし方の設計がそのまま運用の負荷を決めます。

モニターは通知の箱ではなく評価式

モニターという名前からは通知設定のまとまりを想像しがちですが、中心にあるのは評価式です。どのデータを見るかを決める検索クエリ、複数の値をひとつに畳む集約方法 — メトリクス系のしきい値条件なら平均・最大・最小・合計のいずれか、どれだけの時間幅で判断するかという評価ウィンドウ、そして違反とみなすしきい値。この 4 つが決まってはじめて、モニターは状態を持てるようになります。通知先や通知本文は、その状態が変わったときに走る出力の設定にすぎません。

評価と通知が分離していることの実利は、運用が進んでから効いてきます。しきい値の妥当性を検討する作業と、誰に知らせるかを決める作業は、担当者も見直しの周期も違うからです。片方を触るともう片方が壊れる作りになっていないため、モニターは長く育てられます。

グループ化がアラートの粒度を決める

グループ化を指定しないモニターは、条件を満たしたときに 1 通だけ通知します。一方でホストやサービスといった次元でグループ化すると、対象ごとに独立して評価され、対象ごとに通知が飛びます。Datadog はこの 2 つを Simple Alert と Multi Alert という呼び分けで区別します。通知のまとめ方の設定で一部の次元を落とした場合、落とした次元は Sub Groups として画面上に列挙されます。 どちらを選ぶかは技術的な好みの問題ではなく、対応の単位をどこに置くかという運用設計の問題です。ホスト単位で分ければ 100 台が同時に倒れたときに 100 通が届き、受け手は障害の広がりを把握する前に通知の消化に追われます。逆にまとめすぎると、復旧したのは 1 台だけなのにモニター全体が復帰扱いになり、残りの異常が見えなくなります。判断の基準は「この通知を受けた人が、次に取る行動が同じかどうか」です。行動が同じならまとめ、違うなら分ける。この一点を先に決めておくと、しきい値の議論が空回りしなくなります。

データが来なくなったときの挙動を先に決める

モニターの落とし穴は、しきい値を超えたときよりも、データが届かなくなったときに現れます。Datadog は欠損時の扱いとして、ゼロとして評価する Evaluate as zero、直前の状態を保つ Show last known status、欠損状態を表示する Show NO DATA、それを通知まで行う Show NO DATA and notify、正常として扱う Show OK を用意しています。何も考えずに既定のままにすると、収集が止まったサーバーが「静かで健全」に見える状態が生まれます。 ここで押さえておきたいのは、欠損と判断するまでの待ち時間そのものは設定項目として開かれていない点です。2026 年 8 月時点の公式ドキュメントでは、この判定の幅は利用者が変更できないと明記されています。評価式に default_zero() を書いた場合は、欠損をゼロとして扱う挙動が式の側で固定されるため、欠損時の設定よりも式の書き方が先に効きます。 自動解決の設定も誤解されやすい項目です。これはデータの報告が止まったモニターを一定時間後に解決済みへ戻す機能で、しきい値を下回って正常に戻ったことを検知する仕組みではありません。ドキュメントも基本的に無効のまま運用することを勧めています。正常復帰を検知したいなら、復帰用のしきい値を別に置くのが筋の通った設計です。

評価の遅延とメンテナンス時間の扱い

クラウド事業者から取り込むメトリクスは、実際の時刻より遅れて Datadog に届きます。この遅れを無視して評価すると、まだ書き込まれていない直近の区間を見て欠損と判断してしまいます。モニターには評価を一定秒数だけ後ろへずらす設定があり、2026 年 8 月時点で指定できる上限は 86400 秒、つまり 24 時間です。公式ドキュメントは、遅れて埋められるクラウドメトリクスには 15 分程度、除算を含む式には 60 秒程度の遅延を推奨しています。 評価を回す間隔は、基本的に評価ウィンドウの長さから自動で決まります。日次・週次・月次のスケジュールに載せ替える設定はありますが、それ以外で間隔を直接選ぶことはできません。2026 年 8 月時点では、24 時間未満のウィンドウなら 1 分ごと、24 時間から 48 時間なら 10 分ごと、48 時間以上なら 30 分ごとに評価されます。長い窓を選ぶと反応が鈍くなるのは、しきい値の性質ではなく評価間隔そのものが伸びるためです。 計画されたメンテナンスの間だけ黙らせたい場合は、モニター側の条件をいじらず、期間を指定して通知を止める Downtime を使います。条件を一時的に緩めて戻し忘れる事故は、監視が形だけ残る典型的な壊れ方です。止めるための仕組みが分かれているのは、この事故を避けるためだと理解しておくとよいでしょう。

いつ気にする概念か、よくある誤解

モニターを本気で考え始めるのは、集めて眺めるだけの段階を抜けて、異常を人に知らせる段階に入ったときです。そこで実際につまずくのは、次の 3 つの思い込みです。 第一に、モニター 1 件がアラート 1 通に対応するという思い込み。グループ化した瞬間に、1 件のモニターは対象の数だけ独立した通知を生みます。第二に、鳴っていないことが正常の証明になるという思い込み。欠損時の扱いを詰めていなければ、沈黙は健全さではなく観測の停止を意味します。第三に、誤検知を減らすにはしきい値を厳しくすればよいという思い込み。瞬間的な跳ねが原因なら、しきい値を動かすよりも評価ウィンドウを伸ばして跳ねを畳んだ方が、本来検知したい持続的な悪化を取りこぼしません。 しきい値の値そのものは、あとから何度でも直せます。直しにくいのはグループ化の粒度と欠損時の扱いで、ここは通知を受ける体制と結び付いているぶん、後から変えると運用側の合意を取り直すことになります。設定を作るときは、この 2 つに時間を使うのが得です。仕様の一次情報は Datadog の公式ドキュメント Configure Monitors で確認できます。種類別の使い分けや通知文の設計まで踏み込んだ内容は、解説「モニターとアラート」で扱っています。