複合条件モニター

概要

複合条件モニターは、個別モニターを組み合わせて 1 つのモニターにし、さらに詳細なアラート条件を定義します。

既存のモニターを選択して、複合条件モニターを作成します。たとえば、モニター A とモニター B とします。次に、A && B などのブール演算子を使用してトリガー条件を設定します。複合条件モニターは、個別モニターが同時に複合条件モニターのトリガー条件を真にする値を持つときにトリガーします。

構成の目的上、複合条件モニターは構成モニターに依存しません。複合条件モニターの通知ポリシーは、構成モニターのポリシーに影響することなく変更できます。その逆も同様です。さらに、複合条件モニターを削除しても、構成モニターは削除されません。複合条件モニターは他のモニターを所有せずに、その結果を使用するだけです。複数の複合条件モニターが同じ個別モニターを参照することもあります。

注

個別モニター、構成モニター、非複合条件モニター という用語はすべて、複合条件モニターがそのステータスを計算するために使用するモニターを指します。
複合条件結果には、共通のグループ化が必要です。共通のグループ化がないモニターを選択した場合、式で選択したモニターが複合条件結果にならない場合があります。
複合条件モニターは、他の複合条件モニターに基づくことはできません。

モニターの作成

Datadog で複合条件モニターを作成するには、メインナビゲーションを使用して次のように移動します: Monitors –> New Monitor –> Composite。

モニターの選択とトリガー条件の設定

モニターの選択

複合条件モニターで使用する個別モニターを最大 10 個まで選択できます。異なるアラートタイプのモニターでもかまいません (シンプルアラートのみ、マルチアラートのみ、または両方の組み合わせ)。複合条件モニターを個別モニターとして使用することはできません。最初のモニターを選択すると、UI にそのアラートタイプと現在のステータスが表示されます。

マルチアラートモニターを選択すると、UI にはモニターの group-by 節と、現在レポートされている一意のソースの数が表示されます (例: Returns 5 host groups)。マルチアラートモニターを組み合わせる場合、この情報は自然にペアになるモニターを選択するのに役立ちます。

同じグループを持つモニターを選択する必要があります。そうしなかった場合、UI には、このような複合条件モニターは決してトリガーしない旨の警告が表示されます。

同じグループのマルチアラートモニターを選択した場合でも、モニターに共通のレポートソース (共通のグループ化とも呼ばれる) がない場合、Group Matching Error が表示されることがあります。共通のレポートソースがない場合、Datadog は複合条件モニターのステータスを計算できず、トリガーしません。ただし、警告を無視して、とにかくモニターを作成することは_可能_です。詳細については、複合条件モニターが共通の報告元ソースを選択する方法を参照してください。

警告が表示されないように 2 つ目のモニターを選択すると、Trigger when フィールドにデフォルトのトリガー条件 a && b が挿入され、提案された複合条件モニターのステータスが表示されます。

トリガー条件を設定する

Trigger when フィールドに、ブール演算子を使用して目的のトリガー条件を記述します。個別モニターは、フォーム内のラベル (a、b、c など) で識別されます。括弧を使用して演算子の優先度を制御すると、複雑な条件を作成できます。

以下はどれも有効なトリガー条件です。

!(a && b)
a || b && !c
(a || b) && (c || d)

高度なアラート条件

No Data

複合条件モニターがデータなしの状態にあることを Do not notify（通知しない）か Notify（通知する）かを選択します。ここでどちらを選択しても、個別モニターの Notify no data 設定には影響しませんが、複合条件がデータなしでアラートを出すためには、個別モニターと複合モニターの両方をデータが欠落していることを Notify（通知する）に設定する必要があります。

その他のオプション

高度なアラートオプション (自動解決など) の詳細な手順については、モニターコンフィギュレーションページを参照してください。

通知

For instructions on using template variables from a composite monitor’s constituent monitors in your notifications, see composite monitor variables. For detailed instructions on the Configure notifications and automations section, see the Notifications page.

API

API を使用している場合、複合条件モニターのクエリはモニター ID を使用しているサブモニターについて定義されます。

たとえば、2 つの非複合条件モニターに次のクエリと ID があるとします。

"avg(last_1m):avg:system.mem.free{role:database} < 2147483648" # Monitor ID: 1234
"avg(last_1m):avg:system.cpu.system{role:database} > 50" # Monitor ID: 5678

上記のモニターを組み合わせた複合条件モニターのクエリは、"1234 && 5678" や "!1234 || 5678" などになります。

複合条件モニターの仕組み

このセクションでは、いくつかのサンプルを使用してトリガー条件が計算される方法と、さまざまなシナリオで受け取るアラートの数について説明します。

トリガー条件の計算

複合条件モニターには 4 種類のステータスがあり、そのうち 3 種類はアラート対象です。

ステータス	アラート対象	重大度
`Alert`	真	4 (最も重大)
`Warn`	真	3
`No Data`	真	2
`Ok`	偽	1 (最も重大ではない)

使用されているブール演算子 (&&、||、!) は、複合条件モニターステータスのアラート対象を操作するものです。

A && B がアラート対象である場合、結果は A と B 間の最も重大ではないステータスとなります。
A || B がアラート対象である場合、結果は A と B 間の最も重大なステータスとなります。　
A が No Data の場合、!A は No Data
A がアラート対象の場合、!A は OK　
A がアラート対象でない場合、!A は Alert

2 つの個別モニター（A および B）を考えます。次の表は、トリガー条件 (&& または ||) を与えられた複合条件モニター、および個別モニターにさまざまなステータスが与えられた場合の複合条件モニターの結果ステータスです。アラート対象かどうかは、T または F で示されます。

モニター A	モニター B	条件	通知データなし	複合条件ステータス
Alert (T)	Warn (T)	`A && B`		Warn (T)
Alert (T)	Warn (T)	`A \|\| B`		Alert (T)
Alert (T)	Ok (F)	`A && B`		OK (F)
Alert (T)	Ok (F)	`A \|\| B`		Alert (T)
Warn (T)	Ok (F)	`A && B`		OK (F)
Warn (T)	Ok (F)	`A \|\| B`		Warn (T)
データなし (T)	Warn (T)	`A && B`	真	データなし (T)
データなし (T)	Warn (T)	`A \|\| B`	真	Warn (T)
データなし (T)	Warn (T)	`A && B`	偽	最後の既知データ
データなし (T)	Warn (T)	`A \|\| B`	偽	Warn (T)
データなし (T)	OK (F)	`A && B`	偽	OK (F)
データなし (T)	OK (F)	`A \|\| B`	偽	最後の既知データ
データなし (T)	OK (F)	`A && B`	真	OK (F)
データなし (T)	OK (F)	`A \|\| B`	真	データなし (T)
データなし (T)	データなし (T)	`A && B`	真	データなし (T)
データなし (T)	データなし (T)	`A \|\| B`	真	データなし (T)

注: 複合条件の notify_no_data が false で、サブモニターの評価結果がその複合条件に対して No Data ステータスになった場合、複合条件は代わりに最後の既知の状態を使用します。

複合条件とダウンタイム

複合条件モニターとその個別モニターは互いに独立しています。

複合条件モニターでのダウンタイム

A || Bの条件を持つ 2 つの個別モニターからなる複合条件モニター C を考えてみましょう。複合条件モニターにダウンタイムを作成すると、C からの通知のみが抑制されます。

モニター A または B がそれぞれのモニター構成でサービスやチームに通知する場合、複合条件 C のダウンタイムは A または B によって引き起こされた通知をミュートすることはありません。A または B からの通知をミュートするには、これらのモニターにダウンタイムを設定します。

複合条件モニターで使用している個別モニターでのダウンタイム

複合条件モニター内で使用されている個々のモニター A にダウンタイムを作成しても、複合条件モニターはミュートされません。

例えば、ダウンタイムが発生すると、モニター A、特にそのグループ env:staging はミュートされます。グループ env:staging がアラート対応状態になると、個々のモニターから来る通知は抑制され、複合条件モニターはアラート通知を送信します。

アラートの数

受け取るアラートの数は、個別モニターのアラートタイプによって異なります。すべての個別モニターがシンプルアラートなら、複合条件モニターもシンプルアラートタイプになります。A および B のクエリがすべて同時に true の場合に、複合条件モニターは 1 つの通知をトリガーします。

個別モニターが 1 つでもマルチアラートなら、複合条件モニターもマルチアラートです。同時にいくつのアラートが送信されるかは、複合条件モニターが使用しているマルチアラートモニターが 1 つか複数かに依存します。

共通の報告元ソース

多くのマルチアラートモニターを使用する複合条件モニターでは、個別モニターの共通の報告元ソースのみが考慮されます。

マルチアラートの例

モニター A および B がマルチアラートで、ホスト別にグループ化されているシナリオで考えてみましょう。

host:web01 から host:web05 のホストはモニター A のレポートを作成しています。
host:web04 から host:web09 のホストはモニター B のレポートを作成しています。

複合条件モニターは、共通ソース (web04 と web05) のみを考慮します。1 回の評価サイクルで最大 2 つのアラートを受信できます。

異なるグループ名の共通グループ評価

複合条件モニターはタグ値 (web04) のみを参照し、タグキー (host) は参照しません。上記の例に、単一の報告元ソース service:web04 を持つ service によってグループ化されたマルチアラートモニター C が含まれている場合、複合条件モニターは web04 を A、B、C 間の単一の共通の報告元ソースと見なします。

2 つ以上のディメンションのあるモニターグループ

2 つ以上のタグで分割されたマルチアラートモニターの場合、モニターグループはタグの組み合わせ全体に対応します。たとえば、モニター 1 が device,host に基づくマルチアラートであり、モニター 2 が host に基づくマルチアラートである場合、複合条件モニターはモニター 1 とモニター 2 を組み合わせることができます。