概要

モニターをトリガーせずに、システムのシャットダウン、オフラインメンテナンス、またはアップグレードのダウンタイムをスケジュールします。ダウンタイムはすべてのモニターのアラートと通知を無音にしますが、モニターの状態遷移を妨げることはありません。

ダウンタイムスケジュールの新規作成

Datadog でモニターのダウンタイムのスケジューリングを行うには、Monitors > Manage Downtimes の順に移動します。その後、画面右上の Schedule Downtime ボタンをクリックしてください。

個々のモニターをミュートするには、モニターステータスページの上部にある Mute ボタンをクリックします。これにより、その特定のモニターのダウンタイムスケジュールが作成されます。

サイレントにする対象を選択

モニター名によって特定のモニターに、またはモニタータグによって広範囲のモニターにダウンタイムスケジュールを適用します。Group scope で追加のフィルターを適用します。Preview affected monitors をクリックすると、対象となるモニターが表示されます。その他の例や使用例については、ダウンタイムスケジュールのスコープを参照してください。

注: ダウンタイムがスケジュールされた後に作成または編集されたモニターは、スコープに一致する場合、自動的にダウンタイムに含まれます。

モニター名で

検索するか、ドロップダウンメニューを利用してサイレントにしたいモニターを選択します。フィールドを空欄にすると、すべてのモニターがデフォルトでサイレント状態に設定されます。スコープを選択して、特定のホストやデバイス、任意のタグに限定したダウンタイムを設定することもできます。選択されたすべてのスコープに紐付くモニターのみがサイレントに設定されます。

モニタータグで

1 つまたは複数のモニタータグに基づいて、ダウンタイムをスケジュールします。1 つのダウンタイムに選択できるタグの最大数は 32 です。各タグの長さは最大 256 文字です。選択したすべてのタグを持つモニターだけがサイレントになります。追加の制約のためにスコープを選択することもできます。

ダウンタイムスコープ

グループスコープを使用して、ダウンタイムに追加のフィルターを適用し、どのモニターをミュートにするかをよりコントロールすることができます。ダウンタイムのグループスコープは、モニター固有の対象の後にマッチします。モニタータグを使用して複数のモニターを対象にする場合、グループスコープに一致させる前にタグ付けされたモニターを見つけます。

ダウンタイムのスコープは、モニターのクエリフィルターまたはモニターのグループ名という 2 つの潜在的なターゲットと一致します。

モニターグループ名のスコープ

グループスコープを適用することで、どのモニターをミュートするかをよりコントロールすることができます。例えば、あるモニターがすべてのサービスの平均レイテンシーを監視しているとします。あなたは web-store サービスのアップグレードの実行を計画しており、リクエストの遅延と潜在的なエラーを予測しています。

あなたは service:web-store 関連の通知はミュートされ、残りのサービスのその他の重要なアラートは通常通り配信されるようにしたいと思います。モニター対象を選択した後、ダウンタイムのグループスコープに service:web-store と入力します。

注: これは service や host など、複数のディメンションを持つグループでも動作します。service:web-store にダウンタイムを作成すると、例えば service:web-store,host:a や service:web-store,host:b のように、そのサービスを含むすべてのグループをミュートします。

モニタークエリフィルターのスコープ

モニタークエリをフィルターして、気になるディメンションだけを見ることができます。特定のディメンションを対象とするダウンタイムを作成できるので、グループ化を追加する必要はありません。

上記のモニターは、モニター固有の対象に一致し、env:prod によってスコープされたダウンタイムによってミュートされます。

ダウンタイムスコープ構文

ダウンタイムスコープクエリは、プラットフォーム全体の他の多くの製品がサポートしている共通の検索構文に従っています。ダウンタイムのスコープにすべてのグループを含めるには、Group scope に * と入力します。グループスコープの他の例:

ダウンタイムスコープの制限

サポートされていない制限がいくつかあります。

• 例えば、team:app AND (service:auth OR (service:graphics-writer AND (env:prod OR (type:metric AND status:ok)))) のような 2 つを超えるレベルの入れ子はサポートされていません。ダウンタイムは最大で 2 つのレベルの入れ子にすることができます。ロジックを分解するには、別々のダウンタイムを使用してください。
• 否定はキー/値のペアと OR を持つタグに対してのみサポートされます。例えば、-key:value や -key(A OR B) などです。service:(A AND B)、service:(-A OR -B)、service(A B) などのスコープはサポートされていません。
• 例えば、service:A OR host:X のように、トップレベルの OR はサポートされていません。この場合、2 つの別々のダウンタイムが必要になります。
• prod AND service:(A or B) や prod のようなキーなしのタグはサポートされていません。タグにはキーが必要で、この場合は例えば env:prod です。
• 疑問符のワイルドカード service:auth? はサポートされていません。ワイルドカードを使用する必要がある場合は、代わりに * を使用してください。
• キー内の無効な文字 en&v:prod は有効なダウンタイムスコープではないため、拒否されます。

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

1 回限り

開始日時とタイムゾーンを指定して 1 回のみのダウンタイムを設定します。オプションで終了日時を設定することもできます。

繰り返し

定期的なメンテナンスなどには繰り返しのダウンタイム設定が便利です。開始日時、タイムゾーン、繰り返し条件、期間を指定して繰り返しのダウンタイムを設定します。オプションで終了日や繰り返し回数を指定することもできます。

繰り返しのダウンタイムの 1 つのダウンタイムが終了すると、1 つのダウンタイムはキャンセルされ、同じ制約と更新された開始時刻と終了時刻で新しいダウンタイムが作成されます。
注: 元の作成者は、新しく作成されたすべてのダウンタイムに関連付けられます。

ダウンタイムのスケジュールを定義するには、繰り返しルール (RRULE) を使用します。公式の RRULE ジェネレーターを、繰り返しルールを生成するツールとして使用してください。一般的なユースケースは、RRULES を使用して、例えば毎月第 3 月曜日など、月の特定の日にダウンタイムを定義することです。繰り返しに関するその他の使用例については、ダウンタイムによるアラートの抑制のガイドを参照してください。

注: RRULE で期間を指定する属性はサポートされません（例: DTSTART、DTEND、DURATION）。

Multistep API テスト

メッセージの追加

このダウンタイムについてチームに通知するメッセージをフィールドに入力します。標準のマークダウン形式および Datadog の @-notification 構文での入力が可能です。フォーマットオプションの詳細については、通知ページを参照してください。

チームへの通知

チームメンバーを指定して通知したり、サービスインテグレーションにメッセージを送信します。Datadog は、ダウンタイムがスケジュール、開始、キャンセル、または期限切れになるたびに、指定した宛先に通知を送信します。これらの監査通知により、あなたのチームはシステムのダウンタイムを認識することができます。

最初の回復通知を無効にする

デフォルトでは、Datadog はダウンタイム前にトリガーし、ダウンタイム中に回復するモニターに対して回復通知を送信します。これは、サードパーティのインテグレーションを使用して、開いたインシデントを自動的にクローズする場合に便利です。チェックボックスを選択すると、これらの通知がミュートされます。

最初の回復通知を無効にするオプションは、複数のダウンタイム間で加算されます。例えば、複数のダウンタイムが重なって同じモニターをミュートする場合、少なくとも 1 つのダウンタイムが無効化オプションをチェックすると、最初の回復通知がミュートされます。

注: このオプションは、最初の回復通知をミュートします。ダウンタイム中にモニターがトリガーして再び回復する場合、このオプションの設定に関係なく、対応する通知は常にミュートされます。

管理

Manage Downtimes ページには、アクティブなダウンタイムとスケジュールされたダウンタイムのリストが表示されます。ダウンタイムを選択して、詳細を表示、編集、または削除します。詳細には、作成者、スコープ、適用されるモニターのリストが含まれます。 ファセットパネルと検索バーを使用して、Creator、Scope、Monitor Tags、または Active、Automuted、Recurring パラメーターのリストをフィルタリングします。

履歴

ダウンタイムの履歴は、Monitor Status ページでグループ移行履歴に重ねて見ることができます。また、イベントエクスプローラーでは、tags:audit downtime、または tags:audit downtime_id:<DOWNTIME_ID> で ID による特定のダウンタイムを検索することで見ることができます。

ミュート設定

モニターは、ALERT、WARNING、RESOLVED、NO DATA 間でステータスが切り替わる際にイベントをトリガーします。モニターがミュートまたはダウンタイムによってサイレント状態になっている時は、RESOLVED から別の状態に変わっても、イベントや通知はトリガーされません。

注: モニターのステータスページからモニターをミュートまたはミュート解除しても、そのモニターに関してスケジュールされたダウンタイムは削除されません。ダウンタイムを編集または削除するには、Manage Downtimes ページから設定を変更するか、API を使用する必要があります。

有効期限

デフォルトでは、ダウンタイムの期限が切れたときにモニターのステータスがアラート対象 (ALERT、WARNING、NO DATA) の場合、モニターは新しい通知をトリガーします。これは、ダウンタイム中にモニターの状態が (たとえば OK から ALERT、WARNING、または NO DATA に) 変わったモニターおよび、ダウンタイムが始まる時点で既にアラート対象の状態であるモニターに適用されます。ダウンタイムが手動でキャンセルされた場合、モニターがアラート対象の状態に入っていても、通知は送信されません。

デフォルトの動作をオーバーライドするには、“Notify Your Team” セクションのオプションを使用して、ダウンタイムの終了時に送信する通知を指定します。API で作成されたダウンタイムの場合、デフォルトの動作で is_cancelled オプションが除外されます。

例 1: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中も継続した場合:

1. ダウンタイム中、このアラートの通知は停止されます。
2. モニターはアラートの状態です（依然として条件が満たされているため）。
3. ダウンタイムが終了します。
4. アラート条件が依然として満たされるため、通知が送信されます。

例 2: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中にリカバリした場合:

1. ALERT 状態から OK に移行します。
2. ダウンタイム中にリカバリ通知が送信されます（ダウンタイム中最初のリカバリのみ）。

モニターレポート

週間モニターレポートには、ダウンタイム時を含むすべてのアラートのステータスが含まれます。

オートミュート

Datadog は、特定のクラウドワークロードの手動シャットダウンに関連するモニターをプロアクティブにミュートすることができます。シャットダウンの自動ミュートには、以下のシナリオがサポートされています。

• **Amazon EC2 インスタンス**と、CloudWatch API からのホストステータスに基づく AWS オートスケールによるインスタンスの終了。
• Google Compute Engine (GCE) インスタンスおよび、GCE API からのホストステータスに基づいて GCE オートスケーリングによってトリガーされるインスタンスの終了。
• シャットダウンが手動または Azure オートスケーリングによってトリガーされたかにかかわらず、Azure Resource Health API を通じて利用できるヘルスステータスに基づく、Azure VM。

その他の参考資料

お役に立つドキュメント、リンクや記事:

ダウンタイム時のアラートを停止するガイド ダウンタイムスケジュールのスコープガイド モニターの作成DOCUMENTATION モニター通知DOCUMENTATION