複合モニター
複合モニターとは、既存のモニターの状態を && / || / ! の論理式で組み合わせ、式が真になったときだけ通知する Datadog のモニター種別のこと。部品にしたモニターを所有せず結果だけを使うため、元のモニターの設定と通知はそのまま残る。
概要
複合モニターは、モニター A とモニター B のように選んだ既存のモニターを、a && b のような論理式でつないで 1 つの状態にまとめる Datadog のモニター種別です。部品にできるのは最大 10 個で、複合モニター自身を部品にすることはできません。式は各部品の状態が Alert / Warn / No Data のいずれか、つまり「通知に値する状態か」に対して評価され、複合モニターの状態はその結果から決まります。気にするのは、「CPU が高い、かつエラー率も高いときだけ鳴らしたい」のように、1 つの条件では表せない通知を組みたいときです。
既存のモニターを部品にして、条件式で 1 つにまとめる
複合モニター (Composite Monitor) は、個々のモニターを組み合わせて、より限定した通知条件を定める種別です。モニター A と B を選び、A && B のような論理式を書くと、両方が同時に条件を満たす値になったときに複合モニターが発報します (2026 年 9 月時点・出典: Composite Monitor)。設定の上で複合モニターは部品から独立しています。複合側の通知先を変えても部品の通知先は変わらず、複合モニターを削除しても部品は消えません。複合モニターは部品を所有せず結果だけを使うので、同じ部品を複数の複合モニターから参照できます。既存のアラートを壊さずに条件を重ねられるのが、この種別の性格です。鳴らし方を整える道具立ての全体像はモニターの解説に譲ります。
部品の条件 - 最大 10 個、複合の入れ子は不可
部品にできるモニターは最大 10 個で、シンプルアラートとマルチアラートを混ぜても構いません (2026 年 9 月時点・出典: Composite Monitor)。ただし複合モニターを部品にすることはできず、複合の入れ子は作れません。もう 1 つの条件が、部品同士に共通のグループがあることです。マルチアラートを選ぶと画面にグループ化の句と報告中の系列数が出て、相手選びの手がかりになります。グループが揃わない部品を選ぶと「この複合モニターは決して発報しないかもしれない」という警告が出ます。同じグループでも共通の報告元が無ければ Group Matching Error が表示され、状態が計算できないため発報しません。警告を無視して作成はできるので、警告は「作れない」ではなく「鳴らない」の意味です。
式はラベル a / b と 3 つの演算子で書く
条件式は、部品に振られたラベル a、b、c と、論理積 &&、論理和 ||、否定 ! で書き、括弧で優先順位を制御します (2026 年 9 月時点・出典: Composite Monitor)。公式ドキュメントが有効な例として示すのは !(a && b)、a || b && !c、(a || b) && (c || d) の 3 つです。2 つ目の部品を選ぶと、既定の a && b が入ります。実務でよく組むのは 2 型です。「CPU が高い、かつエラー率も高い」は a && b で、片方だけでは鳴らない通知になります。「依存先の障害中は自分の警報を鳴らさない」は a && !b で、b を依存先のモニターにします。3 つ以上を組むときは括弧で意図を明示しておくと、引き継いだ人が誤読しません。
状態はどう合成されるか
複合モニターの状態は Alert / Warn / No Data / OK の 4 つで、OK 以外の 3 つが「通知に値する」状態です。重さは Alert 4、Warn 3、No Data 2、OK 1 の順です (2026 年 9 月時点・出典: Composite Monitor)。演算子はこの「通知に値するか」に対して働きます。A && B が真なら結果は A と B のうち軽い方の状態、A || B が真なら重い方の状態です。否定は、A が No Data なら No Data のまま、A が通知に値するなら OK、値しないなら Alert になります。No Data で複合モニターに通知させるには、部品と複合の両方で「データ欠損時に通知」を有効にする必要があります。複合側が無効で評価結果が No Data になる場合は、直前の既知の状態が使われます。
| 式と部品の状態 | 複合モニターの状態 |
|---|---|
A && B が真 | A と B のうち軽い方 (例: Alert と Warn なら Warn) |
A || B が真 | A と B のうち重い方 (例: Alert と OK なら Alert) |
A && B で片方が OK | OK (例: Alert と OK なら OK) |
!A で A が No Data | No Data |
!A で A が通知に値する | OK |
!A で A が OK | Alert |
ダウンタイムは複合と部品で別々に効く
複合モニターと部品は互いに独立しているため、ダウンタイムも片方にしか効きません。公式ドキュメントの例は A || B で組んだ複合モニター C です (2026 年 9 月時点・出典: Composite Monitor)。C にダウンタイムを置くと止まるのは C の通知だけで、A や B が自分の通知先を持っていれば、そちらは鳴り続けます。逆に部品 A にダウンタイムを置いても、C はミュートされません。A の env:staging グループをミュートした例では、そのグループが通知に値する状態になると A からの通知は抑えられますが、複合モニターは通知を送ります。「メンテナンス中は一切鳴らさない」には、複合と部品の両方にダウンタイムを置く必要があります。
通知の数は共通の報告元で決まる
届く通知の数は部品のアラート種別で決まります。全ての部品がシンプルアラートなら複合もシンプルアラートで、条件が同時に真になったときに 1 回だけ通知します。部品に 1 つでもマルチアラートがあれば複合もマルチアラートです。複数のマルチアラートを組む場合、評価されるのは部品に共通する報告元だけです (2026 年 9 月時点・出典: Composite Monitor)。公式ドキュメントの例では、A に web01 から web05、B に web04 から web09 が報告していると、複合が見るのは共通の web04 と web05 だけです。1 評価周期に届く通知は最大 2 件です。照合はタグの値だけで行い、キーは見ないため、service:web04 を報告する部品 C を足しても web04 で揃います。グループ化の次元が違う部品は、device,host と host のように包含関係にあれば組めます。