Monitoring レファレンス

このMonitoringレファレンスでは、条件が満たされた時にチームが通知を受けるための設定について解説します。DatadogのMonitor(監視)機能を使い始めたばかりの場合、まずは入門編のMonitor(監視)機能の設定ガイド ページを参照して下さい。

用語集

以下は、このドキュメントで使用している用語の簡単な概要になります。

  • Status: 各Agent Checkは、ホスト上で定期的に実行されOK, WARNING, CRITICALのステータスをDatadogに送信します。
  • Check: Agent Checkのことで、複数のステータスを送信します。
  • Monitor: Agent Checkのステータスやメトリクスの閾値の確認手順、その他のアラート条件を元に通知を送信します。
  • Monitorタイプ: ホスト-, メトリクス-, インテグレーション-, プロセス-, ネットワーク-, イベント-, カスタムチェック, APM-, コンポジット-, があります。特定のMonitorタイプの詳細に関しては、サイドバーからそれぞれのタイプの項目を確認してください。
  • タグ: 各メトリクスやホストに対して付けることができるラベルです。タグの詳細に関しては、Tagging ページを参照して下さい。

新しい Monitor の作成

Create Monitorsのページへ移動するには、メインメニューのMonitorsタブからドロップダウンメニューのNew Monitorを選択します(テーマの選択次第により、メインメニューは画面の左側あるいは上部に配置されています)。ページが表示されると各Monitorタイプが左側に一覧で表示されます。このドキュメントでは、これらの各Monitorタイプの設定方法について解説していきます。

ホストを対象にしたMonitor

Datadog Agent バージョン 5.0.0 以上が必要です。

Datadog Agentが起動しているとdatadog.agent.upと呼ばれるハートビート信号を UPというステータスで定期的に送信します。 このハートビート信号の状態をMonitor対象に追加することで、Datadog Agentやホストの死活状態が把握できます。

  1. ホスト名かタグの単一指定か組み合わせを設定します。タグを選択した場合は、そのタグ(タグの組み合わせ)が付与されているホストが監視対象になります。

  2. Check AlertまたはCluster Alertを選択します。その後、no-data timeframeの項目で、分単位で時間を設定します。ここで設定した時間を超えてハートビート信号が受信できなかった場合に、通知が送信されます。

  3. 通知先の設定をします。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

メトリクスを対象にしたMonitor

  1. アラートのタイプを選択します。

    alert type

    threshold alertは、時間枠内のメトリクス値と指定した閾値を比較する、最も一般的なアラート検知の方法です。更に、アラート条件セクションには、追加で設定可能なオプションもあります。このアラートタイプは正常な範囲か値が事前に分かっている場合に使用します。

    change alertは、直近のデータポイントの値に対するいくらか前の時間の値との変化量または変化率について、指定した閾値と比較します。 比較しているデータポイントの値は単一点の値ではなく、Set alert conditions のセクションで指定されたパラメータで計算されたものになります。

    このアラートタイプは、メトリクスのゆっくりとした変化はもちろん、急速なスパイクやドロップを追跡するのに有効であり、そのメトリクスの正常な範囲や値が事前に分かっていない場合に特に有効です。 注: このアラートの為の計算値は絶対値ではありません。従って下に向かう変化は、マイナス値になります。

    Anomaly Detection は、アルゴリズムベースの異常検出機能です。過去の挙動、つまり1日のうちの特定の時間帯、あるいは1週間のうちの特定の1日の変動パターンを考慮した際に、普段とは異なる挙動がみられた際に検出することができます。これは、閾値ベースのアラートモニタリングで監視することが困難であったり不可能な、強い傾向のある繰り返しパターンを持ったメトリクスに適しています。

    Outlier Detection はアルゴリズムベースの異常検出機能であり、グループ内の特定の個体に他とは異なる挙動がみられた際に外れ値データ(Outlier)として検出することができます。例えば、Webサーバー群の特定の1サーバーが異常なリクエスト数を処理しているような場合に検出し、これをリプレースすべきか判断することができます。あるいは、特定のAWSアベイラビリティゾーン(AZ)において、他のAZより多めの500(5XX)エラーを生じていることを早めに検出することで、そのAZに迫りつつある問題を察知することができるかもしれません。

  2. メトリクスとそのメトリクスを監視する範囲(スコープ)を設定します。

    metric scope

    Datadogに送信している全てのメトリクスをもとにMonitor設定を作成することができます。 この項目では、グラフ表示に使っている標準的な対象範囲(スコープ)の指定の規則が適用されます。 この規則の詳細に関しては、グラフ表示入門のページの対象範囲の指定(scope)を参照してください。

  3. アラートグループを選択します。

    alert grouping

    Simple Alertは、全てのレポートソースをまとめて監視します。”Set alert conditions”のセクションで設定した条件に合致した場合、アラートを1回送信します。この設定は、単一ホストから送信されてくるメトリクスを監視するようなケースに最適です。例えば、”avg of system.cpu.iowait over host:bits”のような設定をしてる場合です。更に、”sum of nginx.bytes.net over region:us-east“のように複数のホストの値を集計して単一メトリクスとして監視したい場合にも有効です。

    Multi Alertでは、パラメータとして指定したグループについて、複数のレポートソースからのアラートを通知することができます。例えば、ディスク容量に関するアラートを通知する場合、ホストとデバイスについてグループを指定すると良いでしょう。JSONでクエリを定義する場合は以下です。

    avg:system.disk.in_use{*} by {host,device}
    

    このように設定することにより、各ホストの各デバイス毎にディスクスペースが無くなった際のアラートを通知することができるようになります。

  4. アラート条件を設定します。

    • アラートタイプによって、選択できるthresholdオプションは若干異なります。どちらのタイプでも、閾値と比較タイプを設定します。閾値を変更する毎に、グラフ上のカットオフポイントを示すマーカーの位置が更新されて表示されます。
    metric threshold

    メトリクスの閾値を設定する際、その値に単位をつけて入力することができます。例えば、system.disk.usedを監視する場合、20GBを閾値として設定することができます。

    threshold alert の場合、集計期間内に含まれるデータの集計方法 を決めるオプションを選択することができます。アラートエンジンは、別の時系列データを生成し選択された集計を実行します。

    それぞれのオプションの詳細は以下のようになります:

    • on average(平均値で比較): 時系列データは、平均値を算出され単一の値となります。その平均値が閾値と比較されます。

    • at least once(少なくとも1回): 生成された時系列データ内のどれかの値が閾値を超えている場合、アラートが発報されます。

    • at all times(常時): 生成された時系列データの全てのポイントが閾値を超えている場合に、アラートが発報されます。

    • in total(合計値): 時系列データの全てのポイントの合計が閾値を超えている場合に、アラートが発報されます。

    注意: *on average*と*at all times*の集計は、最終的に受信したデータが揃っていることを*必要条件*としています。このことは、全ての時系列データが完全に揃っていることを要求しているわけではなく、集計に使うデータのギャップが1分以上空いていないことを要求しています。言い換えれば、1分以上間隔の空くメトリクスに関しては、*at least once*または*in total*を使用することをお勧めします。

    • change alertオプションを選択している場合は、追加で設定可能な項目があります。

      • change は値そのものの変化量を意味し、% change はその値の過去の値との変化量を意味します (つまり過去の値が2で現在が4の場合、% change は100%になります)。
      • 比較する値の変化は、設定された時間枠の範囲内で指定します。時間枠は5分から24時間の間で指定が可能です (最短で5分前の値と、最大で24時間前の値との比較)。
      • threshold alert とほぼ同じように、集計期間集計期間内に含まれるデータの集計方法 を設定します。
    • Anomaly Detection のより詳しい設定方法は、Anomaly Detection ガイドを参照して下さい。

    • Outlier Detection のより詳しい設定方法は、Outlier Detection ガイドを参照して下さい。

  5. 必要に応じて、一定時間以上データが届かない場合notify on no data(オプション)を設定することができます。このオプションを設定する時間枠は、先の条件設定で設定した時間枠の2倍以上の時間枠である必要があります。例えば、過去5分のメトリクスを基にアラートを設定しているなら、データが届いていないことを通知する前に、少なくとも10分間以上の時間を設定する必要があります。

  6. automatically resolve the monitor from a triggered state(アラートが発報している状態を自動的に解除する)オプションを選択することができます。問題が解決したときのみアラートが解除されるのが望ましいため、一般的にこのオプションはOFFにしておくことをお勧めします。

    このオプションの最も一般的なユースケースは、非常に時間の離れたエラーのカウンターです。エラーが発生しなくなると、Datadogへのメトリクスのレポーティングも止まります。一度発報状態になったアラートを解除するためのデータが届いていないので、そのアラートを解除するために、自動での解除が必要になります。

  7. 通知先の設定をします。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

インテグレーションを対象にしたMonitor

インテグレーションタブをクリックすると、既にインストールされているインテグレーションのタイルがタブの下に表示されます。そのタイルを選択するとStatusまたはMetricというMonitorの設定を選択できるようになります。

  • Integration Status を選択すると、そのインテグレーション用のサービスチェックを1つ以上提示します。設定で利用可能なオプションの詳細については、カスタムチェックを対象にしたMonitorのセクションを参照してください。

  • Integration Metricを選択すると、メトリクスを対象にしたMonitorと同等の設定インターフェイスが表示されます。この設定画面のSelect a metricsの項目では、インテグレーションが収集している全てのメトリクスから選択することができます。項目②の”Set alert conditions”のオプションに関しては、先の”メトリクスを対象にしたMonitor”のセクションの “アラート条件の設定” を参照してください。

プロセスを対象にしたMonitor

プロセスを対象にしたMonitorは、Datadog Agentのサービスチェックによってレポートされるprocess.upの状態を監視しています。

設定の詳細については、Process チェックのページをお読みください。

各プロセスに対しサービスチェックのステータスが生成されます。プロセスを対象にしたMonitorの作成画面を介して、どのサービスチェックのステータスを監視し、どのような状態になったときに通知するか設定することができます。

  1. 監視したいプロセスを選択します。Datadog Agentの設定ファイルで有効にしているプロセスチェックの名前が表示されます。

  2. モニタするスコープを選択します。先に選択したプロセスのステータス情報に基づいてホスト名とタグが表示されます。

  3. アラートのオプションを指定します。利用可能なオプションの詳細については、カスタムチェックを対象にしたMonitorの同セクションを参照してください。

  4. 通知のオプションを設定します。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

ネットワークを対象にしたMonitor

ネットワークを対象にしたMonitorは、Datadog Agentで提供しているTCPおよびHTTPのチェックの情報を監視します。Datadog Agentでネットワークチェックを有効にする方法は、guide to network checks を参照してください。

ネットワークステータス

  1. ネットワークチェックを指定します。Datadog Agentによりレポーティングされた全てのHTTPとTCPチェックから選択することができます。

  2. モニタするスコープを選択します。先に選択したネットワークチェックのステータス情報に基づいてホスト名とタグが表示されます。

  3. アラートのオプションを指定します。利用可能なオプションの詳細については、カスタムチェックを対象にしたMonitorの同セクションを参照してください。

  4. 通知のオプションを設定します。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

ネットワークメトリクス

  1. ネットワークメトリクスを指定します。Datadog Agentによりレポーティングされた全てのHTTPとTCPの応答時間メトリクスから選択することができます。

  2. モニタするスコープを選択します。先に選択したネットワークメトリクスのステータス情報に基づいてホスト名とタグが表示されます。

  3. アラートのオプションを指定します。利用可能なオプションの詳細については、カスタムチェックを対象にしたMonitorの同セクションを参照してください。

  4. 通知のオプションを設定します。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

イベントを対象にしたMonitor

イベントを対象にしたMonitorでは、指定した条件に合致する場合にアラートで通知することができます。

  1. 監視する文字列とパラメータ(ステータス, 優先度, ソース, タグ)を設定します。

  2. アラートグループを選択します。

  3. アラート条件 を設定します。閾値時間枠の設定によって、アラートが発報されるために必要な時間枠あたりのイベント発生回数を指定することができます。

    1. 通知のオプションを設定します。通知先の設定に関しては、このドキュメントの”通知先の設定”の項目を参照してください。

カスタムチェックを対象にしたMonitor

カスタムチェックを対象にしたMonitorでは、独自に作成したAgent Checkによって収集しているサービスチェックのステータスを監視します。

メトリクスやイベント、あるいはサービスチェックを送信する独自のCheckの作成方法については、「Agent Checkの書き方」を参照してください。

  1. カスタムチェックを選択します。

  2. 監視したいホスト名やタグ(複数可)を選択します。 アラートが通知されるの為の確認は、監視対象として指定されたホストから送られてくるタグやタグの組み合わせに対して実行されます。例えば、Nginxのサービスチェックが、{host,port}毎にステータスを報告しているとします。そしてもしも、単一ホスト上で複数のサーバが稼働している状態であれば、それぞれのサーバの障害は個別に通知されることになります。

  3. アラートのオプション を選択します。

各サービスチェックが実行されると、CRITICAL、WARNING、OKの何れかのステータスを送信します。Trigger the alert after selected consecutive failures:の項目でステータス変更とアラートを通知するための連続発生回数を指定します。例えば、カスタムMonitorのチェックが失敗した場合には直ちに知りたいが、OK状態が続くまではリカバー状態にはなってほしくないとします。このようなケースではオプションを、1回のCritical、1回のWarning、4回のOKと設定します。

必要に応じて、一定時間以上データが届かない場合のnotify on no data(オプション)を設定することができます。このオプションを設定する時間枠は、先の条件設定で設定した時間枠の2倍以上の時間枠である必要があります。

  1. 通知のオプションを設定します。通知先の設定に関しては、このガイドの”通知先の設定”の項目を参照してください。

コンポジット-複合-Monitor

コンポジットMonitorを使用すると、多数の個々のMonitorを1つの複合条件Monitorとしてまとめることができ、より具体的なアラート条件を定義することができます。

設定の詳細については、Composite Monitor ガイドのページをお読みください。

コンポジットMonitorは、複合したトリガ条件が真となる値を個々のMonitorのステータスが同時に持つ場合にトリガされます。

通知先の設定

通知は、監視において非常に重要な要素です。可能な限り素早く障害を解決するためには、適切な人材が通知を受けるように設定する必要があります。

  1. Monitorの通知にタイトルを付けましょう。多くの場合、簡潔な説明を使用することが重要です。なぜならばチームメンバーが、何が起こっているかを直ぐに理解することができるからです。

  2. Monitorの通知本文を入力します。このフィールドには、Datadogの@-notification構文の他に標準的なmarkdownフォーマットでも記述することができます。加えて、単に@their-emailとしてメールアドレスを記述することにより、Datadogに登録していないメンバーにもメールによって通知を送信することができます(例えばuser@example.comなら@user@example.comと記述)。

Monitorの通知本文の一般的なユースケースは、障害を解決するための詳細な手順を記述することです。例えばデータベースを監視している場合には、セカンダリーとしてスタンバイしているノードのフェールオーバーの手順を記しておくと良いでしょう。全てのケースにおいて、メッセージ本文には可能な限り多くの情報を記すように心がけましょう。

  1. 必要に応じてMonitor renotificationを有効にしてください。このオプションは、発報しているMonitorに解決の旨のチェックマークがつけられまで、チームメンバーに注意喚起を促し続けるためには良い手段です。このオプションを有効にすると、Monitorが再通知する際、オリジナルのメッセージに加えて送信するエスカレーションメッセージを設定することができます。

注釈: 通知の嵐を避けるために、20秒の間に発生した同一 monitor ID/アラートタイプをまとめる新たなグループ通知が実装されました。このグループ通知では、20秒のグループのうち最初の2つの通知は通常通り送信され、その他のすべての通知は最初の2つの通知の後に1つのメッセージとしてまとめて送信されます。(この機能は標準の通知方法として実装されておりますので、特に設定は不要です)

通知内で使うことのできるテンプレート変数

Monitorの通知の内容を状況に応じて書き換えるためにテンプレート変数(template variables)を使うことができます。この機能は全てのMonitorタイプで使うことができます。 テンプレート変数(template variables)には、主に2つのユースケースが考えられます。

  1. 通知の種類に応じて異なるメッセージを表示したい場合(e.g. triggered, recovered, no data)
  2. Multi Alertで、通知本文にアラート発報の範囲(スコープ)の情報を組み込みたい場合

それぞれの主要ユースケースについて解説します。

  1. 通知タイプの違いに基づいた条件変数: Monitorによって検知されたイベント(triggered, warn, recovered, no dataなど)によって異なった通知本文を表示することができます。これらの条件変数では、次のような基本的なif-else構文を使っています:

    次が、通知本文の記述の例です:

    実際に送信されたアラート通知文は、次のようになります:

    リカバーした際の通知文は、次のようになります:

    使用可能な条件変数は is_alert, is_alert_recovery, is_warning, is_warning_recovery, is_recovery, そして is_no_data です。 これら条件変数の解説は、第3ステップ”Say what’s happening”の”Use message template variables”をクリックすることで見ることができます。

  2. Multi Alertのためのタグ変数: 設定しているMonitorがMulti Alertの場合(タグによってグループが指定されている場合)は、通知のタイトルや本文にタグ変数を適用し、アラート発報の範囲(スコープ)を明示することができます。

    次が、Multi Alertでtemplate variables(タグ変数)を使った例です:

    実際に送信されたアラート通知文は、次のようになります:

    利用可能なタグ変数は、第1ステップで選択したタググループに依存します。利用可能なタグ変数のオプションは自動的に選別され、第3ステップの”Use message template variables”ヘルプボックスの内に表示されます。またこれらのタグ変数は、Monitorのタイトル(名前)で使用することもできます。

    一方で、アラートを通知する範囲(スコープ)を指定しているタグには自動的にタイトルに挿入されるものがあります。このため、範囲指定のために多くのタグを使用している場合にはアラートのタイトルが不必要に長くなる可能性があります。もしタグ変数をアラート本文に使用しているのであれば、スペースを節約するためにInclude triggering tags in notification title のチェックを外すことも有効です。この設定によってアラートのタイトルは以下のようになります。

    テンプレート変数はデフォルトでエスケープされます。もし使用したい変数がJSONやコードを含んでおり、それらをエスケープさせたくない場合は、2重カッコのかわりに3重カッコを使用して下さい。(例 {{{event.text}}})

  3. アラート発報の範囲(スコープ)の違いに基づいた条件変数: Monitorによってアラート発報されたグループによって異なった通知本文を表示することができます。

    {{is_match}} 条件句では、アラート発報の範囲情報と文字列の一致を調べます。例えば、role:dbタグを持つホストについてdbチームに通知したいこともあれば、role:appタグを持つホストについてappチームに通知したいこともあるでしょう。

    条件句の中では現在の設定で利用可能なすべてのタグ変数を使うことができます。文字列がタグ変数の中で確認されると一致したとみなされます。

    この条件変数の構文は以下のようになります:

    {{#is_match “タグ変数” “文字列”}} ここに、一致した場合に表示する本文を記述します。 {{/is_match}}

次が、アラート発報の範囲情報に基づいて異なる本文を表示する例です:

通知本文で利用可能なテンプレート変数

Datadgogでは、さまざまなタイプのMonitor (アラート)を提供していますが、各Monitor ごとにメッセージ欄で使えるテンプレート変数が異なります。 インテグレーションMonitor に関連したテンプレート変数は、特定のインテグレーションやそのMonitorの設定内容に大きく依存します。

hostmetricintegrationprocessnetworkcustom checkevent
Conditionals
is_alertYYYYYYY
is_alert_recoveryYYYYY
is_warningYYYYY
is_warning_recoveryYYYYY
is_recoveryYYYYYYY
is_no_dataYYYYYYY
is_matchYYYYYYY
Variables
{{value}}YY
{{threshold}}Y (cluster)YYYYYY
{{warn_threshold}}Y (cluster)YYYYY
{{ok_threshold}}YYYY
{{comparator}}YYYYYYY
Additional variablesContextualContextual
{{check_message}}
Contextual
{{process.name}}
Contextual
{{url.name}}
{{instance.name}}
{{check_message}}

注) 一部のMonitor (アラート)では、監視している対象に基づいて追加でテンプレート変数を提供しています。 例えば、ホストMonitor は host.availability-zonehost.cloud_providerの変数を提供しています。 メッセージ欄の設定を進めている際に、利用可能なテンプレート変数のリストを見るには、欄の右上の”Use message template variables” リンクをクリックするか、メッセージ欄に”{{“を入力し、補完候補リストを表示してください。

Monitor に関する FAQs

  • Monitorは、プログラム的に管理することはできますか?

はい。各プログラミング言語毎ライブラリやcURLを使ってMonitorを制御する方法に関しては、Datadog APIドキュメントを参照してください。

  • ファンクションを基にアラートを発報することはできますか?

はい。 Monitor設定の第一ステップで’Source’タブを選択し、グラフを設定する際のJSONエディタと同じように編集することにより、カスタムクエリやファンクションのアラートを設定すことができます。