- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
モニターの構成を開始するには、以下を完了します。
検索クエリの作成方法については、個々のモニタータイプページを参照してください。検索クエリを定義すると、検索フィールドの上のプレビューグラフが更新されます。
アラート条件は、モニタータイプによって異なります。クエリ値がしきい値を超えた場合、または特定の数の連続したチェックが失敗した場合にトリガーするようにモニターを構成します。
average、max、min、sum がabove、above or equal to、below、below or equal to になったらトリガーします5 minutes、15 minutes、1 hour など、または custom に 1 分～48 時間 (メトリクスモニターに対して 1 か月) の値を設定します。クエリは一連のポイントを返しますが、しきい値と比較するには単一の値が必要です。モニターは、評価ウィンドウのデータを単一の値に減らす必要があります。
| オプション | 説明 |
|---|---|
| 平均 | 系列の平均値が算出され、単一の値が生成されます。この値がしきい値と比較されます。このオプションは、モニタークエリに avg() 関数を追加します。 |
| 最大 | 生成された系列で、どれか一つの値がしきい値を超えたら、アラートがトリガーされます。これは、max() 関数をモニタークエリに追加します。* |
| 最小 | クエリの評価ウィンドウ内のすべてのポイントがしきい値を超えたら、アラートがトリガーされます。これは、min() 関数をモニタークエリに追加します。* |
| 合計 | 系列内のすべてのポイントの合計値がしきい値から外れている場合に、アラートがトリガーされます。このオプションは、モニタークエリに sum() 関数を追加します。 |
* これらの max と min の説明は、メトリクスがしきい値を_超えた_ときにモニターがアラートすることを想定しています。しきい値より_低い_ときにアラートするモニターでは、max と min の動作は逆になります。
注: as_count() を使用する場合は動作が異なります。詳しくは、モニター評価での as_count() を参照してください。
モニターは、累積タイムウィンドウまたはローリングタイムウィンドウを使用して評価することができます。累積タイムウィンドウは、「この時点までのすべてのデータの合計は？」のような歴史的な文脈を必要とする質問に最も適しています。ローリングタイムウィンドウは、「直近の N データポイントの平均は？」のような、このコンテキストを必要としない質問に答えるのに最適な方法です。
下図は、累積タイムウィンドウとローリングタイムウィンドウの違いを示しています。
ローリングタイムウィンドウは、サイズが固定で、時間の経過とともに開始点が移動します。モニターは、5 minutes、15 minutes、1 hour またはカスタムで指定したタイムウィンドウを振り返ることができます。
累積タイムウィンドウは、開始点が固定され、時間の経過とともに拡大します。モニターは 3 つの異なる累積タイムウィンドウをサポートしています。
Current hour: 構成可能な分単位で開始する最大1時間のタイムウィンドウです。例えば、HTTP エンドポイントが 0 分から 1 時間の間に受けたコールの量を監視します。Current day: 構成可能な 1 日の時分から始まる、最大 24 時間のタイムウィンドウです。例えば、1 日のログインデックスクォータを監視するには、current day タイムウィンドウを使い、UTC 2:00pm から開始するようにします。Current month: 当月 1 日午前 0 時 (UTC) を起点に、当月を振り返ります。このオプションは、1 か月単位のタイムウィンドウを表し、メトリクスモニターでのみ利用可能です。累積タイムウィンドウは、その最大タイムスパンに達するとリセットされます。例えば、current month を見る累積タイムウィンドウは、毎月 1 日の午前 0 時 (UTC) にリセットされます。あるいは、current hour の累積タイムウィンドウは、30 分から始まり、1 時間ごとにリセットされます。例えば、午前 6 時 30 分、午前 7 時 30 分、午前 8 時 30 分などです。
評価頻度は、Datadog がモニタークエリを実行する頻度を定義します。ほとんどの構成では、評価頻度は 1 minute で、これは 1 分ごとにモニターが選択したデータを選択した評価ウィンドウにクエリして、定義したしきい値と集計値を比較することを意味します。
評価頻度は、使用されている評価ウィンドウに依存します。ウィンドウを長くすると、評価頻度が低くなります。以下の表は、タイムウィンドウを大きくすることで評価頻度がどのように制御されるかを示しています。
| 評価ウィンドウの範囲 | 評価頻度 |
|---|---|
| ウィンドウ < 24 時間 | 1 分 |
| 24 時間 <= ウィンドウ < 48 時間 | 10 分 |
| ウィンドウ >= 48 時間 | 30 分 |
しきい値には、アラートをトリガーする数値を設定します。メトリクスに何を選ぶかによって、エディターに表示される単位 (byte、kibibyte、gibibyte など) が変わります。
Datadog には、アラートと警告の 2 種類の通知があります。モニターのリカバリはアラートや警告のしきい値に基づいて自動的に行われますが、条件を追加することもできます。リカバリのしきい値について詳しくは、リカバリのしきい値とはを参照してください。たとえば、メトリクスが 3 を超えたときにモニターがアラートを出し、回復しきい値が指定されていない場合、メトリクス値が 3 を下回るとモニターは回復します。
| オプション | 説明 |
|---|---|
| アラートしきい値 (必須) | アラートの通知のトリガーに使用される値 |
| 警告しきい値 | 警告の通知のトリガーに使用される値 |
| アラート回復しきい値 | アラートのリカバリに対する追加条件を示すしきい値 (任意) |
| 警告回復しきい値 | 警告のリカバリに対する追加条件を示すしきい値 (任意) |
しきい値を変更すると、エディター内でプレビューグラフにカットオフポイントを示すマーカーが表示されます。
メモ: しきい値を小数で入力する際、値が <1 の場合は先頭に 0 を付けます。たとえば、.5 ではなく 0.5 としてください。
チェックアラートは、各チェックグループにつき、送信されたステータスを連続的にトラックし、しきい値と比較します。チェックアラートを次のように設定します。
何回連続して失敗したらアラートをトリガーするか、回数 <数値> を選択します。
各チェックは OK、WARN、CRITICAL のいずれか 1 つのステータスを送信します。WARN と CRITICAL ステータスが連続して何回送信されたら通知をトリガーするか選択します。たとえば、プロセスで接続に失敗する異常が 1 回発生したとします。値を > 1 に設定した場合、この異常は無視されますが、2 回以上連続で失敗した場合は通知をトリガーします。
何回連続して成功したらアラートを解決するか、回数 <数値> を選択します。
何回連続して OK ステータスが送信されたらアラートを解決するか、回数を選択します。
チェックアラートの構成の詳細については、プロセスチェック、インテグレーションチェック、カスタムチェックモニターのドキュメントを参照してください。
正常な状態で、メトリクスが常にデータを報告するようにするには、「データなし」通知を利用すると便利です。たとえば、Agent を使用しているホストが継続的に稼働している必要がある場合、system.cpu.idle メトリクスがデータを常に報告することが期待されます。
この場合、データ欠落の通知を有効にする必要があります。以下のセクションでは、各オプションでこれを実現する方法を説明します。
注: 欠落したデータに対してアラートを出す前に、モニターはデータを評価できなければなりません。例えば、service:abc のモニターを作成し、その service からのデータが報告されていない場合、モニターはアラートを送信しません。
データ欠落への対応には 2 つの方法があります。
Notify no data オプションを使用したメトリクスベースのモニターOn missing data オプションは、APM Trace Analytics、Audit Log、CI Pipelines、Error Tracking、Events、Logs、および RUM モニターでサポートされていますデータなしを通知しない場合は Do not notify を、データなしが N 分以上続いた時に通知する場合は Notify を設定します。
データが欠落している場合、またはデータが欠落していない場合に通知されます。構成された時間帯にデータが受信されなかった場合に通知されます。
注: 「データなし」ウィンドウは、評価期間中に最低 2 回設定することを推奨します。
自動的に停止・起動するホストのオートスケーリンググループのメトリクスを監視している場合、データがないことを通知すると、多くの通知が発生します。
この場合、欠落データに対する通知を有効にするべきではありません。このオプションは、データが長期間報告されていない時に有効にすると機能しません。
データ欠落の通知を行わないモニターの場合、ステータスを OK から変更するデータが戻ってくるまで、モニターは評価をスキップし、緑色のままとなります。
「データなし」を通知しないモニターの場合、グループがデータを報告しないとモニターは評価をスキップし、最終的にグループをドロップします。この期間、結果ページのバーは緑のままです。データがありグループが報告を再開すると、グリーンバーには OK ステータスとバックフィルが表示され、中断がなかったかのように見せます。
N 分のデータがない場合、ドロップダウンメニューからオプションを選択します。
Evaluate as zero / Show last known statusShow NO DATAShow NO DATA and notifyShow 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 に設定されます。 |
Evaluate as zero と Show last known status のオプションが、クエリの種類に応じて表示されます。
default_zero() 関数がない Count クエリを使用するモニターに使用できます。Count 以外のクエリタイプ、例えば Gauge、Rate、Distribution を使用しているモニター、および default_zero() を持つ Count クエリで利用できます。アラートをトリガーされた状態から解決するタイミングを、[Never]、After 1 hour、After 2 hours などで指定します。
自動解決は、データが送信されなくなったときに機能します。データがまだ報告されている場合、モニターは、ALERT または WARN 状態から自動解決されません。データがまだ送信されている場合は、再通知機能を利用して、問題が解決されていないことをチームに知らせることができます。
メトリクスが定期的に報告を行う場合に、トリガーされたアラートを一定の期間の後に自動で解決したいことがあります。たとえば、エラーのログだけを報告するカウンターがある場合、エラーの数が 0 であれば報告が行われないため、アラートがいつまでも解決しません。このような場合、メトリクスからの報告がないまま一定の期間が経過したらアラートを解決するように設定できます。注: モニターがアラートを自動で解決し、次回の評価でクエリーの値がリカバリのしきい値を満たしていない場合、モニターはもう一度アラートをトリガーします。
ほとんどの場合、アラートは問題が実際に修正されてから解決する必要があるため、この設定は不要です。つまり、通常はこれを [Never] にしておいて、メトリクスが設定されたしきい値を上回る (または下回る) 場合にだけアラートを解決するようにしてください。
データが欠落してから N 時間経過すると、そのグループをモニターステータスから削除することができます。最大で 72 時間です。
自動解決オプションと同様に、グループの保持は、データが送信されなくなったときに機能します。このオプションは、データが報告されなくなった後、グループがモニターのステータスに保持される時間を制御します。デフォルトでは、グループはドロップされる前に 24 時間ステータスを保持します。グループ保持の開始時間と自動解決オプションは、モニタークエリがデータを返さないとすぐに 同一 になります。
グループ保持時間を定義するユースケースとしては、以下のようなものがあります。
注: グループ保持時間オプションは、On missing data オプションをサポートするマルチアラートモニターを必要とします。これらのモニタータイプは、APM トレース分析、監査ログ、CI パイプライン、エラー追跡、イベント、ログ、および RUM モニターです。
新しいグループの評価開始を N 秒遅らせます。
アラートを開始する前に待機する時間 (秒単位)。新しく作成されたグループが起動し、アプリケーションが完全に起動できるようにします。これは負でない整数である必要があります。
たとえば、コンテナ化されたアーキテクチャを使用している場合、グループ遅延を設定すると、新しいコンテナが作成されたときのリソース使用量や待ち時間が長いために、コンテナを対象とするモニターグループがトリガーされなくなります。遅延はすべての新しいグループ (過去 24 時間に表示されていない) に適用され、デフォルトは 60 秒です。
このオプションは、マルチアラートモードで使用できます。
評価を N 秒遅らせます。
評価を遅らせる時間 (秒単位)。負以外の整数を指定してください。たとえば、遅延を 900 秒 (15 分) に、モニターが評価を行う期間を直前の 5 minutes に、時刻を 7:00 に設定すると、モニターは 6:40 から 6:45 までのデータを評価します。構成可能な評価遅延の最大値は 86400 秒 (24 時間) です。
通知メッセージを構成して、最も関心のある情報を含めることができます。アラートを送信するチームと、アラートをトリガーする属性を指定します。
このセクションを使用して、チームへの通知を構成し、これらのアラートを送信する方法を構成します。
通知メッセージの構成オプションの詳細については、アラート通知を参照してください。
アラートは、クエリを定義する際に group by の手順で選択したグループに応じて自動的にグループ化されます。クエリにグループ化がない場合、デフォルトで Simple Alert (シンプルアラート) でグループ化されます。クエリがディメンションでグループ化されている場合は、Multi Alert (マルチアラート) でグループ化されます。
Simple Alert モードでは、すべての報告元ソースを集計します。集計値が設定条件を満たすと、アラートを 1 件受信します。
Multi Alert モードは、グループパラメーターに従って、各ソースにアラートを適用します。設定した条件を満たすグループごとにアラートを受け取ります。例えば、容量メトリクスを見るクエリを host と device でグループ化して、容量が不足しているホストデバイスごとに個別のアラートを受け取ることができます。
どのディメンションでアラートをトリガーするかをカスタマイズすることで、ノイズを減らし、最も重要なクエリに焦点を当てることができます。クエリを host と device でグループ化しているが、host 属性がしきい値を満たしたときだけアラートを送信したい場合、マルチアラートのオプションから device 属性を削除して送信する通知数を減らしてください。
注: device タグがなく、host タグだけが報告されているメトリクスは、モニターによって検出されません。host と device の両方のタグを持つメトリクスは、モニターによって検出されます。
クエリでタグまたはディメンションを構成した場合、これらの値はマルチアラートで評価されるすべてのグループで利用でき、有用なコンテキストで動的に通知を埋めることができます。通知メッセージでタグの値を参照する方法については、属性変数とタグ変数を参照してください。
| グループ化 | シンプルアラートモード | マルチアラートモード |
|---|---|---|
| (すべて) | 1 つの通知をトリガーする 1 つの単一グループ | N/A |
| 1 つ以上のディメンション | 1 つ以上のグループがアラート条件を満たす場合の 1 つの通知 | アラート条件を満たすグループごとに 1 つの通知 |
お役に立つドキュメント、リンクや記事:
