モニターを構成する

ドキュメント > モニター > モニターを構成する

概要

モニターの構成を開始するには、以下を完了します。

Define the search query: イベントのカウント、メトリクスの測定、1 つまたは複数のディメンションによるグループ化などを行うクエリを作成します。
Set alert conditions: アラートと警告のしきい値、評価タイムフレームを定義し、高度なアラートオプションを構成します。
Configure notifications and automations: 変数を使用してカスタム通知のタイトルとメッセージを記述します。通知をチームに送信する方法を選択します (メール、Slack、PagerDuty など)。アラート通知にワークフローの自動化やケースを含めます。
Define permissions and audit notifications: きめ細かいアクセス制御を構成し、モニターを編集できる特定のロールとユーザーを指定します。モニターが変更された場合にアラートで通知するために、監査通知を有効にします。

検索クエリを定義する

検索クエリの作成方法については、各モニターの種類のページを参照してください。

グラフをプレビューする

クエリを作成または変更すると、構成の上部にあるプレビューグラフが、リアルタイムで結果を反映するために動的に更新されます。

Evaluated Data グラフには、現在のクエリとしきい値を使用して、モニターがデータをどのように評価したかが示されます。Evaluated Data では、次のことを行えます。

過去の状態遷移を確認します (例: OK → ALERT)。
モニターがどのように動作したかを理解します。
(通知ルールからのものも含め) 誰に通知されるかをプレビューします。
保存する前に、誤構成を迅速に見つけます。

この機能は、メトリクス、ログ、APM、RUM、イベント、監査、データベース、Agent Observability、デプロイモニターで利用できます。

Source Data グラフには、しきい値評価やアラートロジックが適用されていない、モニターの生の時系列データやクエリ出力が表示されます。これにより、次のことが可能になります。

モニターの評価対象である基盤データを視覚化します。
アラート状態の変化を実際のデータの傾向と関連付けます。
アラート条件を設定する前に、データ内の異常、ギャップ、または予期しないパターンを特定します。

Source Data グラフを使用して、クエリが期待どおりの結果を返していることを確認し、アラートのしきい値や評価ウィンドウの調整に役立てます。

アラート条件を設定する

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

メトリクスの average、max、min、または sum が、しきい値の * above、above or equal to、below、または below or equal to であった場合にトリガーし、
過去 5 minutes、15 minutes、1 hour、または custom に 1 分～48 時間 (メトリクスモニターに対して 1 か月) の値を設定します

集計方法

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

オプション	説明
average	系列の平均値を計算して、しきい値との比較でチェックする単一の値を生成します。モニタークエリに `avg()` 関数を追加します。
max	生成された系列内のいずれか 1 つの値でもしきい値を超えた場合に、アラートがトリガーされます。モニタークエリに `max()` 関数を追加します。*
min	クエリの評価ウィンドウ内のすべてのポイントがしきい値を超えた場合に、アラートがトリガーされます。モニタークエリに `min()` 関数を追加します。*
sum	系列内のすべてのポイントの合計値がしきい値を超えた場合に、アラートがトリガーされます。モニタークエリに `sum()` 関数を追加します。

* 最大および最小の説明は、メトリクスがしきい値を_超えた_場合にモニターがアラートを出すことを前提としています。しきい値を_下回った_場合にアラートを出すモニターの場合は、最大と最小の動作が逆になります。

各集計方法の仕組みの内訳と例については、モニターの集計方法ガイドを参照してください。

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

評価ウィンドウ

モニターは、累積タイムウィンドウまたはローリングタイムウィンドウを使用して評価することができます。累積タイムウィンドウは、“この時点までに使用可能なすべてのデータの合計を教えてください”のような、過去のコンテキストが必要な質問に最適です。ローリングタイムウィンドウは、“最後の N 個のデータポイントの平均を教えてください”のような、このコンテキストを必要としない質問に回答する上で最適です。

下図は、累積タイムウィンドウとローリングタイムウィンドウの違いを示しています。

ローリングタイムウィンドウ

ローリングタイムウィンドウはサイズが固定されており、時間の経過と共に開始点を移動させます。モニターは、過去 5 minutes、15 minutes、1 hour、または最大 1 か月のカスタムタイムウィンドウを遡って確認できます。

注: ログモニターでは、最大 2 days のローリングタイムウィンドウを設定できます。

累積タイムウィンドウ

累積タイムウィンドウでは開始点が固定されており、時間の経過と共に拡大します。モニターは、3 つの異なる累積タイムウィンドウをサポートしています。

Current hour: 開始時間として 1 時間の中の分を設定できる、最大 1 時間のタイムウィンドウ。たとえば、0 分から 1 時間の間に HTTP エンドポイントが受信する呼び出しの数をモニターします。
Current day: 開始時間として 1 日の中の時間と分を設定できる、最大 24 時間のタイムウィンドウ。たとえば、Current day タイムウィンドウを使用し、開始時間として 2:00pm UTC を指定して、日別のログインデックスの割り当てをモニターします。
Current month: 設定可能な 1 か月の中の日と設定可能な時間および分から、今月を遡って確認します。このオプションは月初から現在までのタイムウィンドウを表し、メトリクスモニターでのみ利用可能です。

累積タイムウィンドウは、最大時間スパンに達するとリセットされます。たとえば、Current month を確認する累積タイムウィンドウは、毎月 1 日の午前 0 時 (UTC) にリセットされます。30 分から開始する Current hour の累積タイムウィンドウは、毎時間リセットされます。たとえば、午前 6 時 30 分、午前 7 時 30 分、午前 8 時 30 分です。

評価頻度

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

デフォルトでは、評価頻度は使用される評価ウィンドウによって決まります。ウィンドウが長くなるほど、評価頻度は低くなります。以下の表は、時間ウィンドウが大きくなると、評価頻度がどのように変わるかを示しています。

評価ウィンドウ範囲	評価頻度
ウィンドウが 24 時間未満	1 分
ウィンドウが 24 時間以上 48 時間未満	10 分
ウィンドウが 48 時間以上	30 分

評価頻度は、モニターのアラート条件が日次、週次、または月次でチェックされるように構成することもできます。この構成では、評価頻度は評価ウィンドウではなく、構成されたスケジュールに従って決定されるようになります。

詳しくは、モニター評価頻度のカスタマイズ方法のガイドをご覧ください。

しきい値

しきい値を使用して、アラートをトリガーするための数値を設定します。エディターには、選択したメトリクスに応じて使用される単位が表示されます (byte、kibibyte、gibibyte など)。

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

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

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

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

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

何回連続して失敗したらアラートをトリガーするか、回数 <NUMBER> を選択します。
チェックを実行するたびに、OK、WARN、または CRITICAL の 1 つのステータスが送信されます。WARN および CRITICAL ステータスが何回連続して送信されたら通知をトリガーするかを選択します。たとえば、プロセスで接続が失敗する原因となるブリップが 1 回発生したとします。この値を > 1 に設定すると、ブリップは無視されますが、連続して 2 回以上失敗する問題が発生すると、通知がトリガーされます。
何回連続して成功したらアラートを解決するか、回数 <NUMBER> を選択します。
何回連続して OK ステータスが送信されたらアラートを解決するか、回数を選択します。

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

高度なアラート条件

データなし

欠落データに関する通知は、通常の状況下ではメトリクスによって常にデータが報告されると想定される場合に役立ちます。たとえば、Agent を使用するホストが常に稼働している必要がある場合、system.cpu.idle メトリクスは常にデータを報告すると想定することができます。

この場合、欠落データに関する通知を有効にする必要があります。以下のセクションでは、各オプションを使用してこれを実現する方法を説明します。

注: モニターは、欠落データに対してアラートを出す前にデータを評価できる必要があります。たとえば、service:abc のモニターを作成し、その service からのデータが報告されない場合、モニターはアラートを送信しません。

N 分のデータが欠落している場合、ドロップダウンメニューからオプションを選択します。

Evaluate as zero / Show last known status
Show NO DATA
Show NO DATA and notify
Show OK。

モニターのクエリからデータが返されない場合、選択された動作が適用されます。Do not notify オプションとは対照的に、欠落データウィンドウは構成可能ではありません。

オプション	モニターステータスと通知
Evaluate as zero	空の結果はゼロに置き換えられ、アラート/警告のしきい値と比較されます。たとえば、アラートしきい値が `> 10` に設定されている場合、ゼロはその条件をトリガーせず、モニターステータスは `OK` に設定されます。
Show last known status	グループまたはモニターの最後の既知のステータスが設定されます。
Show NO DATA	モニターステータスが `NO DATA` に設定されます。
Show NO DATA and notify	モニターステータスが `NO DATA` に設定され、通知が送信されます。
Show OK	モニターが解決され、ステータスが `OK` に設定されます。

クエリで default_zero() を使用すると、欠落データ動作はそのクエリタイプのデフォルトに固定され、他のオプションは無効になります。

default_zero() を含むクエリの場合、欠落データは常にゼロとして評価され、他の欠落データ動作は使用できません。
default_zero() を含まないクエリの場合、Count クエリはデフォルトで Evaluate as zero になり、他のクエリタイプはデフォルトで Show last known status になります。すべての欠落データ動作が引き続き使用可能です。

自動解決

[Never]、After 1 hour、After 2 hours など。トリガーされた状態からこのイベントを自動的に解決します。

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

定期的に報告されるメトリクスについては、トリガーされたアラートが特定の期間後に自動解決されるように設定したほうが適切な場合があります。たとえば、エラーがログに記録されたときにのみ報告されるカウンターの場合、メトリクスがエラーの数として 0 を報告することがないため、アラートが解決されることはありません。その場合は、メトリクスが一定の期間非アクティブであった場合にアラートを解決するように設定します。注: モニターが自動解決され、次回の評価時にクエリの値が回復しきい値を満たさない場合、モニターは再度アラートをトリガーします。

ほとんどの場合、この設定は役に立ちません。これは、アラートが実際に修復された後でのみ、アラートを解決する必要があるためです。したがって、通常はこれを [Never] のままにして、メトリクスが設定されたしきい値を超えたか、下回った場合にのみ、アラートが解決されるようにするのが適切です。

グループ保持時間

グループ保持は、データの報告が停止した後、モニターグループがモニターのステータスをどれくらいの時間保持するかを制御します。保持期間が経過すると、グループは期限切れとなり、モニターのステータスから削除されます。

デフォルトでは、グループは 24 時間ステータスを保持してから削除されます。データ欠落時に通知するホストモニターおよびサービスチェックは、ステータスを 48 時間保持します。

カスタム保持をサポートするマルチアラートモニタータイプの場合、1 時間から 72 時間の間の値を設定できます。Remove the non-reporting group after N (length of time) を選択します。

自動解決オプションと同様に、グループ保持はデータが送信されなくなった場合に動作します。グループ保持と自動解決オプションの開始時間は同じで、モニターのクエリがデータを返さなくなった時点です。

カスタムグループ保持時間を定義するユースケースとしては、以下のようなものがあります。

データの報告が停止した直後にグループを削除する場合
トラブルシューティングに通常かかる時間と同じだけ、グループのステータスを維持する場合

注: カスタムグループ保持時間オプションには、On missing data オプションをサポートするマルチアラートモニターが必要です。これらのモニタータイプは、APM トレース分析、監査ログ、CI パイプライン、Error Tracking、イベント、ログ、および RUM モニターです。

プレビュー: 動的グループ保持

動的グループ保持はプレビュー版であり、新しく作成されたモニターに適用されます。グループ数が多いモニターの場合、Datadog は、データが報告されなくなった後にグループが保持される時間を自動的に短縮します。グループの出現と消失が頻繁になるほどこの期間は短くなり、モニターの高速性と効率性が維持されます。これは、報告が停止したグループにのみ影響します。データをアクティブに報告しているグループが削除されることはありません。

新しいグループ遅延

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

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

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

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

評価遅延

Datadog では、サービスプロバイダーによってバックフィルされるクラウドメトリクスには遅延を 15 分に設定することをお勧めしています。また、除算の計算式を使用する場合は、モニターが完全な値を評価できるよう、60 秒の遅延を設定すると役に立ちます。遅延時間の見積もりについては、クラウドメトリクスの遅延ページを参照してください。

評価を N 秒遅らせます。

評価を遅らせる時間 (秒単位)。これは負でない整数でなければなりません。たとえば、遅延を 900 秒 (15 分) に、モニターが評価を行う期間を直前の 5 minutes に、時刻を 7:00 に設定すると、モニターは 6:40 から 6:45 までのデータを評価します。構成可能な評価遅延の最大値は 86400 秒 (24 時間) です。

通知と自動化を構成する

通知メッセージを構成して、最も関心のある情報を含めることができます。アラートを送信するチームと、アラートをトリガーする属性を指定します。

メッセージ

このセクションを使用して、チームへの通知を構成し、これらのアラートを送信する方法を構成します。

通知メッセージの構成オプションの詳細については、アラート通知を参照してください。

メタデータを追加する

モニターのタグは、Agent やインテグレーションによって送信されるタグとは独立しています。モニターの管理のドキュメントを参照してください。

Tags ドロップダウンを使用して、モニターにタグを関連付けます。
Teams ドロップダウンを使用して、チームをモニターに関連付けます。
Priority を選択します。

アラートの集約を設定する

アラートは、クエリに対して選択された集約に基づいて自動的にグループ化されます (例: avg by service)。クエリでグループ化が指定されていない場合、デフォルトで Simple Alert に設定されます。クエリが任意のディメンションでグループ化されている場合、グループは Multi Alert に変更されます。

シンプルアラート

Simple Alert モードでは、すべての報告元ソースを集計して通知をトリガーします。集計値が設定条件を満たすと、アラートを 1 件受信します。たとえば、すべてのサーバーの平均 CPU 使用率が特定のしきい値を超えた場合に通知するようにモニターを設定することができます。そのしきい値に達した場合、しきい値に達した個々のサーバーの数に関係なく、1 件の通知を受信します。これは、広範なシステムの傾向や動作をモニターする上で役立ちます。

マルチアラート

Multi Alert モニターは、アラートしきい値に達したモニター内の各エンティティに対して個別の通知をトリガーします。

たとえば、サービスごとに集計される P99 レイテンシーが特定のしきい値を超えた場合に通知するようにモニターを設定した場合、P99 レイテンシーがアラートしきい値を超えた個々のサービスごとに別のアラートを受信します。これは、システムまたはアプリケーションの個別の問題を特定して対処する場合に役立ちます。こうすることで、よりきめ細かいレベルで問題を追跡できます。

通知のグループ化

大規模なエンティティグループをモニターする場合、マルチアラートではモニターのノイズが増える可能性があります。これを軽減するために、アラートをトリガーするディメンションをカスタマイズします。これによりノイズが減少し、最も重要なアラートに注目することができます。たとえば、すべてのホストの平均 CPU 使用率をモニターするとします。service および host でクエリをグループ化するが、しきい値に達した service 属性ごとに一度だけアラートを送信する場合は、マルチアラートオプションから host 属性を削除し、送信される通知の数を減らします。

Multi Alert モードで通知を集計する場合、集計されないディメンションは UI で Sub Groups になります。

注: メトリクスが service タグが指定されていない host でのみ報告される場合、そのメトリクスはモニターで検出されません。host および service タグが指定されたメトリクスは、モニターによって検出されます。

クエリでタグまたはディメンションを構成した場合、これらの値はマルチアラートで評価されるすべてのグループで利用でき、有用なコンテキストで動的に通知を埋めることができます。通知メッセージでタグの値を参照する方法については、属性変数とタグ変数を参照してください。

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

権限

すべてのユーザーは、関連付けられているチームやロールに関係なく、すべてのモニターを表示できます。デフォルトでは、モニターの書き込み権限を持つロールが付与されているユーザーのみがモニターを編集できます。Datadog Admin ロールおよび Datadog 標準ロールには、デフォルトでモニターの書き込み権限が付与されています。組織がカスタムロールを使用している場合は、ほかのカスタムロールがモニターの書き込み権限を持つ場合があります。モニターの RBAC 設定や、モニターを固定設定からロール制限の使用へ移行する方法について詳しくは、モニターに RBAC を設定する方法に関するガイドを参照してください。

モニターを編集できるチーム、ロール、またはユーザーのリストを指定することで、モニターをさらに細かく制限できます。モニターの作成者はデフォルトで、モニターに対する編集権を持っています。編集には、モニターのコンフィギュレーションの更新、モニターの削除、モニターのミュート (時間の長短を問わず) などが含まれます。

注: 制限は UI と API の両方に適用されます。