ダウンタイムをスケジューリングすると、システムシャットダウンやオフラインメンテナンス、アップグレードを、モニターをトリガーせずに行うことができます。
Datadog でモニターのダウンタイムのスケジューリングを行うには、メインナビゲーションで Monitors –> Manage Downtime の順に移動します。その後、画面右上の Schedule Downtime ボタンをクリックしてください。
検索するか、ドロップダウンを利用してサイレントにしたいモニターを選択します。フィールドを空欄にすると、すべてのモニターがデフォルトでサイレント状態に設定されます。スコープを選択して、特定のホストやデバイス、任意のタグに限定したダウンタイムを設定することもできます。選択されたすべてのスコープに紐付くモニターのみがサイレントに設定されます。
一つないし複数のモニタータグに基づくダウンタイムのスケジューリングが可能です。少なくとも 1 つのタグを選択する必要があります。タグは最大 32 個まで選択でき、各タグの長さは最大 256 文字までとなります。選択されたすべてのタグに紐付くモニターのみがサイレントに設定されます。スコープを選択すれば、対象をさらに制限することもできます。
モニターのサイレント設定にスコープを追加する場合は、Preview affected monitors をクリックして該当するモニターを表示します。ダウンタイムのスケジューリング後に作成または編集されたモニターは、スコープに合致した場合に自動でダウンタイムに組み込まれます。
ダウンタイムを単純なアラートモニターに制限する場合、単純なアラートモニターはすべてのレポートソースを集約して単一のアラートを送信するため、Group scope フィールドは無視できます。
1 台のモニターから複数のアラートを送信している場合は、スコープに含まれるグループだけがサイレントに設定されます。たとえば、host:X がダウンタイムのスコープに含まれており、host:X と host:Y の両方に対してアラートがトリガーされる場合、Datadog は host:Y に対してのみモニター通知を生成します。host:X に対する通知は行われません。
以下の例は、Group scope をマルチアラートモニターに適用する方法を示しています。
例 1: 特定のサービスの通知をミュートする
service:web-store) のみでダウンタイムをスケジュールするには、そのグループを Group scope フィールドに入力します。service:web-store のアラートはスケジュールされたダウンタイム中にミュートされます。
service:web-store のアラートのみがミュートされます。
service:synthesizer、service:consul など) でダウンタイムをスケジュールするには、グループごとに追加のダウンタイムを作成できます。例 2: env と service でグループ化されたモニターの特定の環境の通知をミュートする
env:dev) でダウンタイムをスケジュールするには、そのグループを Group scope フィールドに入力します。env:dev のアラートはスケジュールされたダウンタイム中にミュートされます。
env:dev および dev 環境に関連するすべてのサービスのアラートがミュートされます。
env:dev AND service:web-store) でダウンタイムをスケジュールするには、ダウンタイムに追加スコープを追加します。スケジュールされたダウンタイムが共通のモニタータグに基づいており、スコープ内のモニターが 1 つの “group by” スコープを持つマルチアラートモニターである場合、Group scope フィールドを使用して、スコープ内のモニターが共通に持つグループをサイレントにできます。
例 1: それぞれが 1 つの “group by” スコープを持つ 2 つのマルチアラートモニターには、共通の downtime:true モニタータグがあります。
service グループにわたって平均されたメトリクスを報告するホスト用のマルチアラートモニターです。service:web-store に対して同じメトリクスを報告するホスト用のマルチアラートモニターです。downtime:true モニタータグを持つすべてのモニターに対してスケジュールされます。service:web-store に制限されています。service:web-store が含まれていることがわかります。
service:web-store
service:web-store のダウンタイムが開始されたことを示しています。すべてのモニターのグループ (host ごと) は service:web-store に属しているため、このモニターのダウンタイム中にすべてのホストがミュートされます。開始日時とタイムゾーンを指定して 1 回のみのダウンタイムを設定します。オプションで終了日時を設定することもできます。
定期的なメンテナンスなどには繰り返しのダウンタイム設定が便利です。
開始日時、タイムゾーン、繰り返し条件、期間を指定して定期のダウンタイムを設定します。オプションで終了日や繰り返し回数を設定することもできます。
毎回の定期ダウンタイムが終了すると、そのダウンタイムをキャンセルし、同じ条件（開始時間と終了時間が異なる）の新しいダウンタイムを作成するというパターンが繰り返されます。注: このように新しく作成されたダウンタイムはすべて、元の作成者に関連付けられます。
RRULE (つまり繰り返しルール) を使用して、ダウンタイムのスケジュールを定義します。定期的なルールを生成するためのツールとして、公式の RRULE ジェネレーターを使用してください。
一般的な使用例は、RRULE を使用して月の特定の日のダウンタイムを定義することです。 たとえば、毎月第 3 月曜日に:
注: RRULE で期間を指定する属性はサポートされません（例: DTSTART、DTEND、DURATION）。
このダウンタイムについてチームに通知するメッセージをフィールドに入力します。標準のマークダウン形式および Datadog の @-notification 構文での入力が可能です。
対象のチームメンバーを指定して通知するか、サービスインテグレーションにメッセージを送信します。
ダウンタイムの管理ページには、アクティブなダウンタイムとスケジュールされたダウンタイムのリストが表示されます。ダウンタイムを選択して、詳細を表示、編集、または削除します。Filter downtimes テキストボックスを使用して、ダウンタイムを検索します。
デフォルトでは、このテキストボックスは、ダウンタインの monitor_name、scopes、monitor_tags、message、status パラメーターを検索します。
ダウンタイム履歴は、Monitor Status ページにグループ遷移履歴のオーバーレイとして表示されます。または、イベントストリーム内で tags:audit,downtime を検索するか、tags:audit,downtime_id:<ダウンタイム_ID> を使用して特定のダウンタイムを ID で検索できます。
モニターは、ALERT、WARNING、RESOLVED、NO DATA 間でステータスが切り替わる際にイベントをトリガーします。モニターがミュートまたはダウンタイムによってサイレント状態になっている時は、RESOLVED から別の状態に変わっても、イベントや通知はトリガーされません。
注: UI を使用してモニターをミュートまたはミュート解除しても、そのモニターに関してスケジュールされたダウンタイムは削除されません。ダウンタイムを編集または削除するには、Manage Downtimes ページから設定を変更するか、API を使用する必要があります。
ダウンタイムの期限が切れたときにモニターのステータスがアラート対象（ALERT、WARNING、NO DATA）の場合、モニターは強制リカバリされ、アラートの条件が満たさされればすぐに再トリガーされます。これは、ダウンタイム中にモニターのステータスが（たとえば OK から ALERT、WARNING、または NO DATA に）変わったモニターや、ダウンタイムの開始時にすでにアラート対象のステータスであったモニターも同様です。
例 1: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中も継続した場合:
例 2: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中にリカバリした場合:
OK に移行します。週間モニターレポートには、ダウンタイム時を含むすべてのアラートのステータスが含まれます。
お役に立つドキュメント、リンクや記事:
