アラート
監視条件が満たされたことを人やシステムへ知らせる通知そのもので、条件を持つモニターとは別の層として設計します。
概要
Datadog のアラートは、モニターの状態が変わったときに宛先へ送り出される連絡を指します。条件やしきい値を保持するのはモニター側で、アラートは「誰に、どんな文面で、何回届けるか」を担う層です。この二層を分けて考えると、監視は動いているのに誰も気づかなかった、逆に鳴りすぎて読まれなくなった、という失敗をそれぞれ別の作業として直せます。宛先の指定方法、本文に埋め込める変数、再通知と集約の効き方が設計の柱になります。
アラートとモニターの線引き
監視条件を定義した設定そのものは モニター と呼ばれ、その条件が満たされて状態が変わったときに外へ送り出される連絡がアラートです。状態を保持するのはモニター側で、アラートはその状態遷移から生まれる出力にあたります。この線引きが効くのは障害の振り返りのときです。状態は正しく alert に変わっていたのに誰も動かなかったのなら、直す対象はしきい値ではなく宛先と文面です。逆に状態が変わっていなかったのなら通知をいくら整えても届きません。Datadog の設定画面でも、評価条件の節と通知の節は別の区画として並んでいます。アラートを受け取る側から見ると、1 件のモニターが送る通知は 0 回のこともあれば、再通知の設定によって何度も届くこともあります。件数はモニターの数ではなく通知設計で決まると考えたほうが実態に合います。
誰に届けるかを決める
宛先の指定には三つの層があります。Datadog は個々のモニターに手で宛先を書き並べるのではなく、モニター通知ルールで条件に応じて宛先を自動的に足す方法を推奨しています。
- 通知ルール: 通知に付く タグ の条件で宛先を自動割り当てする
- モニター本文の宛先指定:
@に続けて人・連携先・ワークフローを書く - 連携先の接頭辞:
@slackや@pagerdutyのように連携ごとの書式で経路を選ぶ
連携の書式は @<INTEGRATION_NAME>-<VALUES> で、Jira・PagerDuty・Slack・Webhooks・Microsoft Teams・ServiceNow などの接頭辞が用意されています。書式には二つの落とし穴があり、宛先指定の直前には空白が必要で、丸括弧を含むハンドルは解釈されずアラートが作られません (2026 年 8 月時点)。メールは @ に続けてアドレスを書けば Datadog の利用者以外にも送れますが、招待が未承諾の利用者や無効化された利用者は受信対象になりません。詳細は Datadog の Notifications を参照してください。
本文は手順書として書く
通知本文の欄は Markdown 記法と変数に対応しており、受け取った人がそのまま動ける手順を書けます。条件変数 {{#is_alert}} で状態ごとに文面を切り替え、タグ変数 {{host.name}} で発火した対象名を差し込む、という組み合わせが基本形です。ディスク容量の警告なら、不要パッケージの削除から重複ファイルの整理までを番号付きで並べ、末尾に担当チャンネルの宛先を置く形が公式の例として示されています。ただし Markdown の解釈は経路ごとに差があります。Slack とメールのどちらも太字・斜体・インラインコード・リンクは効きますが、表は整形されずそのままの文字で届き、Slack では見出し記法も文字のまま出ます。表で整理したくなる場面でも、通知本文では箇条書きに落としたほうが読める形で届きます。重要度は P1 から P5 の優先度で表せます。既定の優先度に対して {{override_priority 'P1'}} を使えば、同じモニターでも警告状態と障害状態で別の優先度を送り出せます。
鳴り続ける通知と鳴らない通知を整える
解決されない問題を思い出させたいときは再通知を有効にします。設定できるのは間隔、再通知の対象にする状態 (alert・warn・データ無し)、そして送る回数の上限です。上限を 1 回にすれば、最初のアラートのあとに一度だけ念押しが届く形になります。段階を上げた文面は {{#is_renotify}} のブロックに書く方法が推奨されており、この場合は元の本文も一緒に送られるため、ブロック内には追加の情報だけを書きます。逆に鳴りすぎを抑える側では集約が効きます。モニターのクエリがグループ化されている場合、通知のグループ化から一部の軸を外したり、すべて外して 1 通にまとめたりできます。あわせて、通知に載せる内容も選べます。クエリだけを隠す、宛先の一覧だけを隠す、クエリ・宛先・スナップショット・末尾の関連リンクをまとめて外す、という選択肢が用意されているので、監視の中身を外部チャンネルへ流したくない場合はここで絞ります。作り終えたら送信テストで実物を確認します。テストでは状態遷移とグループを選んで実際に送れ、送られた通知には試験であることが分かる印が付いてイベントとして記録されます。
設計順序と取り違え
順番を「鳴った後の 3 分で人が何をするか」から逆算すると手戻りが減ります。最初に受け手を決め、次にその受け手が動くための文面を書き、最後に再通知と集約で音量を調整する、という順です。しきい値の微調整から入ると、届いた人が何をすべきか分からないまま鳴り続ける状態が残りがちです。取り違えやすい点が二つあります。一つは、アラートが届かないことを取りこぼしと同一視することです。宛先が無効な利用者だった、書式が壊れていた、といった経路側の理由でも同じ症状になります。もう一つは、通知の件数を障害の件数として読むことです。集約と再通知の設定次第で、同じ 1 件の障害が数十通になることも 1 通になることもあります。件数を指標として扱うなら、集約設定を固定してから比較してください。アラートを含むモニター全体の組み立ては モニターとアラート の解説で扱っています。