予測モニター
予測モニターとは、メトリクスの過去の推移から将来の値を予測し、予測の帯の端が 12 時間から 3 か月先までの指定した期間内にしきい値へ届く見込みになった時点で通知する Datadog のモニター種別のこと。ディスク使用量のように一方向へ進む値が「いつ枯れるか」を、枯れる前に知らせる。
概要
予測モニターは、メトリクスの過去の推移から先の値を推定し、その予測がしきい値に届く見込みになったら知らせる Datadog のモニター種別です。判定に使うのは予測値そのものではなく信頼区間の帯の端で、帯がしきい値を越える時期が指定した先読み期間 (12 時間から 3 か月) に入ると発報します。線形の傾向を延ばす linear と、時間帯や曜日の繰り返しを織り込む seasonal の 2 つのアルゴリズムがあり、対象の値の性質で選びます。気にするのは容量計画の場面、つまりディスクや接続数のように満杯へ向かう値を、満杯になる前に手当てしたいときです。今の値が普段と違うかを見る異常検知モニターとは、見ている時間の向きが逆になります。
いつしきい値に届くかを先に告げるモニター
予測モニター (Forecast Monitor) はモニターの種別の一つで、メトリクスの過去の推移から先の値を推定し、その予測がしきい値に届く見込みになった時点で通知します。公式ドキュメントは、ログの出力量が増え始めたときにディスクが満杯になる 1 週間前に知らせる例と、利用者登録数のような業務指標を四半期の目標と照らす例を挙げています (2026 年 9 月時点・出典: Forecasts Monitor)。通知の条件は「予測の信頼区間の帯の端が、指定した先読み期間のうちにしきい値を上抜けるか、下抜けるか」です。先読み期間は 24 時間 / 1 週間 / 1 か月の選択肢か、12 時間から 3 か月の範囲で自由に指定します。しきい値を越えた事実ではなく、越える見込みで鳴る点が、他の種別と決定的に違います。
異常検知モニターとは、見ている時間の向きが逆
混同しやすい相手が異常検知モニターです。異常検知は「今の値が、過去の推移から期待される帯の中にあるか」を見るので、視線は過去から今へ向いています。予測モニターは「この先、帯の端がしきい値に届くか」を見るので、視線は今から先へ向いています。どちらも履歴から帯を作りますが、異常検知の帯は今の値を判定する基準であり、予測の帯は将来の値の見込み幅です。設定なしで動く組み込みの検知である Watchdog も過去の推移を土台にした異常の検知で、しきい値への到達時期を予告する仕組みではありません。クエリの上でも両者は別の関数です。予測の forecast() の中に異常検知の anomalies() や外れ値の outliers() を入れ子にすることはできません (2026 年 9 月時点・出典: Forecasts Monitor)。
linear と seasonal - 伸ばすか繰り返すか
アルゴリズムは linear と seasonal の 2 つです。linear は一定の傾向はあるが繰り返しの周期は無い値に向き、直線を延ばして先を描きます。seasonal は時間帯や曜日で同じ形を繰り返す値に向き、過去の周期を重ねて先を描きます。Datadog は選んだメトリクスを解析して各項目を自動で設定します (2026 年 9 月時点・出典: Forecasts Monitor)。まず自動設定のまま評価プレビューの予測線を見て、実感と合わないときだけ詳細オプションを触る順番が無難です。表の項目名は公式ドキュメントの表記に揃えています。
| 項目 | linear | seasonal |
|---|---|---|
| 向く値 | 傾向はあるが周期が無い値 | 時間帯や曜日で繰り返す値 |
| 形を決める選択 | model: default (直近の傾向に合わせつつノイズに頑健) / simple (履歴全体で頑健な線形回帰) / reactive (直近をよく延ばすがノイズや突発値に過適合しやすい) | seasonality: hourly / daily / weekly。daily と weekly では夏時間の切り替えも指定できる |
| 履歴の扱い | history で予測に使う過去の長さを指定する (例: 1w / 3d) | 少なくとも 2 周期分の履歴が必要で、最大 6 周期分を予測に使う |
| 共通の調整 | Deviations: 帯の幅 (1 か 2 で通常の点の大半が収まる) / Rollup: 集約間隔 (広げるとノイズの影響を受けにくい) | |
クエリの形を読むと、何を予測しているかが見える
API で作るときの query は、公式ドキュメントが示す骨格に従います (2026 年 9 月時点・出典: Forecasts Monitor)。先頭の集約子は、上抜けを見るなら max、下抜けを見るなら min を選び、続く next_7d のような窓が先読み期間です。forecast() の中には対象メトリクスのクエリ、アルゴリズム名、帯の幅を決める deviations (1 以上の数)、集約間隔の interval (秒) を並べます。linear ならそこへ history と model、seasonal なら seasonality を足します。末尾の比較子は上抜けが >=、下抜けが <= で、その右がしきい値です。公式ドキュメントは、この文字列を手で組むより、画面で作ったモニターの JSON を書き出してクエリを写す方法を強く勧めています。予測が「どの窓で、どの幅で、どの履歴から」作られているかは、この 1 行に全て現れます。
向く指標と向かない指標 - 容量計画に使うときの目安
向くのは、ディスク使用量、ストレージの残容量、キューの滞留数、接続数の上限に対する使用率のように、傾向を持って一方向へ進む値です。予測が成り立つ前提は「これまでの傾向か周期が、この先も続く」ことなので、リリースや障害のたびに段差やスパイクで動く値は、延ばすべき線がそもそも定まりません。そうした値は静的なしきい値や異常検知に任せ、予測モニターは容量と枯渇の予告に絞ると、役割分担が明快になります。履歴が足りない新しいメトリクスでは、seasonal は 2 周期分の履歴が揃うまで使えません。溜まるまでは静的なしきい値で守り、後から切り替える段取りになります。異常検知や外れ値との使い分けの一覧はモニターの解説に譲ります。予測が外れたときの手当ても通知の本文に書いておくと、受け取った人が「まだ余裕があるのか、今動くのか」をその場で判断できます。