Datadogモニターのタイプ選定と閾値設計：評価ウィンドウと通知テンプレートの実装手順

Datadogでモニターを作るとき、詰まるのは作成画面の操作ではありません。29種類あるタイプのどれに対象を載せるか、閾値と評価ウィンドウをどの数値に置くか、データが欠けた時間をどう扱うか。この3点を決めずに画面の初期値のまま保存すると、鳴らしたい障害では鳴らず、深夜のデプロイでは鳴り続けます。この記事では、タイプの選び分けから閾値の3段構成、評価ウィンドウと評価遅延、多重アラートとコンポジット、通知テンプレートの変数構文までを、2026年8月時点の公式ドキュメントに記載された設定名と制約に沿って整理します。

まとめ：Datadogモニター設計で先に決める3つの判断

第一に、タイプは「どのデータストアを評価するか」で決まります。公式のモニタータイプ一覧には2026年8月時点で29種類が並びますが、実務で最初に触るのはメトリクス、ログ、外形、サービスチェックの4系統に収まる。ここを取り違えると、後から閾値をいくら調整しても意図した粒度になりません。

第二に、閾値は1つではなく3つ置きます。alert threshold（発報）とwarning threshold（警告）に加え、recovery threshold（復旧）を別の値に置くと、境界をまたいで往復する通知が止まる。復旧側を指定しない場合、Datadogは発報の閾値を下回った時点で復旧扱いにするため、境界付近で揺れる指標ほど往復が増えます。

第三に、データが来ない時間の扱いを先に決めます。欠損時の挙動は5つの選択肢から選ぶ設計で、バッチのように止まる期間がある対象と、常時流れる対象では選ぶべき値が違う。自動解決はデータ送信が止まった場合にのみ機能する仕様なので、通知が消えない理由をここで取り違えないようにします。

モニタータイプを4系統へ整理して対象データから選び分ける手順

タイプの一覧を上から読んで選ぶと迷います。判断の起点は「Datadogのどの製品に入っているデータを見るか」で、そこが決まればタイプは1つか2つに絞れる。メトリクスとして数値が入っているならMetric系、テキストとして入っているならLogsやEvent、外から叩いた結果ならSynthetic Monitoring、Agentが返す状態ならService CheckやProcess Checkです。到達そのものの前提はDatadog Agent導入の実装手順とdatadog.yamlの設定範囲で扱っています。

この4系統に畳んでから対象を当てはめると、タイプ選定に時間を取られません。SLO Alerts、Cloud Cost、Database Monitoringのように特定の製品を契約している場合だけ現れるタイプもあるため、画面に出ていないタイプを探し続けないことも判断の一部です。

メトリクスモニターの評価式を集計とrollupの順で組み立てる

メトリクスモニターの式は、評価ウィンドウ・空間集計・時間集計・条件の4要素でできています。書く順番を固定すると設定漏れが減る。まず何分間を見るか、次に複数ホストの値をどうまとめるか（avg、max、sum）、次に時間方向の丸め方を決め、最後に比較演算子と閾値を置きます。

1. 評価ウィンドウを対象の変化速度に合わせて選ぶ
2. 空間集計を決めて対象ホストやコンテナの束ね方を固定する
3. 時間集計の丸め方を指定して欠測点の扱いをそろえる
4. 比較演算子と閾値を置いて発報条件を確定する

空間集計をavgのまま本番へ載せる設定は、台数の多い環境で鳴りません。10台のうち1台がCPU100%でも平均は上がらないためで、個別に見たいならmaxにするか、後述の多重アラートでホストごとに分割します。逆に、全体の傾向として捉えたい指標をmaxで見ると、1台の瞬間値で毎回鳴る。

ログとイベントのモニターで変わる評価ウィンドウの上限と件数条件

ログモニターは、検索クエリに一致した件数を閾値と比較する構造です。メトリクスと同じ感覚で長い期間を指定すると設定できない場面があり、公式ドキュメントではログモニターの評価ウィンドウ上限を最大2日と記載しています。日次のバッチ失敗を1週間分まとめて見る、といった設計はここで成立しません。

件数条件は「何件出たら鳴らすか」に見えて、実際は「どの検索クエリで絞ったか」で精度が決まります。status:error だけで拾うと、想定内のリトライまで件数に入る。ログ側の属性設計とパイプラインの整え方はDatadogログ収集の3経路とパイプライン設計で扱っており、標準属性へ寄せてから検索条件を書くほうが、モニター側の調整は軽くなります。

閾値の3段構成と評価ウィンドウを実データの到達間隔に合わせる

閾値の数値は、感覚ではなく直近の実測から置きます。ダッシュボードで対象指標の2週間分を見て、通常時の上限と障害時の値を確認してから決める。画面側の作り方はDatadogダッシュボードの作り方とウィジェット選定にまとめています。ここで実測を挟まずに「CPU80%」のような一般値を置くと、環境によっては常時超過するか、一度も超えないかのどちらかになります。

alertとwarningの2段に分けて対応の緊急度を通知へ載せる

warning thresholdは任意項目ですが、置くと運用が変わります。alertだけの設計では通知はすべて同じ重さで届き、受け取った側は毎回ログを見に行くことになる。warningを一段手前に置き、通知先をチャットのチャンネルだけにしておけば、電話が鳴る対象を絞れます。

2段に分けるときの目安は、対応の期限差です。warningは「今日中に見る」、alertは「今すぐ見る」と定義し、その定義に合う数値を置く。数値を先に決めて後から意味を付けると、warningが実質的に無視される通知になります。通知先を分ける運用の型そのものはDatadog運用のベストプラクティスで整理したアラート設計を前提にしてください。

recovery thresholdを別値に置いて状態の往復を止める

recovery thresholdは、alertとwarningの双方に任意で設定できる復旧側の条件です。指定しない場合、値が発報の閾値を下回った時点で復旧扱いになります。閾値ちょうどの付近で揺れる指標では、この仕様が通知の往復を生む。

実装は単純で、発報が80なら復旧を70に置くだけです。幅は、その指標が通常時に取る値のばらつきに合わせる。ばらつきが大きい指標ほど広げ、狭い指標では5ポイント程度でも往復は止まります。それでも止まらない場合は、閾値ではなく評価ウィンドウが短すぎる可能性を疑ってください。

評価ウィンドウと評価遅延を実データの到達間隔に合わせて決める

評価ウィンドウには、ローリングと累積の2系統があります。ローリングは直近5分・15分・1時間、およびカスタムで最大1か月まで指定でき、累積は現在の時間・現在の日・現在の月という区切りです。累積は月内の使用量や日次の総量を見る対象に向き、瞬間的な障害検知には向きません。

もう1つ効くのが評価遅延（evaluation delay）で、設定上限は86400秒（24時間）です。公式ドキュメントはクラウドのメトリクスに対し15分程度の遅延を推奨しており、これはAWSやAzure側からDatadogへ数値が届くまでに時間差があるためです。遅延を入れずに評価すると、まだ届いていない直近の点が欠測として扱われ、実体のないNO DATAが鳴ります。

データ欠損時の挙動と自動解決・再通知の間隔を先に決める設計手順

欠損の設計を後回しにすると、通知の半分が「データが来ていない」で埋まります。対象がバッチなのか常駐プロセスなのか、Agentが止まる可能性があるのか、クラウド連携の遅延があるのか。この違いによって選ぶべき挙動が変わるため、モニターを作る時点で対象ごとに決めておきます。

データ欠損の扱いは5つの選択肢から監視対象ごとに決めておく設計

公式ドキュメントは、指定した分数のあいだデータが届かない場合の挙動として5つの選択肢を示しています。ゼロとして評価する、最後に判明している状態を維持する、NO DATAを表示する、NO DATAを表示して通知する、OKを表示する。この5択のどれを選ぶかで、同じモニターでも運用の手触りが変わります。

選び分けの目安は3つです。件数系のログモニターは、届かない＝0件が正しい状態なのでゼロ評価が噛み合う。常駐プロセスのメトリクスは、届かないこと自体が異常なのでNO DATAで通知する。バッチや夜間停止する環境は、最後の状態を維持するか、OK表示にして無音の時間を作ります。

自動解決が効く条件と再通知の間隔を運用の当番体制から決める基準

自動解決（auto resolve）は「Never」または1時間後・2時間後といった選択肢から選びますが、動く条件が限定されています。公式ドキュメントの記述では、データが送信されなくなった場合にのみ、発報状態のイベントを自動で解決する仕様です。数値が閾値を下回って復旧した場合の解決は、あくまで復旧条件の側で判定されます。

再通知の間隔は、当番の体制から逆算します。当番表そのものの組み方はDatadog On-Callのスケジュールとエスカレーション設計で扱っています。24時間の当番がいるなら短く、平日日中のみなら夜間の再通知は意味を持たない。間隔を短く置いたまま夜間を通すと、朝には同じ通知が数十件並び、対応の優先順位が読めなくなります。通知過多そのものの構造はアラート疲れの原因と対策を監視の実装視点で整理した記事で扱っています。

多重アラートとコンポジットモニターで通知の件数を絞り込む設計

1つのモニターが何十件もの通知を出すとき、原因は閾値ではなく分割の粒度にあります。多重アラート（multi alert）は group by に指定したタグの値ごとに独立して評価し、条件を満たした単位ごとに通知を出す仕組み。便利な反面、粒度を細かく取りすぎると1度の障害が通知の束になります。

group byの粒度を落として通知が分割される件数を抑える

粒度は「対応の単位」に合わせます。ホスト単位で対応するならホスト、サービス単位で対応するならサービス。コンテナIDのように入れ替わる値でgroup byすると、デプロイのたびに新しい単位が生まれ、通知が増えるうえに履歴も追えません。

公式ドキュメントも、通知の次元から必須でないグループ属性を外すことでノイズを減らせると記載しています。実装としては、評価はホスト単位のまま、通知のテンプレート側でサービス名だけを出す形も取れる。分割の単位と表示の単位を別に考えると、粒度の調整が進みます。タグの命名そのものがそろっていない環境では、まずタグ設計から手を付けたほうが早い。

複数のモニターを1つの式でまとめて発報の条件を厳しくする手順

コンポジットモニターは、既存の複数モニターの状態を式で組み合わせて発報します。「CPUが高い」だけでは鳴らさず、「CPUが高い、かつレスポンスタイムが伸びている」で鳴らす、といった条件が書ける。単体では誤報になりやすい指標を、実害の出ている指標と掛け合わせて絞り込む使い方です。

注意点は、元のモニターを消すとコンポジット側が壊れることと、状態の遷移が元モニターの評価タイミングに依存することです。元モニターの評価ウィンドウがそろっていないと、条件を同時に満たす瞬間が生まれにくく、鳴るはずの場面で鳴らない。組み合わせる前に、元モニター側のウィンドウをそろえておきます。

通知テンプレートの本文を条件変数とタグ変数で書き分ける実装手順

通知本文を初期値のまま運用すると、受け取った側は毎回Datadogを開くことになります。テンプレートには3系統の変数があり、状態で分岐する条件変数、イベントに付いたタグや属性を差し込むタグ変数と属性変数、モニターの数値を出すテンプレート変数を組み合わせて書く。数値は {{value}} と {{threshold}}、比較演算子は {{comparator}} で出せます。

条件変数の内側と外側で通知先が呼び出される場面が変わる設計仕様

公式ドキュメントは、条件変数の外に置いたテキストと通知ハンドルはすべての状態遷移で呼ばれ、条件変数の内側に置いたものは条件に一致した遷移でのみ呼ばれる、と明記しています。この違いを知らずに宛先を先頭へ並べると、復旧の通知まで同じ宛先へ飛ぶ。

実装の型は、共通の説明文を外に、宛先を条件変数の内側に置く形です。{{#is_alert}} のブロックに緊急の宛先、{{#is_warning}} にチャットの宛先、{{#is_recovery}} には復旧の記録先だけを書く。再通知だけ宛先を変えたい場合は {{#is_renotify}} を使い、欠損は {{#is_no_data}} で分けます。

タグ変数で通知の宛先を切り替えて配線の本数を減らす書き方の型

宛先をサービスごとに固定で書くと、サービスが増えるたびにモニターを複製することになります。タグ変数を宛先の一部に埋め込めば、1本のモニターで宛先が切り替わる。公式ドキュメントは @slack-{{service.name}} の形でサービスごとのチャンネルへ振り分ける例を示しています。

成立の条件は、タグの値とチャンネル名の対応が崩れていないことです。service タグの表記ゆれが1つでもあると、その通知は宛先の解決に失敗して届かない。導入直後はタグの値の一覧を突き合わせ、対応しないチャンネルが出た場合の受け皿として、条件変数の外に共通の宛先を1つ残しておく設計が安全です。本文には {{last_triggered_at}} や {{triggered_duration_sec}} を入れておくと、継続時間が一目で読めます。

AnomalyとForecastを採用できる条件と見送る場面の判断基準

検知アルゴリズムを使うタイプは、閾値を決めなくてよい代わりに、鳴った理由の説明が難しくなります。導入判断は「その指標に安定した周期があるか」と「鳴った後に誰が判断するか」の2点で決まる。この2つが揃わない環境では、固定閾値のMetricモニターのほうが運用は続きます。

Anomalyが向く指標と向かない指標を分ける実務上の境界線

Anomalyは過去の履歴から通常の範囲を推定し、そこから外れた挙動を検知します。向くのは、平日と休日、昼と夜で水準が明確に変わる指標。リクエスト数やログイン数のように、時間帯で数倍動く対象は固定閾値だと昼夜どちらかで意味を失うため、ここは相性が良い。

向かないのは3つです。履歴が数週間分もない新規サービスの指標、デプロイのたびに水準が変わる指標、そもそも通常時がほぼ一定で固定閾値のほうが説明しやすい指標。とくに「なぜ鳴ったか」を運用者が説明できない状態は、通知の信頼を落とします。採用するなら、まず通知なしのモニターとして1〜2週間動かし、鳴り方を見てから通知先を付けてください。

Forecastで先に鳴らす判断とWatchdogに任せる範囲の線引き

Forecastは、指標が閾値を将来またぐと予測された時点で鳴らすタイプです。ディスク使用量やライセンス消費のように、単調に増えて枯渇する対象に向く。逆に上下を繰り返す指標では予測が安定せず、鳴ったり止まったりを繰り返します。

Watchdogは、こちらで指標を指定せずDatadog側が異常を検出して通知する仕組みで、設計の対象というより発見の補助です。監視対象を洗い出す前の初期段階や、想定していなかった箇所の劣化を拾う用途に置く。設計として鳴らす対象はMetricとLogsで明示的に書き、Watchdogは補助に留める線引きが、通知の説明可能性を保ちます。外形からの検知はDatadog Syntheticsの実装手順と頻度設計で別に組み合わせてください。

モニターをコードで管理する境界線と運用で手作業に残す範囲の判断

モニターが数十本を超えると、画面での管理は破綻します。誰がいつ閾値を変えたか追えず、同じ内容のモニターが複数残る。ここからはコード管理へ寄せる判断になりますが、全部をコードにするのが正解とは限りません。

datadog_monitorで管理する範囲と画面で作る範囲の分け方

Terraformの datadog_monitor リソースを使うと、モニターの定義をリポジトリで管理できます。レビューが入り、環境ごとの複製もモジュール化で済む。本番と検証で同じ監視をそろえたい場面では、この管理方法が効きます。

一方で、調査中に一時的に置くモニターや、閾値を毎日動かしながら詰めている段階のモニターまでコードにすると、手数が増えて調整が止まります。分け方の目安は「本番の当番が対応する対象かどうか」。対応対象になったモニターだけをコードへ移し、それ以外は画面のまま残して定期的に棚卸しする運用が現実的です。画面側から入る場合の初期手順はDatadogの使い方とAgent導入から最初の監視までの流れにまとめています。

モニターを増やさない判断と定期の棚卸しで削る対象を決める基準

監視は足すほど安心に見えて、通知が増えるほど1件あたりの注意は薄まります。増やす前に問うべきは「鳴ったとき、誰が何をするか」。この答えが出ない対象は、モニターではなくダッシュボードに置くほうが噛み合う。判断の全体像はDatadogとは何かと機能の全体像を押さえたうえで組み立ててください。

棚卸しの基準は3つです。直近3か月で一度も鳴っていないモニターは、条件が実態と合っていない可能性が高い。鳴っているが誰も対応していないモニターは、通知先か閾値のどちらかが間違っている。同じ事象で必ず一緒に鳴る複数のモニターは、コンポジットへ寄せるか片方を削る。四半期に一度、この3点で棚卸しすると本数は増え続けません。

モニターの設計と棚卸しは、一度作って終わりではなく、サービスの増減や当番体制の変化に合わせて見直し続ける運用作業です。社内に監視の専任を置けない場合は、保守運用・内製化支援で設計と定期見直しを引き受けています。既存モニターの棚卸しから閾値と通知先の再設計、運用手順の内製化までを段階的に移管する形も選べます。

よくある質問：Datadogモニターの設定と通知でつまずく点

モニターの設定と通知について、問い合わせの多い5点に答えます。

モニターのタイプは作成後に変更できますか？

タイプそのものの切り替えはできず、別タイプで作り直すことになります。作り直しの際に消えるのは、モニターIDに紐づく通知履歴とミュートの設定、そしてコンポジットモニターからの参照です。コンポジットに組み込んでいるモニターを作り替える場合は、先に参照側の式を確認してください。ダッシュボードに貼っているモニターのウィジェットも同様に貼り直しになります。

通知が多いときは閾値と評価ウィンドウのどちらから直しますか？

評価ウィンドウを先に見ます。短いウィンドウは瞬間値を拾うため、閾値を上げても別の瞬間で鳴る。5分を15分へ広げるだけで通知が落ち着く例は多くあります。それでも収まらない場合に閾値を調整し、次に復旧側の値を離し、最後に group by の粒度を落とす。この順で触ると、検知の感度を落とし過ぎずに件数だけを減らせます。

NO DATAの通知が頻発するときは何を確認しますか？

確認は3段階です。第一に評価遅延で、クラウド連携のメトリクスは到達に時間差があるため、15分程度の遅延を入れると解消する場合があります。第二に欠損判定までの分数で、短すぎると一時的な欠測で鳴る。第三にAgentやインテグレーション側の停止で、対象ホストが実際に消えていないかを確認します。バッチのように止まる時間がある対象では、そもそもNO DATAで通知しない選択も取れます。

AnomalyモニターとWatchdogはどう使い分けますか？

Anomalyは対象の指標をこちらで指定し、その履歴から外れ値を検知します。Watchdogは指標を指定せず、Datadog側が異常を見つけて知らせる仕組み。設計として鳴らしたい対象が決まっているならAnomaly、まだ何を見るべきか洗い出せていない段階ならWatchdogを補助に置く形が噛み合います。両方を同時に通知先へつなぐと同じ事象で二重に鳴るため、Watchdog側は記録用のチャンネルに留めるのが扱いやすい。

モニターはすべてTerraformで管理すべきですか？

すべてを移す必要はありません。本番の当番が対応する対象だけをコードへ移し、調査用や調整中のモニターは画面に残す分け方が現実的です。全部をコードにすると、閾値を1つ動かすのにレビューと適用の手間がかかり、調整の頻度が落ちる。逆に本番の監視を画面のままにすると、変更の履歴が追えず、退職や異動で経緯が失われます。

関連記事

• Datadogの使い方｜アカウント作成から最初の監視までの手順：本記事の前段となる初期導入と最初のモニター作成を扱っています。
• Datadog運用のベストプラクティス｜タグ設計とコスト抑制：通知先の型とタグ命名規約をまとめています。
• Datadogログ収集の3経路とパイプライン設計：ログモニターの前提となる属性設計を解説しています。
• アラート疲れとは｜原因と対策を監視の実装視点で解説：通知が増え続ける構造と減らし方を整理しています。
• Datadogダッシュボードの作り方｜ウィジェット選定と設計手順：閾値を決める前の実測に使う画面設計を扱っています。