Monitor(監視)機能の設定ガイド

Monitor(監視)機能のより詳しいレファレンスは、Monitoringレファレンス ページを参照して下さい。

インフラ全体を一箇所で監視しようとする場合、そのインフラが危機的な状況になっていることを検知する方法を確立するのは重要な作業です。 Datadogでは、能動的にメトリクス, インテグレーション, ネットワークの接続状態, その他を監視してくれるMonitor機能を設定することができます。

一度Monitor機能を設定しておけば、条件が満たされた時に通知を受けることができます。 電子メールでチームメンバーに通知することもでき、サードパーティのサービス(例えばPagerdutyまたは Hipchat)やwebhooksを使い、他のサービスと連携して通知を送信することもできます。

通知を送信したMonitorはイベントストリームに表示され、そのアプリケーションやインフラの問題解決に向けたコラボレーションができるようになります。DatadogのTriggered Monitorsのページには、通知済み状態のMonitorの項目がリスト表示されます。Manage Monitorsのページには全てのMonitorが表示され、それらを管理することができるようになっています。

用語集

以下は、このガイドで使用している用語の簡単な概要になります。

  • Status: 各Agent Checkは、ホスト上で定期的に実行されOK, WARNING, CRITICALのステータスをDatadogに送信します。
  • Check: Agent Checkのことで、複数のステータスを送信します。
  • Monitor: Agent Checkのステータスやメトリクスの閾値の確認手順、その他のアラート条件を元に通知を送信します。
  • Monitorタイプ: host-, metric-, integration-, process-, network-, event-based, custom, APM-, composite- があります。 特定のMonitorタイプの詳細に関しては、Monitoringレファレンス ページを参照して下さい。
  • タグ: 各メトリクスやホストに対して付けることができるラベルです。タグの詳細に関しては、Tagging ページを参照して下さい。

新しいMonitorの作成

Create Monitorsのページへ移動するには、メインメニューの Monitors にマウスオーバーし現れるサブメニューの New Monitor を選択します(テーマの選択次第により、メインメニューは画面の左側あるいは上部に配置されています)。ページが表示されると各Monitorタイプが左側に一覧で表示されます。このガイドでは、メトリクスを対象にしたMonitorタイプについての設定方法を説明していきます。より詳しい各Monitorタイプの設定方法については、Monitoringレファレンスページを参照して下さい。

監視対象の設定

  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に迫りつつある問題を察知することができるかもしれません。

  1. メトリクスとその対象範囲(スコープ)の設定

    metric scope

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

  1. アラートのグループ化についての設定

    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}
    

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

監視条件の設定

  1. アラート検知条件の設定

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

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

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

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

    - *on average*(平均値で比較): 時系列データは、平均値を算出され単一の値となります。その平均値が閾値と比較されます。
    
    - *at least once*(少なくとも1回): 生成された時系列データ内のどれかの値が閾値を超えている場合、アラートが発報されます。
    
    - *at all times*(常時): 生成された時系列データの全てのポイントが閾値を超えている場合に、アラートが発報されます。
    
    - *in total*(合計値): 時系列データの全てのポイントの合計が閾値を超えている場合に、アラートが発報されます。
    

    注意: on averageat 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 ガイドを参照して下さい。

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

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

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

通知先の設定

notification
  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つのメッセージとしてまとめて送信されます。(この機能は標準の通知方法として実装されておりますので、特に設定は不要です)

監視設定をエクスポートする

設定画面の右手 Export Monitor をクリックすることで、Monitor 設定のJSONをエクスポートすることができます。 Monitor 設定をプログラマティックに管理しデプロイする場合は、まずDatadogのUIで雛形となるMonitorを設定してJSONでエクスポートして利用するのが簡単です:

export monitor

ダウンタイムをスケジュールする

メンテナンスやアップグレードなどによる計画停止のため、システムを停止したりオフラインにする必要が生じることもあるでしょう。ダウンタイムをスケジュールことで、設定済みのMonitorがアラートをトリガすることを防ぐことができます。

ダウンタイムの管理

Manage Downtime のページへ移動するには、メインメニューの Monitors にマウスオーバーし現れるサブメニューの Manage Downtime を選択します。 他のMonitor設定ページの上部にある Manage Downtime リンクを選択し移動することも可能です。

downtime-nav

Manage Downtime のページでは、アクティブなものとスケジュールされたもの、両方のダウンタイムのリストが表示されます。各ダウンタイムを選択することで、対象となるホストとMonitor設定の詳細を確認することができます。

downtime-manage

ダウンタイムのスケジュール設定

ダウンタイムをスケジュールするには、画面上部右側の”Schedule Downtime”を選択します。

  1. 停止するMonitorを選択する
downtime-silence

停止したい特定のMonitorを指定するか、ここでは特定のMonitorは指定せずすべてのMonitorを停止の対象とします。続いて、ダウンタイムの対象を限定するために、特定のホスト、デバイス、あるいは任意のタグによって範囲(スコープ)の設定をします。範囲(スコープ)の設定については、グラフ表示入門のページのJSONの使用方法、対象範囲の指定(scope)も併せて参照してください。

すべてのMonitorを停止の対象としたうえで範囲(スコープ)の設定によって対象を限定するような場合には、”Preview affected monitors” (対象となるMonitorをプレビューする)をクリックすることで、現在対象となっているMonitorのリストが表示されます。作成時に停止の対象としたMonitorの範囲(スコープ)は、ダウンタイムのスケジュール設定後でも修正することができます。

指定するMonitorにMulti Alartを含むような場合は、範囲(スコープ)の設定によって限定した対象のみが停止されることに注意して下さい。例えばダウンタイムの範囲(スコープ)がhost:Xにセットされていて、あるMulti Alartはhost:Xhost:Y両方についてアラートを発報する場合, Datadogは引き続きhost:Yについての通知は行います。

  1. スケジュールをセットする
downtime-schedule

ダウンタイムをスケジュールする日時をここで設定します。あるいは、空欄のままにしてダウンタイムを即刻開始することもできます。また、定期的な計画停止のために繰り返しのスケジュールを設定することも可能です。

  1. チームに通知するためのメッセージ本文を追加で設定する
downtime-notify

ダウンタイム設定についてチームに通知するメッセージを入力します。このフィールドには、Datadogの@-notification構文の他に標準的なmarkdownフォーマットでも記述することができます。”Notify your team”フィールドでは、メッセージを送りたいチームメンバー個人あるいは特定のサービス integtration (インストール済みのインテグレーション)を選択することができます。

設定済みのMonitorの管理

Manage Monitors ページではすべての設定済みのMonitorを詳細検索することで、Monitorの削除やミュート、解決済みのマーク、あるいはサービスタグの編集などを、一括で実行することができます。検索した個々のMonitorは、クローンしたり、編集することも可能です。

Monitorを検索する

Monitorの詳細検索では、あらゆるMonitorの属性を組み合わせてクエリすることができます:

  • titlemessage — Monitorのタイトルと通知本文の検索、テキスト検索で使用
  • status — Alert, Warn, No Data, Ok, Muted
  • type — metric, integration, apm, など
  • creator - Monitorの作成者
  • service — サービスタグ
  • scope — 例えば、 *、あるいは role:master-db
  • id - Monitor ID
  • team — タグ
  • env — タグ
  • metric — メトリクス または サービスチェック、例えば、 system.cpu.user, http.can_connect
  • notification — Monitorで設定した通知先のターゲット、例えば、you@example.com, slack-ops-oncall

Monitorの検索を実行するには、画面左側のチェックボックスおよび/あるいは画面上部の検索バーを使用してクエリを指定します。チェックボックスを使用すると、検索バーにも同等のクエリが表示されます。同じように、検索バーのクエリを変更したり一から指定したりすると、チェックボックスの内容も変更が反映されます。いずれの場合でも、クエリの結果はリアルタイムで更新されるので、クリックするための検索ボタンはありません。

Monitorをチェックボックスから検索する

Monitorのタイトルや通知本文を使って検索する必要がないのであれば、Monitorの検索はわずか1-2回程度のクリックをするだけです。 以下の要点を考慮したうえで、検索に必要なだけチェックボックスを選択して下さい:

  • 異なるフィールドの属性をチェックした場合は、それらはAND条件として処理されます、例えば、status:Alert type:Metric (2つの検索条件の間に演算子は記載されていませんが、これはAND条件を意味します)
  • 同じフィールド内で属性をチェックした場合は、それらはOR条件として処理されます、例えば、status:(Alert OR Warn)、しかし、これにはいくつか例外もあります。例えばscopeserviceタグを複数選択した場合はAND条件で処理されます。
  • いくつかのフィールドでは複数の値を選択することが許可されていません、例えば、メトリクス/サービスチェックについて選択した場合は、他のメトリクス/サービスチェックは選択中のチェックを外さない限りリストには現れません。
  • Statusフィールド直下のTriggeredチェックボックスは status:(Alert OR Warn OR "No Data") を意味し、 status:Triggered を意味するわけではありません。これは、Triggered がMonitorステータスの有効な値ではないためです。
  • Statusフィールドには Mutedチェックボックスがありますが、Mutedは実際は独立したフィールドを持つものです。これをチェックすると、検索クエリとしてはmuted:true が加えられます。status:muted ではありません。
  • Metric/Checkのフィールドは検索クエリとしては常にmetric と記述されます。例えば、http.can_connect チェックを追加すると、metric:http.can_connect が検索クエリに記述されます。

いずれのフィールド(Service tag, Scope, Metric/Check, Notification)においても、すべてのMonitorを通して膨大な数の値がある場合はフィールドごとに配置されている検索バーで使用したい値を検索します。

チェックボックスでできることよりも複雑な検索の実行が必要な場合は、画面上部の検索バーにてクエリを指定して下さい。

Monitorの検索クエリを利用する

検索バーで個別にクエリを記述する最も一般的な理由は、すべてのMonitorのタイトルと通知本文に対して特定のテキストを検索したい場合です。シンプルに postgresql と単語で検索した場合は、タイトルか通知本文のいずれかに postgresql を含むすべてのMonitorが返されます。タイトルか通知本文について検索したいが両方ではない場合、いずれかのフィールドを指定して title:postgresql というように検索ができます。

あるいは、Boolean演算子 (AND, OR, そして NOT) とカッコを使用して、Monitorのあらゆるフィールドに対する複雑なクエリを記述します。検索クエリの構文は Elasticsearch のそれと非常によく似ています。このため、Elasticserchの構文がどんなもの ではない のかを説明するのが最も簡単でしょう:

  • 正規表現はサポートされていません。
  • 1字のワイルドカード (?) はサポートされていませんが、一般的なワイルドカードである (*) はサポートされています。
  • 近接検索はサポートされていませんが、 fuzzy 演算子についてはサポートされています。
  • Ranges はサポートされていません。
  • Boosting はサポートされていません。

最後に、下記の文字: -, (, ), ", ~, *, :, ., そして空白は予約されています。これらの文字を含むMonitorフィールドを検索するには、フィールドの文字列を引用符で囲います。status:Alert AND "chef-client" は有効なクエリ文字列ですが、status:Alert AND chef-client は有効ではありません。

フィールドの文字列を囲う際にいくつかの注意点があります:

  • ドット . は既に有効な metric:system.cpu.idle などのフィールドで一般的に使用されているので、引用符で囲っても囲わなくても構いません。
  • 引用符で囲われたクエリ文字列中にワイルドカードを使用することはできません: "chef-client*" は有効な構文ではあるものの、* が文字通りに扱われるため、"chef-client failing" のようなタイトルのMonitorを返すことはありません。

選択したMonitorを設定変更する

探していたMonitorが得られたあとは、検索結果の各Monitor横にあるチェックボックスを使用して編集したいMonitorを1つ以上選択します。STATUS列 見出しの横にある一番上のチェックボックスを選択すると、すべての検索結果を選択できます。検索結果の右上にあるボタン(Mute, Resolve, Delete そして Edit Tags)を使用して、一括してMonitorを変更します。

manage-monitors-mute

個々のMonitorを編集するには、編集したいMonitorにマウスオーバーし、その行の右端にあるボタン (Edit, Clone, Mute, Delete) を使用します。Monitorの詳細を表示するには、そのタイトルをクリックしてステータスページにアクセスします。

manage-monitors-hover-clone

トリガされたMonitorをグループ単位で操作する

トリガされたMonitorを一括でミュートや解決済みとマークするには Triggered Monitors ページを使用します。これはManage Monitors ページとよく似ているので、同じようにMonitorの属性のチェックボックスをやクエリ構文を使用して簡単にMonitorを探すことができますが、いくつか違いがあります。Monitorをトリガの状態(Alert, Warn, または No Data)と表示するだけでなく、Triggered Monitorsページには各Monitorの 各グループ (各アラート元)の行が表示されるというのが大きな違いです。

例えば、サーバーホストによってグループ化された “high latency” というMonitorがあるとします。ホストが20台あり、14台がトリガ状態の場合、検索バーでMonitorのタイトルで検索した場合、Triggered Monitorページには14行が表示されます(例、high latency または title:"high latency")。これにより、一部のアラート元でMonitorを簡単にミュートまたは解決済みとマークすることができます(もちろん、すべてをミュートまたは解決することもできます)

検索クエリを記述する場合、Manage Monitors ページで使用可能なすべてのフィールドを使用できますが、そのほとんどはトリガされたモニタページのチェックボックスで制御できません。 Triggered Monitorsページのフィールドとの違いに関するいくつかの注意があります:

  • status フィールドの代わりに group_status が使用されます。
  • triggered フィールドが追加されています。これにより、トリガされてからの時間によってMonitorをフィルタすることができます。
  • また、 group フィールドも追加されています。これは、複数のグループにまたがったMonitorの検索結果を絞り込むのに役立ちます。例えば、Monitorが hostenv でグループ化されており、このMonitorをタイトルで検索して4行の結果を得ました。グループが host:web01,env:dev, host:web02,env:dev, host:web01,env:prod, そして host:web02,env:prodとなっています。group フィールドを使用することで、env:prod のホスト (group:"env:prod") または web02 のホスト (group:"host:web02") だけを表示できます。

Monitorに関するFAQs

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

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

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

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

手動で monitorを解除することはできますか?

はい。手動で monitorを解除することは可能です(トリガされたmonitorのStatusをResolveとセットすること)。ただし、この操作は以下のケースでのみ有効だと考えられます:

  • monitor が”no data”の状態であり、このmonitor を解除することで triggered monitors ページから排除したいケース
  • monitor がトリガされた状態だがデータの送信は停止しており、このmonitor を解除することで triggered monitors ページから排除したいケース

そうでなければ、monitor はすぐに次の値の評価に移ります。つまり、評価している値が指定している閾値を超えているままなのであれば、Resolveとセットされた場合でもそのmonitor は次の値の評価の際(およそ60秒後)に再びトリガされることになります。