Datadog Watchdogの検知範囲と誤検知の抑え方｜手動モニターとの役割分担

Watchdogは設定を書かずに動く機能です。そのため、鳴ったときに「何を根拠に鳴ったのか」を運用側が説明できないと、通知の信頼が落ちて誰も見なくなる。逆に、見ている範囲と検知が始まる条件を先に把握しておけば、閾値を書き切れない領域を任せる相手として噛み合います。この記事では、Datadog公式ドキュメント（2026年8月16日時点）の記述に沿って、Watchdogが自動で見る4系統の対象、検知が動き出すまでに必要なデータ履歴、画面に出るInsightsと飛んでくるAlertsの役割差、Watchdog Monitorでのスコープ設計、誤検知と感じたときの切り分け手順、そして明示モニターとの線引きまでを実装目線で整理します。

まとめ：Watchdogを通知へつなぐ前に決める3つの線引き

ひとつ目は、検知が動き出すデータ条件を満たしているかの確認です。公式ドキュメントでは、ログは最低24時間、メトリクスは最低2週間の履歴が必要で、6週間あると精度が上がると説明されています。APM側のフィルタには毎秒0.5リクエスト以上という下限がある。立ち上げ直後のサービスで何も鳴らないのは、故障ではなく条件を満たしていないだけのことが多い。

ふたつ目は、Watchdog単体では通知が飛ばないという仕様の理解。画面に出るInsightsとアラート一覧は「見に行くもの」であり、当番の端末を鳴らすにはMonitors画面からWatchdog Monitorを作り、環境・カテゴリ・チームのセレクタでスコープを絞る作業が要ります。ここを飛ばすと「Watchdogを入れたのに気づけなかった」という結末になりやすい。

3つ目は、明示モニターとの役割分担です。当番が起きて対応する通知は、閾値と評価条件を自分で書いたモニターへ寄せてください。Watchdogは、まだ何を見るべきか洗い出せていない領域と、想定していなかった劣化を拾う側に置く。両方を同じ通知先へつなぐと同一事象で二重に鳴るため、配線を最初に分けておくと運用が保ちます。

Watchdogが設定なしで見ている範囲と検知が始まるデータ条件

Watchdogは、Datadogへ既に届いているデータを横断して見るエンジンです。公式ドキュメントには、全機能が組み込みで提供され、有効化のための設定作業は不要と記載されています。ただし「設定不要」は「何でも見てくれる」ではない。拾う対象の系統と、拾い始めるための履歴の条件が決まっています。製品全体の中での位置づけはDatadogとは何かで扱ったため、ここでは検知範囲の輪郭に絞ります。

Alertsが自動で拾う4系統とサポート対象の主なミドルウェア

自動で生成されるアラートの対象は、次の4系統に整理できます。

インフラ側でサポートされる対象は、システム指標のほかにRedis・PostgreSQL・MySQL・SQLServer・Cassandra・Oracle Database・NGINX・Docker・Kubernetesが挙げられています。クラウド側はS3、ELBとALBとNLB、CloudFront、DynamoDB、RDS、ECS、Lambdaが対象です。裏を返せば、この一覧に載らない自作の業務指標やカスタムメトリクスは、Watchdogの自動検知を待っても鳴りません。売上や在庫数のような業務固有の値は、自分で閾値を書くモニターの担当になります。

APMとUSMは同じ指標を見ますが、入口が違う。dd-traceで計装したサービスはAPM側、計装せずネットワーク越しに見えているサービスはUSM側で拾われます。計装とサービス名の付け方はDatadog APM導入の実装手順に整理しているため、Watchdogの検知単位が想定と合わないときは、まずserviceとenvの付き方を確認してください。

検知が動き出すまでに必要な履歴の長さとAPM側の下限リクエスト条件

Watchdogは、過去のデータから「普段どうであるか」を計算してから逸脱を判定します。そのため、データが薄い期間は判定に入れません。公式ドキュメントが示す条件は次のとおりです。

この3条件は、導入直後の問い合わせのほとんどを説明します。新規サービスをリリースした翌日に「Watchdogに出てこない」と相談を受けても、メトリクスの2週間に届いていなければ待つしかない。夜間帯だけ毎秒0.5リクエストを割り込むサービスでは、時間帯によって対象へ入ったり外れたりします。社内向けの管理画面のようにリクエストが少ないサービスを見張りたいなら、Watchdogではなく明示的なモニターを置くほうが確実です。

移行にも同じ話が効きます。エージェントの入れ替えや送信経路の変更でメトリクスの系列が変わると、Datadogから見れば別物の系列が始まった状態になり、そこから履歴を積み直す扱いになる。切り替え直後に検知が止まったように見えても、しばらくは静観してください。

画面で読むInsightsと飛んでくるAlertsで役割が分かれる仕組み

Watchdogという名前でまとめられている機能は、実際には性格の異なる2つに分かれます。調査中に画面へ差し込まれるInsightsと、一覧に蓄積されて通知の材料になるAlertsです。この違いを押さえると、どちらを運用へ組み込むかの判断が早くなります。

Insightsが出る画面の一覧と異常と外れ値の読み分けの基準

Insightsが表示されるのは、Log Explorer、Processes ExplorerとServerless ExplorerとKubernetes Explorer、APMのService PageとResource PageとProfile ExplorerとTrace Explorer、Database Explorer、Real User Monitoring Explorer、Synthetic Monitoring & Testing Explorer、そしてError Trackingのイシュー側パネルです。調査で開く画面のほとんどが対象に入っている、と考えて差し支えありません。

出てくる中身は2種類あります。ひとつは異常で、これは検索クエリに一致する既存のWatchdogアラートを引き当てて見せるものです。もうひとつが外れ値で、あるイベント種別の中で頻出しすぎるタグを動的に計算して示します。エラーの外れ値、レイテンシの外れ値、プロファイリング由来のロック競合やガベージコレクションの外れ値などが該当する。読み分けの基準は単純で、時間軸で普段と違うものが異常、同時点の集団の中で偏っているものが外れ値です。

障害調査では外れ値のほうが効きます。全体のエラー率が上がったときに、特定のバージョンやアベイラビリティゾーンだけ突出していれば、外れ値の右上から「Filter on Insight」で絞り込むだけで対象が半分に減る。詳細は「View all」で開き、共有は詳細パネルの「Copy Link」で足ります。イシュー単位で追う場面はDatadog Error Tracking実装手順側の集約と併せて使うと、原因箇所まで一気に降りられます。

アラートの状態が3種類で遷移する仕様とアーカイブ操作の使い分け

Alertsの状態は、ongoing、resolved、expiredの3つです。48時間以上続いたアラートはexpiredへ移ります。ここで気をつけたいのが、expiredは「解消した」ではなく「打ち切られた」に近い意味だという点。慢性的に遅いエンドポイントを放置すると、収まっていないのにexpiredで一覧から消えていきます。棚卸しでは、resolvedとexpiredを同じ扱いにしないでください。

一覧が読みづらくなったら、確認済みのアラートはアーカイブできます。アーカイブしたものは「Show N archived alerts」で呼び戻せるため、消したつもりが消えていないのを前提に運用してよい。ただしアーカイブは表示の整理であって、検知そのものを止める操作ではありません。同じ事象が翌週また上がってくるなら、次の章のスコープ設計へ手を入れる番です。

Watchdog Monitorで通知先へつなぐときのスコープ設計

Watchdogが検知しても、それだけでは誰の端末も鳴りません。通知へつなぐには、Monitors画面のNew MonitorからWatchdogを選び、モニターとして作成します。対象はAPM、Infrastructure、Logsの3領域です。閾値や評価ウィンドウを自分で書く他タイプとの違いは、鳴る条件をこちらで指定せず、届く範囲だけを設計する点にあります。

環境とカテゴリとチームの3セレクタで通知が届く範囲を絞る設計手順

用意されている事前セレクタは3つです。Environmentはenvタグから派生し、Alert Categoryは検知の種類、TeamはCatalogの情報から派生します。加えて、Watchdogのイベントに付いた任意のタグでのフィルタと、通知をまとめる単位を決めるGroup Byが使えます。

1. Environmentで本番環境に限定する（開発や検証を混ぜない）
2. Alert Categoryで扱う系統を決める（まずはAPMかLogsの片方から）
3. Teamまたはタグで担当範囲へ寄せ、宛先を1系統に固定する
4. Group Byの粒度を粗く保ち、通知が分割されすぎない形にする

この順で作ると、最初の1週間で通知の量が読めます。逆にGroup Byをサービス単位やホスト単位まで細かくすると、1つの障害が何十件もの通知に割れて当番が読み切れなくなる。分割の粒度と通知テンプレートの書き分けはDatadogモニターのタイプ選定と閾値設計で扱っているため、そちらの設計をそのまま流用してください。

ログ異常が3つのタグを基準に拾われる仕様と通知粒度を決める基準

ログ側の異常は、service、source、envの3つのタグを基準に検出されます。モニターのスコープにこの3つを含めた場合は該当する異常だけが対象になり、hostのような別のタグを足すと、そのタグと関連づく組み合わせだけに絞られる仕様です。

実務でつまずくのは、この3タグが揃っていないログを流しているケース。sourceが未設定のまま取り込んだログは、パイプライン側で属性を整えるまでWatchdogの判定単位に乗りません。取り込み経路とタグの整備はDatadogログ収集の3経路とパイプライン設計にまとめてあるので、ログ異常を通知へ回す前に整えておく価値があります。粒度の決め方としては、当番が1件ずつ対応できる単位、つまりサービス単位より1段粗いチーム単位から始めるのが扱いやすい。

誤検知と感じたアラートを切り分ける3つの確認と鳴り方の抑え込み

Watchdogへの不満は、ほぼ「鳴った理由が分からない」に集約されます。ここは仕組み上、閾値を書いていない以上どうしても起きる。ただ、原因の切り分けは定型化できます。

鳴った理由を説明できないアラートで先に確かめる3つのデータ前提

第一に、履歴の長さを見てください。メトリクスで2週間、ログで24時間という下限をぎりぎり超えたばかりの対象は、普段の姿の推定が浅く、平常の変動を逸脱と見なしがちです。6週間まで貯まると落ち着くケースが多いため、立ち上げ期の鳴り方だけで機能そのものを判断しないほうがよい。

第二に、トラフィックの量です。毎秒0.5リクエストの下限付近を行き来するサービスは、母数が小さいぶん率の変動が大きく出ます。1件のエラーでエラー率が跳ねる規模なら、率ではなく件数で見る明示モニターへ切り替える判断が要ります。

第三に、直前の変更を疑ってください。デプロイでのversionタグの付け替え、環境の統廃合によるenvの変更、エージェントの入れ替えは、いずれもデータの見え方を変えます。変更の直後に増えたアラートは、システムの劣化ではなく観測側の変化を拾っている可能性がある。デプロイ時刻と突き合わせるだけで、切り分けはかなり進みます。

アラートのアーカイブとスコープ縮小のどちらを先に打つかの判断基準

切り分けの結果で打ち手を分けます。単発で、原因を説明できたものはアーカイブで閉じる。同じサービスや同じ環境で週に何度も繰り返すものは、アーカイブを続けても手間が増えるだけなので、モニター側のスコープを縮めてください。具体的には、Environmentを本番だけに限定する、Alert Categoryを絞る、当該サービスのタグを除外条件へ回す、の順で効きます。

順序の判断基準は言い切れます。通知そのものを止める前に、スコープを縮めるほうを先に打ってください。通知を止めると再開の判断が誰の担当でもなくなり、そのまま忘れられる。スコープの縮小なら、範囲が台帳に残るため、後から広げ直す判断ができます。アーカイブは記録の整理であって、通知設計の道具ではないという整理を、チーム内で共有しておくと迷いが減ります。

自動検知へ任せる範囲と明示モニターで書き切る範囲を分ける判断基準

ここまでの内容を、採用と見送りの条件へ落とします。Watchdogは監視設計の代替ではなく、設計から漏れた領域を拾う補助という位置づけが実務に合います。

Watchdogの通知先を分けて二重発報を避ける配線と当番への渡し方

当番の端末を鳴らす通知は、閾値も評価条件も自分で書いたモニターに限定してください。Watchdog Monitorの宛先は、チャットの記録用チャンネルや日次で見るダッシュボードへ寄せる。理由は単純で、同じ障害を明示モニターとWatchdogの両方から鳴らすと、当番は同一事象を2回起こされ、やがて両方を無視するようになるからです。

記録用に寄せても価値は落ちません。朝会で前日のWatchdogアラートを流し見て、明示モニターが拾えていなかった事象があれば、そこを次のモニター化の候補にする。この回し方なら、Watchdogは監視設計を育てる入力になります。エスカレーションの段組みと当番の持ち回りはDatadog On-Callのスケジュールとエスカレーション設計で扱っているため、宛先の分離はそちらの設計に合わせて配線してください。

Watchdogの採用を見送る条件と記録用に留める運用へ寄せる場面

見送ってよい場面は3つあります。監視対象がサービス数本で、担当者が全ての閾値を書き切れている段階。夜間や休日にトラフィックが下限を割り込み、率の判定が安定しない小規模な社内システム。そして、通知先が1チャンネルしかなく、記録用と当番用を分けられない体制です。この状態でWatchdogを通知へつなぐと、既存の通知が埋もれる副作用のほうが大きい。

採用する条件も明確です。サービスの数が増えて何を見張るべきかの洗い出しが追いつかなくなった段階、外部サービスやミドルウェアの劣化のように自分たちの想定に入りづらい事象を拾いたい場面、そして障害調査でInsightsを入口として使いたい場面。いずれかに当てはまるなら、記録用チャンネルへ配線したうえで2週間ほど鳴り方を観察し、そこから通知設計へ組み込むかを決めてください。なお、調査そのものを自動で進める機能はBits AI SREの基本概要で扱う別物であり、Watchdogの検知と混同しないほうが判断がぶれません。

監視の設計と当番運用を社内だけで回し切るのが難しい場合は、保守運用・内製化支援のように、運用を引き受けながら手順を移管していく形も選べます。検知の仕組みを入れるところまでは短期間で終わりますが、鳴り方を見て育てる工程は継続が要る領域です。

よくある質問：Watchdogの検知範囲と通知設定でつまずく点

Watchdogを使い始めるのに設定作業は必要ですか？

公式ドキュメントでは、Watchdogの各機能は組み込みで提供され、セットアップは不要と説明されています。ただし通知は別で、当番へ飛ばすにはMonitors画面からWatchdog Monitorを作る作業が要ります。検知は自動、配線は手動、という整理で覚えてください。

新しく作ったサービスがWatchdogに出てこないのはなぜですか？

データ履歴の条件に届いていない可能性が高い。メトリクスは最低2週間、ログは最低24時間が必要で、APMのフィルタには毎秒0.5リクエストという下限があります。リリース直後や低トラフィックのサービスは対象へ入りません。急ぐなら明示モニターを置いてください。

Watchdogのアラートを特定のチームだけに通知できますか？

できます。Watchdog Monitorの事前セレクタにEnvironment、Alert Category、Teamがあり、Teamはカタログの情報から派生します。加えてWatchdogのイベントに付いたタグでのフィルタも使えるため、環境で本番に限定してからチームで宛先を絞る形が扱いやすい。

Bits AI SREとWatchdogはどう違いますか？

Watchdogは、普段の姿からの逸脱を自動で見つけて知らせる検知側の機能です。調査を代行して仮説を立てる機能とは目的が異なります。前者は「気づく」ための仕組み、後者は「調べる」ための仕組みと分けて考えると、どちらを先に入れるかの判断がしやすい。

誤検知が続くアラートは消してしまってよいですか？

まずアーカイブで一覧から外しつつ、繰り返すものはモニターのスコープを縮めてください。アーカイブは表示の整理で、検知は止まりません。通知を丸ごと止めると再開の判断が宙に浮くため、範囲を狭める対応を先に打つほうが後戻りできます。

関連記事

• Datadogとは何か？機能やメリット、導入の背景を詳しく解説
• Datadogモニターのタイプ選定と閾値設計：評価ウィンドウと通知テンプレートの実装手順
• Datadog On-Callのスケジュールとエスカレーション設計：少人数運用の実装手順
• Datadogログ収集の3経路とパイプライン設計：インデックス制御で保管費を抑える実装手順
• Datadog Error Tracking実装手順：イシュー集約とソースマップ登録、APM/RUM/Logs連携
• Bits AI SREの基本概要とDatadog製品群内での位置付け