概要
モニターをトリガーせずに、システムのシャットダウン、オフラインメンテナンス、またはアップグレードのダウンタイムをスケジュールします。ダウンタイムはすべてのモニターのアラートと通知を無音にしますが、モニターの状態遷移を妨げることはありません。
セットアップ
ダウンタイムスケジュールを作成する
Datadog でモニターダウンタイムをスケジュールするには、Manage Downtimes ページに移動します。次に、右上の Schedule Downtime ボタンをクリックします。
個々のモニターをミュートするには、モニターステータスページの上部にある Mute ボタンをクリックします。これにより、その特定のモニターのダウンタイムスケジュールが作成されます。
サイレントにする対象を選択
モニター名で特定のモニターにダウンタイムスケジュールを適用したり、モニタータグで広範なモニターに適用したりできます。追加のフィルターを Group scope で適用します。Preview affected monitors をクリックして含まれるモニターを確認してください。詳細な例と使用例については、ダウンタイムスケジュールのスコープ設定を参照してください。
注: ダウンタイムがスケジュールされた後に作成または編集されたモニターは、スコープに一致する場合、自動的にダウンタイムに含まれます。
検索またはドロップダウンメニューを使用してサイレントにするモニターを選択します。フィールドを空のままにすると、デフォルトですべてのモニターがサイレントになります。特定のホスト、デバイス、または任意のタグにダウンタイムを制限するためにスコープを選択することもできます。 ALL selected scopes (選択したすべてのスコープ) を持つモニターのみがサイレントになります。
1 つまたは複数のモニタータグに基づいて、ダウンタイムをスケジュールします。1 つのダウンタイムに選択できるタグの最大数は 32 です。各タグの長さは最大 256 文字です。選択したすべてのタグを持つモニターだけがサイレントになります。追加の制約のためにスコープを選択することもできます。
ダウンタイムスコープ
グループスコープを使用して、ダウンタイムに追加のフィルターを適用し、どのモニターをミュートにするかをよりコントロールすることができます。ダウンタイムのグループスコープは、モニター固有の対象の後にマッチします。モニタータグを使用して複数のモニターを対象にする場合、グループスコープに一致させる前にタグ付けされたモニターを見つけます。
例えば、すべてのサービスの平均レイテンシーを監視するモニターがあるとします。web-store サービスのアップグレードを予定しており、リクエストの遅延や潜在的なエラーが予想されます。
あなたは service:web-store 関連の通知はミュートされ、残りのサービスのその他の重要なアラートは通常通り配信されるようにしたいと思います。モニター対象を選択した後、ダウンタイムのグループスコープに service:web-store と入力します。
注: これは service や host など、複数のディメンションを持つグループでも動作します。service:web-store にダウンタイムを作成すると、例えば service:web-store,host:a や service:web-store,host:b のように、そのサービスを含むすべてのグループをミュートします。
ダウンタイムスコープ構文
ダウンタイムスコープのクエリは、プラットフォーム全体で多くの他の製品がサポートする共通の検索構文に従います。ダウンタイムの Group scope に * を入力すると、すべてのグループが含まれます。グループスコープのさらなる例は以下の通りです。
| ダウンタイムグループスコープ | 説明 |
|---|
service:web-store | web-store サービスに関するすべての通知をミュートします。 |
service:web-store AND env:dev | dev 環境で実行している web-store サービスに関するすべての通知をミュートします。 |
env:(dev OR staging) | dev または staging 環境に関連するすべての通知をミュートします。 |
service:web-store AND env:(dev OR staging) | dev または staging 環境で実行している web-store サービスに関連するすべての通知をミュートします。 |
host:authentication-* | 名前のプレフィックスが authentication- であるホストに関連するすべての通知をミュートします。 |
host:*-prod-cluster | 名前のサフィックスが -prod-cluster であるホストに関連するすべての通知をミュートします。 |
host:*-prod-cluster | 名前のサフィックスが -prod-cluster であるホストに関連するすべての通知をミュートします。 |
service:webstore AND -env:prod | prod 環境で実行していない web-store サービスに関するすべての通知をミュートします。 |
ダウンタイムスコープの制限
サポートされていない制限がいくつかあります。
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) などのスコープはサポートされていません。 - トップレベルの OR はサポートされていません。例:
service:A OR service: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 ジェネレーターを使用して繰り返しルールを生成します。一般的な使用例は、毎月第 3 月曜日など、毎月の特定の曜日にダウンタイムを定義するために RRULE を使用することです。繰り返しのさらなる使用例については、ダウンタイムでアラートを抑制するガイドを参照してください。
注: RRULE で期間を指定する属性はサポートされません（例: DTSTART、DTEND、DURATION）。
通知
メッセージの追加
このダウンタイムについてチームに通知するメッセージを入力します。メッセージフィールドでは標準の Markdown フォーマットと Datadog の @-notification 構文が使用できます。フォーマットオプションの詳細については、通知ページを参照してください。
通知と自動化の構成
チームメンバーを指定したり、サービスインテグレーションにメッセージを送信することで、通知と自動化を構成します。Datadog はダウンタイムがスケジュール、開始、キャンセル、または期限切れになるたびに指定された宛先に通知を送信します。これらの監査通知により、チームはシステム内のダウンタイムを認識できます。
最初の回復通知を無効にする
デフォルトでは、Datadog はダウンタイム前にトリガーし、ダウンタイム中に回復するモニターに対して回復通知を送信します。これは、サードパーティのインテグレーションを使用して、開いたインシデントを自動的にクローズする場合に便利です。チェックボックスを選択すると、これらの通知がミュートされます。
最初の回復通知を無効にするオプションは、複数のダウンタイム間で加算されます。例えば、複数のダウンタイムが重なって同じモニターをミュートする場合、少なくとも 1 つのダウンタイムが無効化オプションをチェックすると、最初の回復通知がミュートされます。
注: このオプションは、最初の回復通知をミュートします。ダウンタイム中にモニターがトリガーして再び回復する場合、このオプションの設定に関係なく、対応する通知は常にミュートされます。
管理
Manage Downtimes ページには、アクティブおよびスケジュールされたダウンタイムのリストが表示されます。ダウンタイムを選択して詳細を表示、編集、または削除します。詳細には作成者、スコープ、および適用されるモニターのリストが含まれます。
ファセットパネルと検索バーを使用して、Creator、Scope、Monitor Tags、または Active、Automuted、Recurring パラメーターでリストをフィルタリングします。
履歴
ダウンタイムの履歴は、グループ遷移履歴にオーバーレイされた形で Monitor Status ページで表示でき、Events Explorer で tags:audit downtime を検索することで表示できます。特定のダウンタイムを ID で検索するには、tags:audit downtime_id:<DOWNTIME_ID> を使用します。
ミュート設定
モニターは、ALERT、WARNING、RESOLVED、NO DATA 間でステータスが切り替わる際にイベントをトリガーします。モニターがミュートまたはダウンタイムによってサイレント状態になっている時は、RESOLVED から別の状態に変わっても、イベントや通知はトリガーされません。
注: モニターステータスページからモニターをミュートまたはミュート解除しても、そのモニターに関連付けられたスケジュールされたダウンタイムは削除されません。ダウンタイムを編集または削除するには、Manage Downtimes ページまたは API を使用してください。
有効期限
デフォルトでは、ダウンタイムが終了したときにモニターがアラートに値する状態 (ALERT、WARNING、または NO DATA) にある場合、モニターは新しい通知をトリガーします。これは、ダウンタイム中に状態が変化するモニター (例: OK から ALERT、WARNING、または NO DATA に) や、ダウンタイムが始まるときにすでにアラートに値する状態にあるモニターに適用されます。ダウンタイムが手動でキャンセルされた場合、モニターがアラートに値する状態に入っていても通知は送信されません。
デフォルトの動作を上書きするには、Configure notifications and automations (通知と自動化を構成する) セクションのオプションでダウンタイム終了時に送信する通知を指定します。API で作成されたダウンタイムの場合、デフォルトの動作は Is cancelled オプションを除外します。
例 1: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中も継続した場合:
- ダウンタイム中、このアラートの通知は停止されます。
- モニターはアラートの状態です（依然として条件が満たされているため）。
- ダウンタイムが終了します。
- アラート条件が依然として満たされるため、通知が送信されます。
例 2: モニターがダウンタイムの開始前にアラートの状態で、ダウンタイム中にリカバリした場合:
ALERT 状態から OK に移行します。- ダウンタイム中にリカバリ通知が送信されます（ダウンタイム中最初のリカバリのみ）。
モニターレポート
モニターがダウンタイム中であっても、すべてのアラート状態は週次モニターレポートに含まれます。
オートミュート
Datadog は、特定のクラウドワークロードの手動シャットダウンに関連するモニターをプロアクティブにミュートすることができます。シャットダウンの自動ミュートには、以下のシナリオがサポートされています。
- **Amazon EC2 インスタンス**および CloudWatch API からのホストステータスに基づく AWS オートスケーリングによるインスタンス の終了。
- Google Compute Engine (GCE) インスタンスおよび GCE API からのホストステータスに基づく、GCE オートスケーリングによるインスタンスの終了。
- Azure VM は、手動でのシャットダウンや Azure オートスケーリングによるシャットダウンがトリガーされた場合でも、Azure Resource Health API で利用可能な健全性ステータスに基づきます。
その他の参考資料
