イベント
イベントは、デプロイやモニターの状態変化のように、ある時刻に起きた出来事を 1 件として記録する信号です。数値の推移を追うメトリクスや処理の詳細を残すログとは役割が異なり、グラフに現れた変化と「いつ何を変えたか」を結びつける手がかりになります。
概要
イベントは、ある時刻に起きた出来事を 1 件として記録する信号です。Datadog はモニターの状態変化や Watchdog の検知、Error Tracking が見つけた新しいエラーから自動でイベントを作り、Agent と導入済みのインテグレーションもコンテナの再起動やジョブの完了といった出来事を送ります。自分でデプロイや設定変更を投入すれば、グラフが折れ曲がった時刻の真上に変更のしるしを立てられます。障害の原因を「いつ何を変えたか」から絞りたいとき、そして人の作業や外部システムからの通知を監視画面へ集めたいときに気にする概念です。
点の推移ではなく、起きたことの 1 件
イベントは、ある時刻に起きた出来事を 1 件として記録する信号です。メトリクス が同じ名前の数値を等間隔に並べて推移を見せるのに対し、イベントは「いつ / 何が / どこで」起きたかを 1 件ずつ残します。件数が増えても連続した線にはならず、時間軸の上に点として並ぶのが特徴です。この形が効くのは、数値の変化に理由を与えたいときです。応答時間のグラフが 14 時に跳ねた事実はメトリクスが教えてくれますが、14 時にリリースが行われたことはメトリクスのどこにも書かれていません。両者を同じ時間軸に並べて初めて、変化と原因が線でつながります。
イベントはどこからやってくるのか
出どころは大きく 3 系統に分かれます。1 つ目は Datadog 自身が作るもので、モニター の状態変化や Watchdog の検知、Error Tracking が見つけた新しいエラーが自動でイベントになります。2 つ目は Agent と導入済みのインテグレーション由来です。100 を超えるインテグレーションがイベント収集に対応しており、Kubernetes / Docker / Jenkins / Amazon ECS などが代表例です (2026 年 9 月時点・出典: Event Management)。3 つ目は自分で送るもので、デプロイや設定変更、変更要求、他社ツールから届いたアラートを取り込めます。
- 発生源 (モニターの状態変化 / インテグレーション / 自分で送る出来事)
- 取り込み
- パイプラインとプロセッサで属性を整える
- 探す (Events Explorer) / 鳴らす (モニター) / 重ねる (ダッシュボード)
整える工程が挟まっているのは、出どころごとに形の違う記録を、後から同じ条件で検索できる状態へ揃えるためです。
変更の直後に壊れたことを目で見る
イベントが最も力を発揮するのは、変更の履歴として使うときです。デプロイのたびにイベントを送っておけば、ダッシュボードのグラフにそのしるしを重ねて表示できます。エラー率が上がった線の真下にリリースの点が立っていれば、原因の候補は一気に絞られます。逆に点が無い時間帯で壊れたのなら、自分たちの変更ではなく外側の要因を疑う番だと分かります。これが無いと、障害のたびに変更履歴を別の場所から掘り出し、時刻を手で突き合わせる作業が発生します。イベントは、その突き合わせを最初から監視画面の中で終わらせるための仕掛けです。
イベントを条件にアラートを出せる
取り込んだイベントは、眺めるだけでなく通知の材料にもなります。モニター にはイベントを検索条件にする種類があり、指定した条件に合うイベントが一定時間内に何件出たかで アラート を鳴らせます。コンテナが強制終了された、設定の反映に失敗した、といった数値では表しにくい出来事の見張りに向いた形です。イベントどうしの関連づけによって通知をまとめる仕組みも用意されており、これは鳴る回数を減らして人が読める量に収めるための機能です。
割当と課金はホスト数で決まる
自分で送るカスタムイベントには割当があります。Pro プランではインフラ監視の対象ホスト 1 台あたり 500 個、Enterprise プランでは 1000 個までが含まれます。超えた分は 10 万件あたり 2 ドル (年間契約) から 3 ドル (オンデマンド) で課金されます (2026 年 8 月時点・出典: Datadog Pricing)。本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。この割当はアカウント全体で平均して数えられるため、1 台ずつ厳密に区切られるわけではありません。実務で効いてくるのは、それでも総量がホスト数に比例して決まるという性質です。台数の少ない構成のまま 1 リクエストごとにイベントを送る設計にすると、上限へ早々に届きます。送る対象は後から名指しで探したい出来事に絞り、細かい発生回数は数値として数えるのが基本の切り分けです。探すときの軸になる環境名やサービス名は、タグ として付けておきます。
ログで代わりにできるのか
同じことをログでできないか、という疑問はよく出ます。デプロイの記録を ログ管理 へ流しても、検索そのものは成り立ちます。違いは扱いの軽さと寿命です。ログはインデックスに入れた分だけ保持期間と費用がかかり、1 日に何百万行と流れる中では 1 行の変更記録が埋もれます。イベントはホスト 1 台あたり 500 個という割当の桁が示すとおり件数を絞って使う前提で、グラフへの重ね合わせや状態変化の追跡といった専用の扱いを受けられます。判断の目安は、その 1 件を半年後に「あの日の変更」として名指しで探すかどうかです。探すならイベント、束にして傾向だけ見るならログに置いておけば足ります。