モニターの構成

概要

モニタータイプを選択したら、モニターの構成を開始します。 モニターを保存する前に、次の 4 つの主要手順を完了する必要があります。

  • **検索クエリを定義します。**イベントのカウント、メトリクスの測定、1 つまたは複数のディメンションによるグループ化などを行うクエリを作成します。
  • **アラート条件を設定します。**アラートと警告のしきい値、評価タイムフレームを定義し、高度なアラートオプションを構成します。
  • **何が起こっているかを伝えます。**変数を使用してカスタム通知のタイトルとメッセージを記述します。
  • **チームに通知します。**通知をチームに送信する方法を選択します (メール、Slack、PagerDuty など)

検索クエリを定義する

検索クエリの作成方法については、個々のモニタータイプページを参照してください。検索クエリを定義すると、検索フィールドの上のプレビューグラフが更新されます。

アラートのグループ化

アラートは、クエリを定義する際に group by の手順で選択したグループに応じて自動的にグループ化されます。グループを設定していない場合は、デフォルトで Simple Alert (シンプルアラート) でグループ化されます。クエリがディメンションでグループ化されている場合は、デフォルトで Multi Alert (マルチアラート) でグループ化されます。

Simple Alert モードでは、すべての報告元ソースを集計します。集計値が設定条件を満たすと、アラートを 1 件受信します。

グループパラメーターに従い、Multi Alert モードが各ソースに適用されます。各グループで設定された条件を満たすと、アラートが送信されます。たとえば、容量メトリクスを調べるクエリを host および device でグループ化すると、容量不足のデバイスに対してアラートを個別に送信できます。 メトリクスが device タグを伴わない host のみで報告する場合、モニターグループにより hostdevice の両方で検出されません。複数アラートで評価される各グループには[タグ変数][4]を利用でき、便利なコンテキストで通知を動的に入力します。

グループ化シンプルアラートモードマルチアラートモード
(すべて)1 つの通知をトリガーする 1 つの単一グループN/A
1 つ以上のディメンション1 つ以上のグループがアラート条件を満たす場合の 1 つの通知アラート条件を満たすグループごとに 1 つの通知

アラートの条件を設定する

アラート条件は、モニタータイプによって異なります。クエリ値がしきい値を超えた場合、または特定の数の連続したチェックが失敗した場合にトリガーするようにモニターを構成します。

  • メトリクスが aboveabove or equal tobelowbelow or equal to の場合にトリガーされる
  • しきい値は、on averageat least onceat all times あるいは in total
  • 過去 5 minutes15 minutes1 hour など、または custom に 1 分~48 時間 (メトリクスモニターに対して 1 か月) の値を設定します。

集計の方法

クエリは一連のポイントを返しますが、しきい値と比較するには単一の値が必要です。モニターは、評価ウィンドウのデータを単一の値に減らす必要があります。

オプション説明
on average系列の平均値が算出され、単一の値が生成されます。この値がしきい値と比較されます。このオプションは、モニタークエリに avg() 関数を追加します。
at least once生成された系列内の値がいずれか 1 つでもしきい値から外れている場合に、アラートがトリガーされます。このオプションは、比較方法の選択に基づいて、モニタークエリに関数を追加します。below を選択した場合は min()、above を選択した場合は max() が追加されます。
at all timesクエリの評価ウィンドウ内のすべてのポイントがしきい値から外れている場合に、アラートがトリガーされます。このオプションは、比較方法の選択に基づいて、モニタークエリに関数を追加します。above を選択した場合は min()、below を選択した場合は max() が追加されます。
in total系列内のすべてのポイントの合計値がしきい値から外れている場合に、アラートがトリガーされます。このオプションは、モニタークエリに sum() 関数を追加します。

: as_count() を使用する場合は動作が異なります。詳しくは、モニター評価での as_count() を参照してください。

評価ウィンドウ

モニターは、過去 5 minutes15 minutes1 hour などを振り返って、特定の頻度で評価されます。

評価頻度

評価頻度は、Datadog がモニタークエリを実行する頻度を定義します。ほとんどの構成では、評価頻度は 1 minute で、これは 1 分ごとにモニターが選択したデータ選択した評価ウィンドウにクエリして、定義したしきい値と集計値を比較することを意味します。

しきい値

しきい値には、アラートをトリガーする数値を設定します。メトリクスに何を選ぶかによって、エディターに表示される単位 (bytekibibytegibibyte など) が変わります。

Datadog には、アラートと警告の 2 種類の通知があります。モニターのリカバリはアラートや警告のしきい値に基づいて自動的に行われますが、条件を追加することもできます。リカバリのしきい値について詳しくは、リカバリのしきい値とはを参照してください。たとえば、メトリクスが 3 を超えたときにモニターがアラートを出し、回復しきい値が指定されていない場合、メトリクス値が 3 を下回るとモニターは回復します。

オプション説明
アラートしきい値 (必須)アラートの通知のトリガーに使用される値
警告しきい値警告の通知のトリガーに使用される値
アラート回復しきい値アラートのリカバリに対する追加条件を示すしきい値 (任意)
警告回復しきい値警告のリカバリに対する追加条件を示すしきい値 (任意)

しきい値を変更すると、エディター内でプレビューグラフにカットオフポイントを示すマーカーが表示されます。

しきい値プレビューグラフ

メモ: しきい値を小数で入力する際、値が <1 の場合は先頭に 0 を付けます。たとえば、.5 ではなく 0.5 としてください。

チェックアラートは、各チェックグループにつき、送信されたステータスを連続的にトラックし、しきい値と比較します。チェックアラートを次のように設定します。

  1. 何回連続して失敗したらアラートをトリガーするか、回数 <数値> を選択します。

    各チェックは OKWARNCRITICAL のいずれか 1 つのステータスを送信します。WARNCRITICAL ステータスが連続して何回送信されたら通知をトリガーするか選択します。たとえば、プロセスで接続に失敗する異常が 1 回発生したとします。値を > 1 に設定した場合、この異常は無視されますが、2 回以上連続で失敗した場合は通知をトリガーします。

しきい値アラート/警告のチェック
  1. 何回連続して成功したらアラートを解決するか、回数 <数値> を選択します。

    何回連続して OK ステータスが送信されたらアラートを解決するか、回数を選択します。

しきい値回復のチェック

チェックアラートの構成の詳細については、プロセスチェックインテグレーションチェックカスタムチェックモニターのドキュメントを参照してください。

高度なアラート条件

No Data

データなしを通知しない場合は Do not notify を、データなしが N 分以上続いた時に通知する場合は Notify を設定します。

正常な状態で、メトリクスが常にデータを報告するようにするには、「データなし」通知を利用すると便利です。たとえば、Agent を使用しているホストが継続的に稼働している必要がある場合、system.cpu.idle メトリクスがデータを常に報告することが期待されます。このような場合は、「データなし」を通知するように設定します。

: 「データなし」ウィンドウは、評価期間中に最低 2 回設定することを推奨します。

また、オートスケーリングが有効であり、起動と停止が自動で行われるホストグループに対してメトリクスをモニターする場合にこの設定を有効にすると、通知が数多く生成されるので、データなしの通知を有効にするべきではありません。データが長期間にわたって報告されていない場合、このオプションは有効であっても機能しません。

グループ化

「データなし」を通知しないモニターの場合、グループがデータを報告しないとモニターは評価をスキップし、最終的にグループをドロップします。この期間、結果ページのバーは緑のままです。データがありグループが報告を再開すると、グリーンバーには OK ステータスとバックフィルが表示され、中断がなかったかのように見せます。

Auto resolve

アラートをトリガーされた状態から解決するタイミングを、[Never]After 1 hourAfter 2 hours などで指定します。

自動解決は、データが送信されなくなったときに機能します。データがまだ報告されている場合、モニターは、ALERT または WARN 状態から自動解決されません。データがまだ送信されている場合は、再通知機能を利用して、問題が解決されていないことをチームに知らせることができます。

メトリクスが定期的に報告を行う場合に、トリガーされたアラートを一定の期間の後に自動で解決したいことがあります。たとえば、エラーのログだけを報告するカウンターがある場合、エラーの数が 0 であれば報告が行われないため、アラートがいつまでも解決しません。このような場合、メトリクスからの報告がないまま一定の期間が経過したらアラートを解決するように設定できます。: モニターがアラートを自動で解決し、次回の評価でクエリーの値がリカバリのしきい値を満たしていない場合、モニターはもう一度アラートをトリガーします。

ほとんどの場合、アラートは問題が実際に修正されてから解決する必要があるため、この設定は不要です。つまり、通常はこれを [Never] にしておいて、メトリクスが設定されたしきい値を上回る (または下回る) 場合にだけアラートを解決するようにしてください。

新しいグループ遅延

新しいグループの評価開始を N 秒遅らせます。

アラートを開始する前に待機する時間 (秒単位)。新しく作成されたグループが起動し、アプリケーションが完全に起動できるようにします。これは負でない整数である必要があります。

たとえば、コンテナ化されたアーキテクチャを使用している場合、グループ遅延を設定すると、新しいコンテナが作成されたときのリソース使用量や待ち時間が長いために、コンテナを対象とするモニターグループがトリガーされなくなります。遅延はすべての新しいグループ (過去 24 時間に表示されていない) に適用され、デフォルトは 60 秒です。

このオプションは、マルチアラートモードで使用できます。

Evaluation Delay

評価を N 秒遅らせます。

評価を遅らせる時間 (秒単位)。負以外の整数を指定してください。たとえば、遅延を 900 秒 (15 分) に、モニターが評価を行う期間を直前の 5 minutes に、時刻を 7:00 に設定すると、モニターは 6:40 から 6:45 までのデータを評価します。

: サービスプロバイダーがバックフィルを行うクラウドメトリクスには、遅延を 15 分に設定することをお勧めします。また、除算の計算式を使用する場合は、モニターが完全な値を評価できるよう、60 秒の遅延を設定すると役に立ちます。