このドキュメントでは、アライメント期間と期間の設定によって条件がトリガーされるタイミングを決定する方法、アラート ポリシーによって複数の条件を組み合わせる方法、アラート ポリシーによって欠落しているデータポイントを置き換える方法について説明します。また、ポリシーに対する対応待ちインシデントの最大数、インシデントごとの通知数、通知の遅延の原因についても説明します。
このコンテンツは、ログベースのアラート ポリシーには適用されません。ログベースのアラート ポリシーの詳細については、ログのモニタリングをご覧ください。
アライメント期間と長さの設定
アライメント期間と期間枠は、アラート ポリシーの条件を指定するときに設定する 2 つのフィールドです。このセクションでは、これらのフィールドの意味を簡潔に説明します。
アライメント期間
アライメント期間とは、特定の時点から振り返った過去の一定の間隔です。整列指定子は、各点をその間隔に集約して 1 つの調整値に変える関数です。 たとえば、アライメント期間が 5 分である午後 1 時の場合、アライメント期間には午後 12 時 55 分から午後 1 時の間に受信したサンプルが含まれます。午後 1 時 1 分では、アライメント期間は 1 分スライドされ、午後 12 時 56 分から午後 1 時 1 分の間に受信したサンプルが含まれます。
Google Cloud コンソール
アライメント フィールドは、[新しい条件] ダイアログの一部である [ローリング ウィンドウ] メニューと [ローリング ウィンドウ関数] メニューで構成します。
使用可能な関数の詳細については、API リファレンスの Aligner をご覧ください。一部の整列指定子関数では、データの整列と別の種類の指標への変換の両方が行われます。詳細については、種類、タイプ、変換をご覧ください。
API
アライメント フィールドは、MetricThreshold および MetricAbsence 構造の aggregations.alignmentPeriod および aggregations.perSeriesAligner フィールドを設定して構成します。
使用可能な関数の詳細については、API リファレンスの Aligner をご覧ください。一部の整列指定子関数では、データの整列と別の種類の指標への変換の両方が行われます。詳細については、種類、タイプ、変換をご覧ください。
アラート ポリシーの指標しきい値条件に対するアライメント期間の影響を示すために、サンプリング期間 1 分の指標でモニタリングする条件について考えてみます。アライメント期間を 5 分、整列指定子を sum に設定するとします。また、時系列のアライメントされた値が少なくとも 3 分間で 2 より大きい場合に条件がトリガーされ、1 分ごとに条件が評価されると仮定します。次の図は、条件の連続した評価を示しています。
図の各行は 1 回の条件の評価を示しています。時系列データが表示されます。アライメント期間内のポイントは青い点で示され、古い点はすべて黒で表示されます。各行にはアライメントされた値と、この値がしきい値の 2 より大きいかどうかが表示されます。start というラベルの付いた行の場合、アライメントされた値は 1 に計算され、しきい値より小さくなります。次の評価で、アライメント期間のサンプルの合計が 2 になります。3 番目の評価では、合計が 3 になります。この値はしきい値より大きいため、期間のタイマーが開始されます。
時間枠
単一の測定値または予測値によって条件がトリガーされないようにするには、期間（時間枠）を使用します。たとえば、条件の duration フィールドが 15 分に設定されているとします。以下では、条件に基づく条件の動作を説明します。
- 指標しきい値条件は、1 つの時系列で 15 分間隔で調整されたすべての測定値がしきい値を超えた場合にトリガーされます。
- 指標の不在条件は、15 分間隔で時系列のデータを受信しない場合にトリガーされます。
- [予測条件] は、15 分間に生成されたすべての予測が、時系列が予測ウィンドウ内のしきい値に違反すると予測した場合にトリガーされます。
条件が 1 つのポリシーの場合、インシデントが開かれ、条件がトリガーされたときに通知が送信されます。条件が満たされている間、これらのインシデントは開いたままになります。
Google Cloud コンソール
時間枠を構成するには、[トリガーを構成] ステップの [再テストの時間枠] フィールドを使用します。
API
期間時間枠を構成するには、MetricThreshold 構造と MetricAbsence 構造の duration フィールドを設定します。
上の図は、指標しきい値条件の 3 つの評価を示しました。start + 2 minutes の時点で、アライメントされた値はしきい値を超えています。ただし、期間時間枠が 3 分に設定されているため、条件は満たされません。次の図では、条件の次の評価の結果を示しています。
アライメントされた値は start + 2 minutes の時点でしきい値より大きい場合でも、アライメントされた値は 3 分間しきい値を超えるまで条件は満たされません。このイベントは start + 5 minutes の時点で発生します。
測定値または予測が条件を満たさないたびに、期間時間枠はリセットされます。この動作は以下の例に示されています。
例: このアラート ポリシーには、5 分間の時間枠を指定する 1 つの指標しきい値条件が含まれています。
HTTP レスポンスのレイテンシが 2 秒を超え、
レイテンシが 5 分間のしきい値を超える場合、
インシデントを開き、サポートチームにメールを送信します。次の一連の流れは、期間時間枠が条件の評価にどのように影響するかを示しています。
- HTTP レイテンシが 2 秒未満である。
- 次の連続する 3 分間で、HTTP レイテンシが 2 秒を超える。
- 次の測定で、レイテンシが 2 秒未満になるため、条件によって期間時間枠がリセットされる。
次の連続する 5 分間で HTTP レイテンシが 2 秒を超えるため、条件がトリガーされます。
ポリシーには条件が 1 つあるため、条件がトリガーされたときにインシデントが開始され、通知が送信されます。
期間時間枠を、誤検出を最小限に抑えるのに十分な長さを確保しながら、インシデントがタイムリーに開かれるように十分に短く設定する。
アライメント期間と期間時間枠を選択する
常にアライメント期間を設定します。これにより、整列指定子と組み合わせられるサンプルの数が、サンプリング期間と同じかそれ以上に決まります。5 つのサンプルを組み合わせるには、アライメント期間はサンプリング期間の 5 倍に設定します。
期間時間枠を使用して、アラートの応答性を指定します。たとえば、指標の不在条件で期間時間枠を 20 分に設定した場合、条件が満たされる前の 20 分間はデータが存在しません。より応答性の高いアラートが必要な場合は、期間をより小さな値に設定します。指標しきい値条件の場合は、最も応答性の高いアラートを得るために、期間をゼロに設定します。1 つのアライメント値によって、これらのタイプの条件がトリガーされます。
アラート ポリシーの条件は、一定の頻度で評価されます。アラインメント期間と期間時間枠に対して行う選択は、条件が評価される頻度を決定しません。
複数の条件を持つポリシー
1 つの アラート ポリシーには、最大 6 個の条件を含めることができます。
Cloud Monitoring API を使用している場合や、アラート ポリシーに複数の条件がある場合は、インシデントが開始されるタイミングを指定する必要があります。複数条件の組み合わせ方を構成するには、次のいずれかを行います。
Google Cloud コンソール
コンバイナ オプションは、[複数条件トリガー] ステップで構成します。
API
コンバイナ オプションは、AlertPolicy 構造の [combiner] フィールドで構成します。
次の表では、Google Cloud コンソールの設定、Cloud Monitoring API での同等の値、各設定の説明を示します。
| Google Cloud コンソール ポリシーによって値がトリガーされます |
Cloud Monitoring API combiner の値 |
意味 |
|---|---|---|
| いずれかの条件が満たされている | OR |
いずれかのリソースがいずれかの条件を満たすと、インシデントが開かれます。 |
| 条件ごとに異なる リソースであっても すべての条件が満たされている （デフォルト） |
AND |
インシデントは、各条件が満たされた場合に開かれます。異なるリソースによってこれらの条件が満たされた場合でも、インシデントは開かれます。 |
| すべての条件が満たされている | AND_WITH_MATCHING_RESOURCE |
同じリソースが各条件を満たすと、インシデントが開かれます。この設定は、最も厳密な組み合わせ選択です。 |
このコンテキストで、met という用語は、条件の構成が true と評価されることを意味します。たとえば、構成が Any time series is greater than 10 for 5 minutes の場合で、このステートメントが true と評価されたとき、条件は満たされています。
例
vm1 と vm2 の 2 つの VM インスタンスを含む Google Cloud プロジェクトについて考えます。また、次の 2 つの条件でアラート ポリシーを作成するとします。
CPU usage is too highという名前の条件は、インスタンスの CPU 使用量をモニタリングします。この条件は、いずれかのインスタンスの CPU 使用率が 1 分間で 100 ミリ秒/秒を超えた場合に満たされます。Excessive utilizationという名前の条件は、インスタンスの CPU 使用率をモニタリングします。この条件は、いずれかのインスタンスの CPU 使用率が 1 分間で 60% を超えた場合に満たされます。
最初は、両方の条件が false と評価されることを前提としています。
次に、vm1 の CPU 使用量が 1 分間 100 ミリ秒/秒を超えたとします。CPU 使用率が 1 分間のしきい値を超えているため、条件 CPU usage is too high を満たします。条件が「いずれかの条件を満たしている」と組み合わされている場合、条件が満たされるためインシデントが作成されます。条件が「すべての条件を満たしている」または「各条件で異なるリソースであってもすべての条件を満たしている」と組み合わされている場合、インシデントは作成されません。これらの組み合わせを選択している場合は、両方の条件が満たされる必要があります。
次に、vm1 の CPU 使用率が 100 ミリ秒 / 秒を超えた状態が継続し、vm2 の CPU 使用率が 1 分間で 60% を超えたとします。その結果、両方の条件が満たされます。条件がどのように組み合わされているかによって、次のようになります。
いずれかの条件を満たしている: リソースが条件を満たすとインシデントが作成されます。この例では、vm2 は条件
Excessive utilizationを満たします。vm2 によって条件
CPU usage is too highが満たされると、インシデントも作成されます。条件CPU usage is too highが満たされる vm1 と vm2 は別々のイベントであるため、インシデントが作成されます。各条件で異なるリソースであってもすべての条件を満たしている: 両方の条件が満たされるため、インシデントが作成されます。
すべての条件を満たしている: 同じリソースですべての条件が満たされることが必要なため、インシデントは作成されません。この例では、vm1 で
CPU usage is too highが満たされ、vm2 でExcessive utilizationが満たされるため、インシデントは作成されません。
部分的な指標データ
時系列データが到着しない、またはデータが遅延すると、Monitoring ではデータが欠落していると分類されます。データが欠落していると、ポリシーによってアラートされなくなり、インシデントが閉じられなくなる可能性があります。サードパーティのクラウド プロバイダからのデータ到着の遅延は 30 分に及ぶ場合があり、5～15 分の遅延が最も一般的です。非常に長い遅延（期間時間枠より長い）では、条件が「不明」状態になる可能性があります。最終的にデータが到着したときに、Monitoring で条件の最近の履歴の一部が失われている場合があります。データが到着した後では遅延の証拠がないため、時系列データを後で調べてもこの問題が明らかにならないことがあります。
Google Cloud コンソール
データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか？同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか？最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか？
データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。
欠落データを置換する値を Monitoring が決める仕組みを構成するには、[条件トリガー] ステップで設定した [欠落データの評価] フィールドを使用します。再テスト ウィンドウが [再テストなし] に設定されている場合、このフィールドは無効になります。
データの受信が止まってから対応待ちのインシデントを閉じるまで Monitoring が待機する時間を構成するには、[Incident autoclose duration] フィールドを使用します。[通知] ステップで自動クローズの期間を設定します。デフォルトの自動クローズ期間は 7 日間です。
欠落データ フィールドに関するさまざまなオプションは次のとおりです。
| Google Cloud コンソール [欠落データの評価] フィールド |
Summary | 詳細 |
|---|---|---|
| 欠落データがない | 対応待ちのインシデントはオープンのままです。 新しいインシデントはオープンされません。 |
条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、データが送られてこない場合、自動クローズ タイマーは 15 分以上の時間をおいて開始されます。タイマーの期限が切れると、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。 |
| 欠落データポイントが、ポリシーに違反する値として扱われる | 対応待ちのインシデントはオープンのままです。 新しいインシデントをオープンできます。 |
条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータが到着しない場合、インシデントはクローズされます。 条件が満たされない場合は、この設定により、指標しきい値の条件が |
| 欠落データポイントが、ポリシーに違反しない値として扱われる | 対応待ちのインシデントはクローズされます。 新しいインシデントはオープンされません。 |
条件が満たされている場合、データの受信が停止すると、その条件は満たされなくなります。この条件のインシデントが対応待ちの場合、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。 |
API
データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか？同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか？最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか？
データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。
欠落データを置換する値を Monitoring が決める仕組みを構成するには、
MetricThreshold構造のevaluationMissingDataフィールドを使用します。durationフィールドがゼロの場合、このフィールドは無視されます。データが到着しなくなった後に対応待ちのインシデントを閉じるまで Monitoring が待機する時間を構成するには、
AlertStrategy構造のautoCloseフィールドを使用します。
欠落データ フィールドに関するさまざまなオプションは次のとおりです。
APIevaluationMissingData フィールド |
概要 | 詳細 |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
対応待ちのインシデントはオープンのままです。 新しいインシデントはオープンされません。 |
条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、データが送られてこない場合、自動クローズ タイマーは 15 分以上の時間をおいて開始されます。タイマーの期限が切れると、インシデントはクローズされます。 条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。 |
EVALUATION_MISSING_DATA_ACTIVE |
対応待ちのインシデントはオープンのままです。 新しいインシデントをオープンできます。 |
条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータを受信しない場合、インシデントはクローズされます。 条件が満たされない場合は、この設定により、指標しきい値の条件が |
EVALUATION_MISSING_DATA_INACTIVE |
対応待ちのインシデントはクローズされます。 新しいインシデントはオープンされません。 |
条件が満たされている場合、データの受信が停止すると、その条件は満たされなくなります。この条件のインシデントが対応待ちの場合、インシデントはクローズされます。 条件が満たされていない場合、データの到着が停止したとき、条件は引き続き満たされません。 |
次のいずれかの方法で、データの欠落による問題を最小限に抑えることができます。
- サードパーティ クラウド プロバイダに連絡して、指標収集のレイテンシを低減する方法を確認してください。
- 条件で使用する期間時間枠を長くします。期間時間枠を拡張すると、アラート ポリシーの応答性が低下するというデメリットがあります。
次のような、収集の遅延が少ない指標を選択します。
- Monitoring エージェントの指標（特に、エージェントがサードパーティのクラウドの VM インスタンス上で実行されている場合）。
- カスタム指標（データを Cloud Monitoring に直接書き込む場合）。
- ログベースの指標（ログ収集が遅延しない場合）。
詳しくは、モニタリング エージェントの概要、ユーザー定義指標の概要、ログベースの指標をご覧ください。 。
ポリシーごとの通知とインシデント
Monitoring でインシデントが作成されてアラート ポリシーの通知が送信されないようにするため、そのポリシーは無効にすることをおすすめします。スヌーズを作成して、ポリシーを検索条件に含めることもできます。スヌーズが有効の場合、そのポリシーでは、インシデントの作成も通知の送信も行われません。
ポリシーが有効で、有効なスヌーズの条件と一致しない場合は、インシデントが作成され、通知が送信されることがあります。このセクションでは、ポリシーごとの対応待ちインシデント数の上限と、同じインシデントに複数の通知が表示されるタイミングついて説明します。
ポリシーごとの対応待ちインシデント数
アラート ポリシーは多くのリソースに適用できるため、リソース全体に影響を及ぼす問題が発生してポリシーがトリガーされると、リソースごとに対応待ちのインシデントが生じる可能性があります。インシデントは、条件が満たされている時系列ごとに開かれます。
システムの過負荷を防ぐため、1 つのポリシーの対応待ちインシデントの数は 1,000 に制限されています。
たとえば、2,000（または 20,000）個の Compute Engine インスタンスに適用されるポリシーがあり、各インスタンスでアラートの条件が満たされるとします。Monitoring では、対応待ちインシデントの数を 1,000 に制限しています。ポリシーに対する対応待ちのインシデントが閉じられるまで、満たされている残りの条件はどれも無視されます。
ポリシーごとの通知数
デフォルトでは、時系列によって条件がトリガーされると通知が送信されます。次のいずれかに該当する場合、複数の通知が送信されることがあります。
条件は、複数の時系列をモニタリングします。
ポリシーには複数の条件が含まれている。
すべての条件を満たしている: すべての条件がトリガーされると、条件がトリガーされる時系列ごとに、ポリシーによって通知が送信され、インシデントが作成されます。たとえば、2 つの条件を持つポリシーがあり、各条件が 1 つの時系列をモニタリングしているとします。 すべての条件がトリガーされると、2 つの通知が送信され、2 つのインシデントが表示されます。
いずれかの条件が満たされる: 条件がトリガーされるたびに、ポリシーによって通知が送信されます。たとえば、2 つの条件を持つポリシーがあり、各条件が 1 つの時系列をモニタリングしているとします。 最初の条件がトリガーされたと仮定します。インシデントが開かれ、通知が送信されます。その後の測定で 2 番目の条件がトリガーされたときにインシデントがオープンのままの場合は、別の通知が送信されます。
Cloud Monitoring API を使用して作成されたアラート ポリシーでは、条件がトリガーされたときと条件が満たされなくなったときに通知されます。デフォルトの場合、Google Cloud コンソールを使用して作成されたアラート ポリシーでは、インシデントがオープンされたときに通知されます。インシデントのクローズ時には、通知されません。インシデントのクローズ時の通知は、有効にすることもできます。
無効化されたアラート ポリシーの通知
アラート ポリシーを無効にしても、ポリシーは条件の評価を続けます。ただし、インシデントは作成されず、通知も送信されません。
無効化されたポリシーを有効にした場合、Monitoring により最新の時間枠でのすべての条件の値が検査されます。直近の期間には、ポリシーが有効になる前、途中、および後に取得されたデータが含まれる場合があります。ポリシーは、時間枠が長い場合でも、再開直後にトリガーされる可能性があります。
たとえば、特定のプロセスをモニタリングするアラート ポリシーがあり、このポリシーを無効にしたとします。翌週にはプロセスが停止し、ポリシーが無効のため通知されません。プロセスを再起動してすぐにアラート ポリシーを有効にすると、Monitoring はプロセスが過去 5 分間稼働していないことを認識し、インシデントをオープンにします。
アラート ポリシーを無効にしても、インシデントはミュートしない限り、対応待ちのままになります。インシデントをミュートすると、同じ条件で対応待ちのインシデントがすべてクローズされます。この処理の詳細については、インシデントのミュートをご覧ください。
有効なスヌーズの条件に一致するポリシーの通知
アラート ポリシーによる短い間隔での通知の送信を防ぐには、ポリシーを無効にするのではなく、スヌーズを作成することをおすすめします。たとえば、仮想マシン（VM）のメンテナンスを行う前に、スヌーズを作成し、スヌーズの条件にインスタンスをモニタリングするアラート ポリシーを追加できます。
アラート ポリシーの条件がトリガーされ、そのポリシーがアクティブなスヌーズの条件と一致する場合、インシデントは作成されず、通知は送信されません。スヌーズの期限が切れると、ポリシーはインシデントを作成し、通知を送信できます。
繰り返し通知を送信する
対応待ちの確認済みインシデントの通知受信者にリマインダーを送信するには、繰り返し通知を設定します。この機能は、リソース不足でサービス障害を引き起こす可能性がある重要なリソースをモニタリングするアラート ポリシーに役立ちます。たとえば、空きディスク容量をモニタリングするアラート ポリシーに対して、繰り返し通知を設定できます。
デフォルトでは、アラート ポリシーはインシデントが開かれたときに各通知チャネルに 1 つの通知を送信します。ただし、デフォルトの動作を変更して、アラート ポリシー通知チャネルのすべてまたは一部に通知を再送信するようにアラート ポリシーを構成できます。これらの繰り返し通知は、ステータスが [対応待ち] または [確認済み] のインシデントに送信されます。これらの通知の間隔は 30 分以上 24 時間以内で、秒単位で表されます。
Google Cloud コンソール
Google Cloud コンソールで繰り返し通知を構成することはできません。代わりに Google Cloud CLI または API を使用してください。
API
AlertStrategy オブジェクトに少なくとも 1 つの NotificationChannelStrategy オブジェクトを追加します。NotificationChannelStrategy オブジェクトには次の 2 つのフィールドがあります。
renotifyInterval: 繰り返し通知の間隔（秒）。renotifyIntervalフィールドの値はいつでも変更できます。間隔を変更したときにアラート ポリシーに関連するインシデントが対応待ちの場合、ポリシーはインシデントに対して別の通知を送信し、間隔を再開します。notificationChannelNames: 通知チャネルのリソース名の配列。projects/PROJECT_ID/notificationChannels/CHANNEL_ID形式の文字列です。これらの通知チャネルは、renotifyInterval値で定義された間隔で繰り返し通知を受け取ります。リソース名のチャネル ID は数値です。チャネル ID を取得する方法については、プロジェクト内の通知チャネルを一覧表示するをご覧ください。
たとえば、次の JSON サンプルは、1,800 秒（30 分）ごとに繰り返し通知を一覧にある通知チャネルに送信するように構成されたアラート戦略を示しています。
"alertStrategy": {
"notificationChannelStrategy": [
{
"notificationChannelNames": [
"projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
],
"renotifyInterval": "1800s"
}
]
}
API を使用してアラート ポリシーを作成する方法の詳細については、API によりアラート ポリシーを作成するをご覧ください。
繰り返し通知を一定期間停止するには、アラート ポリシーのスヌーズを無効にするか、作成します。繰り返し通知を完全に停止するには、API を使用してアラート ポリシーを編集し、NotificationChannelStrategy オブジェクトを削除します。
通知レイテンシ
通知レイテンシは、問題が最初に発生したときからポリシーがトリガーされるときまでの遅延です。
次のイベントと設定が、通知レイテンシ全体に影響します。
指標収集の遅延: Cloud Monitoring が指標値を収集するために必要とする時間。Google Cloud の値の場合、ほとんどの指標は収集後 60 秒間表示されません。ただし、その遅れは指標によって異なります。アラート ポリシーの計算には、さらに 60～90 秒の遅延が発生します。AWS CloudWatch 指標の場合、表示に関わる遅延が数分になることがあります。稼働時間チェックでは、これは（時間枠の最後から）平均で 2 分になります。
期間時間枠: 条件用に構成された時間枠。 時間枠全体にわたって条件が真である場合にのみ、条件が満たされます。たとえば、時間枠を 5 分に設定すると、イベントが最初に発生したときから少なくとも 5 分後に通知の遅延が発生します。
通知の到着時間: メールや SMS などの通知チャネル自体に、ネットワークやその他の遅延（配信される内容とは関係なく）が発生することがあり、場合によっては分単位になります。SMS や Slack などの一部のチャネルでは、メッセージが配信される保証はありません。
次のステップ
アラート ポリシーを作成する方法については、次のドキュメントをご覧ください。
アラート ポリシーの詳細については、サンプル ポリシーをご覧ください。