指標ベースのアラート ポリシーの動作

このドキュメントでは、アライメント期間と再テスト ウィンドウによって条件が満たされるタイミングを決定する方法、アラート ポリシーによって複数の条件を組み合わせる方法、アラート ポリシーによって欠落しているデータポイントを置き換える方法について説明します。また、ポリシーに対する対応待ちインシデントの最大数、インシデントごとの通知数、通知の遅延の原因についても説明します。

このコンテンツは、ログベースのアラート ポリシーには適用されません。ログベースのアラート ポリシーの詳細については、ログのモニタリングをご覧ください。

アライメント期間と再テスト ウィンドウ

Cloud Monitoring は、アラート ポリシーの条件が満たされているかどうかを判断する際に、アライメント期間と再テスト ウィンドウを評価します。

アライメント期間

アラート ポリシーで時系列データをモニタリングする前に、アラート ポリシーで評価するデータが一定間隔で取得されるように、データを正規化する必要があります。正則化プロセスはアライメントと呼ばれます。

アライメントには 2 つのステップがあります。

• 時系列を定期的な時間間隔に分割する（データのバケット化とも呼ばれる）。間隔がアライメント期間です。

• アライメント期間のポイントに対して単一の値を計算します。その単一ポイントの計算方法を選択します。すべての値を合計することも、平均を計算することも、最大値を使用することもできます。データポイントを結合する関数は、整列指定子と呼ばれます。組み合わせの結果は、アライメントされた値と呼ばれます。

  アライメントの詳細については、アライメント: 系列内の正則化をご覧ください。

たとえば、アライメント期間が 5 分である午後 1 時の場合、アライメント期間には午後 12 時 55 分から午後 1 時の間に受信したサンプルが含まれます。午後 1 時 1 分では、アライメント期間は 1 分スライドされ、午後 12 時 56 分から午後 1 時 1 分の間に受信したサンプルが含まれます。

モニタリングは、次のように調整期間を構成します。

アラート ポリシーの指標しきい値条件に対するアライメント期間の影響を示すために、サンプリング期間 1 分の指標でモニタリングする条件について考えてみます。アライメント期間を 5 分、整列指定子を sum に設定するとします。また、アライメントされた時系列の値が 2 より大きい状態が 3 分以上継続している場合に条件が満たされているものと仮定し、これは毎分評価されるものとします。この例では、次のセクションで説明する再テスト ウィンドウは 3 分です。次の図は、条件の連続した評価を示しています。

図の各行は 1 回の条件の評価を示しています。時系列データが表示されます。アライメント期間内のポイントは青い点で示され、古い点はすべて黒で表示されます。各行にはアライメントされた値と、この値がしきい値の 2 より大きいかどうかが表示されます。start というラベルの付いた行の場合、アライメントされた値は 1 に計算され、しきい値より小さくなります。次の評価で、アライメント期間のサンプルの合計が 2 になります。3 番目の評価では、合計が 3 となり、この値がしきい値を超えるため、再テスト ウィンドウのタイマーが開始されます。

再テスト ウィンドウ

アラート ポリシーの条件には再テスト ウィンドウがあり、単一の測定値または予測値によって条件が満たされることを防ぎます。たとえば、条件の再テスト ウィンドウが 15 分に設定されているとします。条件のタイプに基づく動作は次のとおりです。

• 指標しきい値条件は、1 つの時系列で 15 分間隔で調整されたすべての測定値がしきい値を超えた場合に条件を満たします。
• 指標なしの条件は、15 分間隔で時系列にデータが届かない場合に条件を満たします。
• 予測条件は、15 分間のウィンドウで生成されたすべての予測で、時系列が予測期間内にしきい値をまたぐと予測された場合に満たされます。

条件が 1 つのポリシーの場合、条件が満たされるとインシデントがオープンになり、通知が送信されます。条件が満たされている間、これらのインシデントはオープンの状態のままになります。

上の図は、指標しきい値条件の 3 つの評価を示しました。start + 2 minutes の時点で、アライメントされた値はしきい値を超えています。ただし、再テスト ウィンドウが 3 分に設定されているため、条件は満たされません。次の図では、条件の次の評価の結果を示しています。

アライメントされた値は start + 2 minutes の時点でしきい値より大きい場合でも、アライメントされた値は 3 分間しきい値を超えるまで条件は満たされません。このイベントは start + 5 minutes の時点で発生します。

測定または予測が条件を満たさないたびに、条件の再テスト ウィンドウはリセットされます。この動作は以下の例に示されています。

例: このアラート ポリシーには、5 分間の再テスト ウィンドウを指定する 1 つの指標しきい値条件が含まれています。

HTTP レスポンスのレイテンシが 2 秒を超え、
レイテンシが 5 分間のしきい値を超える場合、
インシデントを開き、サポートチームにメールを送信します。

次の一連の流れでは、再テスト ウィンドウが条件の評価にどのように影響するかを示します。

1. HTTP レイテンシが 2 秒未満である。
2. 次の連続する 3 分間で、HTTP レイテンシが 2 秒を超える。
3. 次の測定で、レイテンシが 2 秒未満になるため、条件によって再テスト ウィンドウがリセットされる。

4. 次の連続する 5 分間で HTTP レイテンシが 2 秒を超え、条件が満たされる。

   アラート ポリシーには条件が 1 つあるため、条件が満たされると Monitoring が通知を送信します。

再テスト ウィンドウを、誤検出を最小限に抑えるのに十分な長さを確保しながら、インシデントがタイムリーに開かれるように十分に短く設定します。

アライメント期間と再テスト ウィンドウの設定に関するベスト プラクティス

アライメント期間によって、整列指定子と組み合わせられるサンプルの数が決まります。

• 指標タイプのアライメント期間の最小値は、その指標タイプのサンプリング期間です。たとえば、指標タイプが 300 秒ごとにサンプリングされる場合、調整期間は 300 秒以上にします。ただし、5 つのサンプルを結合する場合は、アライメント期間を 5 * 300 秒（1,500 秒）に設定します。

• アライメント期間の最大値は、指標タイプの取り込み遅延から 24 時間を差し引いた値です。たとえば、指標の取り込み遅延が 6 時間の場合、アライメント期間の最大値は 18 時間です。

再審査時間枠を使用して、アラートの応答性を指定します。たとえば、指標の不在条件で再テスト ウィンドウを 20 分に設定した場合、条件が満たされる前の 20 分間はデータが存在しません。アラート ポリシーの応答性を向上させるには、再テスト ウィンドウを小さい値に設定します。指標しきい値条件の場合、アラート ポリシーのレスポンスを最も高くするには、再審査時間枠を 0 に設定します。1 つの調整された値により、これらのタイプの条件が満たされます。

アラート ポリシーの条件は、一定の頻度で評価されます。アラインメント期間と再テスト ウィンドウに対して行う選択は、条件が評価される頻度を決定しません。

複数の条件を持つポリシー

1 つのアラート ポリシーには、最大 6 個の条件を設定できます。

Cloud Monitoring API を使用している場合や、アラート ポリシーに複数の条件がある場合は、インシデントが開始されるタイミングを指定する必要があります。複数条件の組み合わせ方を構成するには、次のいずれかを行います。

次の表では、 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 が満たされます。条件が「いずれかの条件を満たしている」と組み合わされている場合、条件が満たされるためインシデントが作成されます。条件が「すべての条件が満たされている」または「各条件で異なるリソースであってもすべての条件が満たされている」と組み合わされている場合、インシデントは作成されません。これらの combiner の選択では、両方の条件が満たされている必要があります。

次に、vm1 の CPU 使用率が 100 ミリ秒 / 秒を超えた状態が継続し、vm2 の CPU 使用率が 1 分間で 60% を超えたとします。その結果、両方の条件が満たされます。条件がどのように組み合わされているかによって、次のようになります。

• いずれかの条件が満たされた場合: リソースが条件を満たす原因となる場合、インシデントが作成されます。この例では、vm2 が条件 Excessive utilization を満たす原因となります。

  vm2 が条件 CPU usage is too high を満たす原因となった場合、その場合もインシデントが作成されます。インシデントが作成される理由は、vm1 と vm2 が条件 CPU usage is too high を満たす原因となったことが、異なるイベントであるためです。

• すべての条件が満たされている（各条件で異なるリソースの場合でも）: 両方の条件が満たされるため、インシデントが作成されます。

• すべての条件を満たされている: この combiner は、すべての条件が同じリソースによって満たされることを要求するため、インシデントは作成されません。この例では、vm1 で CPU usage is too high が満たされる一方で、vm2 で Excessive utilization が満たされるため、インシデントは作成されません。

部分的な指標データ

時系列データが到着しない、またはデータが遅延すると、Monitoring ではデータの欠落として分類されます。データが欠落していると、インシデントを閉じることができません。サードパーティのクラウド プロバイダからのデータ到着の遅延は 30 分に及ぶ場合があり、5～15 分の遅延が最も一般的です。非常に長い遅延（再テスト ウィンドウより長い）では、条件が「不明」状態になる可能性があります。最終的にデータが到着したときに、Monitoring で条件の最近の履歴の一部が失われている場合があります。データが到着した後では遅延の証拠がないため、時系列データを後で調べてもこの問題が明らかにならないことがあります。

次のいずれかの方法で、データの欠落による問題を最小限に抑えることができます。

• サードパーティ クラウド プロバイダに連絡して、指標収集のレイテンシを低減する方法を確認してください。
• 条件で使用する再テスト ウィンドウを長くします。再テスト ウィンドウを長くすると、アラート ポリシーの応答性が低下するというデメリットがあります。

• 次のような、収集の遅延が少ない指標を選択します。

  • Monitoring エージェントの指標（特に、エージェントがサードパーティのクラウドの VM インスタンス上で実行されている場合）。
  • カスタム指標（データを Monitoring に直接書き込む場合）。
  • ログベースの指標（ログエントリの収集が遅延しない場合）。

詳しくは、モニタリング エージェントの概要、ユーザー定義指標の概要、ログベースの指標をご覧ください。

Monitoring が通知を送信してインシデントを作成する場合

時系列によって条件が満たされると、Cloud Monitoring は通知を送信します。通知はすべての通知チャンネルに送信されます。通知を特定のチャンネルまたはポリシーのチャンネルのサブセットに制限することはできません。

繰り返し通知を構成すると、アラート ポリシーの特定の通知チャンネルに同じ通知が再送信されます。

次のいずれかに該当する場合、1 つのアラート ポリシーに関連する複数の固有の通知を受け取る可能性があります。

• 条件が複数の時系列をモニタリングする。

• ポリシーに複数の条件が含まれている。この場合、受信する通知は、アラート ポリシーの複数条件トリガーの値によって異なります。

  • すべての条件を満たす: すべての条件を満たす場合、条件が満たされた各時系列に対して、アラート ポリシーによって通知が送信され、インシデントが作成されます。

    アラート ポリシーに複数の条件が含まれている場合、インシデントを 1 つだけ作成して通知を 1 つだけ送信するように Cloud Monitoring を構成することはできません。

  • いずれかの条件を満たしている: 時系列が条件を満たすと、アラート ポリシーによって通知が送信されます。

  詳細については、複数の条件を持つポリシーをご覧ください。

Cloud Monitoring API を使用して作成されたアラート ポリシーでは、条件が満たされたときと条件が満たされなくなったときにも通知されます。 Google Cloud コンソールを使用して作成されたアラート ポリシーは、その動作を有効にしない限り、条件が満たされなくなったときに通知を送信しません。

Monitoring が通知を送信せず、インシデントを作成しない場合

次の状況では、アラート ポリシーの条件が満たされても、Monitoring がインシデントを作成することや、通知を送信することはありません。

• アラート ポリシーが無効になっている。
• アラート ポリシーがスヌーズされている。
• Monitoring が、対応待ちインシデントの最大数の上限に達した。

無効化されたアラート ポリシー

モニタリングでは、無効になっているアラート ポリシーに対してインシデントの作成や通知の送信は行われません。ただし、Monitoring は無効にしたアラート ポリシーの条件の評価を続けます。

無効化されたポリシーを有効にした場合、Monitoring により最新の再テスト ウィンドウでのすべての条件の値が検査されます。最新の再テスト ウィンドウには、ポリシーが有効になる前、途中、および後に取得されたデータが含まれる場合があります。無効化されたポリシーの条件は、ポリシーの再開直後に満たすことができます。これは、再テスト ウィンドウが長い場合でも同じです。

たとえば、特定のプロセスをモニタリングするアラート ポリシーがあり、このポリシーを無効にしたとします。翌週にはプロセスが停止し、アラート ポリシーが無効のため通知されません。プロセスを再起動してすぐにアラート ポリシーを有効にすると、Monitoring はプロセスが過去 5 分間稼働していないことを認識し、インシデントをオープンにします。

無効にしたアラート ポリシーに関連するインシデントは、ポリシーの自動クローズ期間が終了するまでオープンのままになります。

スヌーズされたアラート ポリシー

モニタリングでは、スヌーズされたアラート ポリシーに対して通知を送信することや、インシデントを作成することはありません。アラート ポリシーが短い間隔でのみ通知を送信するのを防ぐには、アラート ポリシーをスヌーズすることをおすすめします。たとえば、仮想マシン（VM）のメンテナンスを行う前に、スヌーズを作成し、スヌーズの条件にインスタンスをモニタリングするアラート ポリシーを追加できます。

アラート ポリシーをスヌーズすると、モニタリングによってポリシーに関連する対応待ちのインシデントがすべてクローズされます。スヌーズの期限が切れると、Monitoring によって新しいインシデントが開かれることがあります。詳しくは、通知とアラートをスヌーズするをご覧ください。

通知と対応待ちのインシデントの制限事項

アラート ポリシーは多くのリソースに適用できるため、リソース全体に影響を及ぼす問題がアラート ポリシーによって各リソースのインシデントを開く可能性があります。インシデントは、条件が満たされている時系列ごとに開かれます。

システムの過負荷を防ぐため、1 つのポリシーの対応待ちインシデントの数は 1,000 に制限されています。

たとえば、2,000 個の Compute Engine インスタンスに適用されるポリシーがあり、各インスタンスでアラートの条件が満たされるとします。Monitoring では、対応待ちインシデントの数を 1,000 に制限しています。ポリシーに対する対応待ちのインシデントが閉じられるまで、満たされている残りの条件はどれも無視されます。

この制限により、1 つの通知チャンネルは一度に最大 1,000 件の通知を受信できます。アラート ポリシーに複数の通知チャンネルがある場合、この制限は各通知チャンネルに個別に適用されます。

レイテンシ

レイテンシとは、Monitoring が指標をサンプリングしてから、指標データポイントが時系列データとして表示されるまでの遅延を指します。レイテンシは、通知が送信されるタイミングに影響します。たとえば、モニタリング対象指標のレイテンシが最大 180 秒の場合、アラート ポリシー条件が true と評価されてから最大 180 秒間、モニタリングによってインシデントが作成されません。詳しくは、指標データのレイテンシをご覧ください。

次のイベントと設定がレイテンシに影響します。

• 指標収集の遅延: Monitoring が指標値を収集するために必要とする時間。 Google Cloud 値の場合、ほとんどの指標は収集後 60 秒間表示されません。ただし、その遅れは指標によって異なります。アラート ポリシーの計算には、さらに最大 5 分 30 秒の遅延が発生します。AWS CloudWatch 指標の場合、表示に関わる遅延が数分になることがあります。稼働時間チェックでは、これは（再テスト ウィンドウの最後から）平均で 2 分になります。

• 再テスト ウィンドウ: 条件用に構成された時間枠。再テスト ウィンドウ全体にわたって条件が真である場合にのみ、条件が満たされます。たとえば、再テスト ウィンドウを 5 分に設定すると、イベントが最初に発生したときから少なくとも 5 分後に通知の遅延が発生します。

• 通知の到着時間: メールや SMS などの通知チャネル自体に、ネットワークやその他の遅延（配信される内容とは関係なく）が発生することがあり、場合によっては分単位になります。SMS や Slack などの一部のチャネルでは、メッセージが配信される保証はありません。

次のステップ

• アラート ポリシーの作成方法については、次のドキュメントをご覧ください。

  • 指標しきい値のアラート ポリシーを作成する
  • 指標なしのアラート ポリシーを作成する
  • 予測指標値のアラート ポリシーを作成する
  • Monitoring API を使用してアラート ポリシーを作成する

• アラート ポリシーの詳細については、サンプル ポリシーをご覧ください。