Event Management
Event Management は、モニターや外部ツールから届くイベントを取り込み、整え、相関させて 1 つの作業項目に束ねる機能です。20 件の通知を 1 件にまとめ、Triage Inbox で選別してから人へ渡します。
何ができるか
モニター、Watchdog、Error Tracking が自動で作るイベントと、Agent や 100 を超えるインテグレーション、任意の出所から届くイベントを 1 か所に集めます。パイプラインでタグを整え、パターン相関と機械学習の相関で関連するアラートを 1 つの作業項目に束ね、Triage Inbox で状態と優先度を付けて通知します。
どのような場面で使うか
「同じ障害で 20 通の通知が別々に届き、誰が何を見ているのか分からない」状態を解くときに使います。サービスと環境のタグで束ねる、デプロイや設定変更のイベントを関連情報として添える、束ねた 1 件だけを Slack や PagerDuty へ通知する、といった使い方です。
身近な例え
新聞社の整理部です。各記者から届く原稿 (イベント) の山から同じ事件の原稿を束ね、見出しを付け、1 本の記事として紙面 (作業項目) に載せます。1 つの事件が 20 本のばらばらな記事として紙面を埋めるのを防ぐ役割です。
結論 - イベント 1 件の話ではなく、束ねて通知を減らす仕組み
Event Management は、あらゆる出所からのイベントを取り込み、正規化し、相関させる機能です。出所は Datadog 製品の自動生成、Agent とインテグレーション、第三者のアラートや変更要求などの任意の出所の 3 系統です (2026 年 9 月時点・出典: Event Management)。3 系統の内訳と、イベント 1 件の定義と割当や課金はイベントの用語解説に譲り、本記事は「束ねる」側を扱います。構成要素は取り込み、Triage Inbox、パイプラインとプロセッサー、Events Explorer、相関の 5 つです。無いと、1 つの障害で 20 本のモニターが鳴れば 20 通が別々の人へ届き、全員が同じ原因を別々に調べます。あると 20 通は 1 つの作業項目になり、通知も 1 件です。
取り込みの入口は標準イベントと任意の出所
入口は 2 系統です。1 つは標準イベントで、追加設定なしに Agent と導入済みインテグレーションが集めたイベントが自動で入ってきます。もう 1 つは任意の出所からの取り込みで、第三者のアラートや変更要求などのイベントを送り込めます (2026 年 9 月時点・出典: Event Management)。相関の前提になるのが重複排除で、イベントはまず集約キー (aggregation key) に基づいてアラートへ重複排除され、その後に設定に従って作業項目へ相関されます。集約キーを持たないイベントは、時間枠の中で 1 つのアラートに重複排除されます (出典: Pattern-based Correlation)。同じモニターが揺れて 5 分に 1 回イベントを出しても、集約キーが同じなら 1 つのアラートとして数えられる、という段が相関の手前にあります。
| 出所 | 集約キー | 相関の手前で起きること |
|---|---|---|
| モニターが自動生成するイベント | モニター ID とモニターグループごとに固有のキーが付く | 同じモニターの揺れは同じキーで 1 つのアラートに重複排除される |
| Agent とインテグレーションの標準イベント | 送信元のキーを使うか、パイプラインの Aggregation Key プロセッサーで付けられる | キーがあればキー単位、無ければ時間枠の中で 1 つのアラートになる |
| 任意の出所からの取り込み | 送信時に付ける | 重複排除の後、設定に従って作業項目へ相関される |
パイプラインとプロセッサーでタグを揃える
相関はタグで束ねるため、出所ごとに表記が違うと束になりません。そこで使うのがパイプラインです。用途は 3 つで、タグやカスタム属性を足してイベントを豊かにする、タグを再マッピングして表記を標準化する、Grok ルールでメッセージや属性を解析して追跡できるタグに変える、です (2026 年 9 月時点・出典: Pipelines and Processors)。仕組みはプロセッサーを順に連ねてイベントを通すもので、届いたイベントは全パイプラインのフィルターと照合され、一致したものが適用されます。フィルターの条件は Events Explorer で作ったクエリをそのまま使えます。Grok パーサーの書き方とタグの設計は各用語解説に譲りますが、実務での順番は「まず外部ツールから来るイベントの service と env を Datadog 側の表記に揃える」が先で、相関ルールはその後です。表記が揃わないまま相関を組むと、例外を相関側で吸収しようとして複雑になります。
相関はパターン型と機械学習型の 2 種類
パターン型は、どう束ねるかを利用者が決める方式で、Datadog は機械学習で関連するモニターイベントを補います。機械学習型は設定なしで Datadog が自動で相関し、対象範囲だけを任意で絞れます (2026 年 9 月時点・出典: Correlation Configuration)。パターンの設定では、イベントソースを選び、除外するイベントをクエリで指定し、変更などの関連イベントを添え、グループ化タグをファセットから選びます。関連イベントは項目に付くだけで新しい項目は作りません。詳細設定では項目を作るのに必要な最小件数と、新しいアラートを同じ項目へ追加し続ける最長時間、状態変化を反映し続ける最長時間を決め、題名は {{tag.service}} のようなテンプレートで組めます。よく使う service と env のタグに基づく推奨パターンが用意され、設定はプレビューで結果を確かめてから保存します (出典: Pattern-based Correlation)。
- イベントが届く (モニター、インテグレーション、第三者ツール)
- 集約キーで重複排除し、アラートにする
- パターン (グループ化タグ + 時間枠 + 最小件数) または機械学習で相関する
- 1 つの作業項目に束ね、関連イベント (デプロイや変更) を添える
- 項目の優先度は束ねたアラートの最高値、状態は全アラート復旧で自動解決
Triage Inbox で束ねた件を選別して渡す
束ねた作業項目を見る場所が Triage Inbox です。左のプロジェクトを選ぶと Open、In Progress、Closed、Archived の既定ビューが並び、詳細調査向きの分割表示と一括確認向きの表表示を切り替え、Priority、Created at、Last Updated で並べ替えて保存できます。カードの上で状態、優先度、担当をそのまま変え、アラート件数に触れると束ねられたアラートを一覧できます (2026 年 9 月時点・出典: Triage Inbox)。相関で作られた項目は、優先度が束ねたアラートの最高値になり、状態はシステムが管理して全アラートの復旧で自動解決、生存時間の枠内で再発すれば自動で再開します。関係ないアラートはチェックして外せ、外したものは再び相関されません (出典: Triage and Notify)。項目そのものの担当や状態の扱いは Work Management の解説と同じです。
| 操作 | 何が起きるか |
|---|---|
| タグ付けとコメント | 項目のタイムラインで同僚を名指しして記録を残す |
| 通知の送信 | Slack、Microsoft Teams、メール、Webhook で関係者へ知らせる |
| エスカレーション | Incident Management でインシデントを起こす、On-Call で当番を呼ぶ、Workflow Automation や外部ツールへ渡す |
| 外部ツールとの同期 | Jira と ServiceNow の記録を同期する |
| 根本原因の印 | 不良な変更などの関連イベントを根本原因として印を付ける |
| 項目の結合と分割 | 関連する項目を 1 つにまとめる、個別調査が要るアラートを切り出す |
通知とチケットは束ねた 1 件に対して出す
効き目は通知の数に出ます。公式ドキュメントは、20 件の通知と調査候補の代わりに 1 つの作業項目と 1 件の通知になると説明しています (2026 年 9 月時点・出典: Triage and Notify)。出し方は 2 つです。1 つはチケットで、プロジェクト設定で ServiceNow と Jira を連携すると手動と自動の起票、双方向同期ができます。もう 1 つはビュー通知で、クエリで項目を絞り込むビューに合う項目が作られたときに通知します。宛先は PagerDuty、メール、Webhook、Microsoft Teams、Slack です。モニターごとの通知設定と違い、単位が「束ねられた項目」になる点が要で、アラートの用語解説にある鳴り続ける通知の整え方はモニター側、ここはモニター横断の話です。当番を On-Call で呼ぶ組織なら、Inbox のエスカレーションとビュー通知から PagerDuty へ送る経路のどちらを正にするかを先に決めると二重の呼び出しを防げます。
モニター側の通知対策とどう分担するか
通知を減らす手段は 3 層に分かれ、Event Management はその真ん中です。1 層目はモニター 1 本の中で、しきい値や評価窓、再通知間隔を整える対策で、同じモニターが揺れて鳴り続ける問題はここで解きます。2 層目がモニター横断で、同じ根本原因で別々のモニターが鳴る問題を service や env で束ねます。3 層目は人の側で、束ねた 1 件を誰が受けるかを On-Call と Work Management で決めます。送り主が 1 本のモニターなら 1 層目、複数のモニターやツールなら 2 層目です。順番も同じで、まずモニター側を整え、それでも同時多発が残るときに相関を組みます。逆にすると、モニターの揺れまで相関で吸収しようとして時間枠や最小件数の調整が終わりません。Explorer で「同じ 10 分に同じサービスで何本鳴ったか」を数えれば、2 層目の要否は実測で判断できます。料金はイベントの用語解説の課金節に譲り、全体は料金の読み解きで扱っています。
注意点
- 本記事は 2026 年 9 月時点の公式ドキュメントの記載に基づいています。相関の設定項目や連携先は変わり得るため、設定時は画面の表示と公式ドキュメントを優先してください。
- Event Management の割当と課金はイベントの用語解説で扱っており、本記事では単価を示していません。契約条件は公開価格表と担当窓口で確認してください。
- 相関で作られた作業項目の状態はシステムが管理し、手動の状態変更は上書きされます (2026 年 9 月時点)。手で閉じたい項目は、束ねられたアラートの復旧を確認してから扱ってください。