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

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

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

アライメント期間と期間の設定

アライメント期間と期間枠は、アラート ポリシーの条件を指定するときに設定する 2 つのフィールドです。このセクションでは、これらのフィールドの意味を簡潔に説明します。

アライメント期間

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

アラート ポリシーの条件に対するアライメント期間の影響を示すために、サンプリング期間 1 分の指標でモニタリングする条件について考えてみます。アライメント期間を 5 分、整列指定子を sum に設定するとします。時系列のアライメントされた値が 3 分間以上の時間で 2 より大きい場合に、条件は met または active として記述されます。この例では、条件が 1 分ごとに評価されると仮定します。

次の図は、条件の連続した評価を示しています。

アライメント期間の影響を示す図。

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

期間時間枠

単一の測定値が原因で条件が満たされることを防ぐには、期間(期間時間枠)を使用します。Google Cloud Console では、次のフィールドを使用して期間を構成します。

以前のインターフェース

期間時間枠を構成するには、アラート ポリシーの [構成] ペインの [For] フィールドを使用します。

プレビューのインターフェース

期間時間枠を構成するには、[トリガーを構成] ステップの [再テストの時間枠] フィールドを使用します。

API

期間時間枠を構成するには、MetricThreshold 構造と MetricAbsence 構造の duration フィールドを設定します。

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

期間時間枠の影響を示す図。

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

前の例では、わかりやすくするために、複数の時系列のアライメント済みデータポイントを 1 つの測定にまとめる可能性を排除しています。その測定値は、条件が満たされているかどうかを判定するためにしきい値と比較されます。

測定が条件を満たさないたびに、期間時間枠はリセットされます。この動作は以下の例に示されています。

: このポリシーでは、5 分間の期間時間枠を指定します。

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

次の一連の流れは、期間時間枠が条件の評価にどのように影響するかを示しています。

  1. HTTP レイテンシが 2 秒未満である。
  2. 次の連続する 3 分間で、HTTP レイテンシが 2 秒を超える。
  3. 次の測定で、レイテンシが 2 秒未満になるため、条件によって期間時間枠がリセットされる。
  4. 次の連続する 5 分間で HTTP レイテンシが 2 秒を超えるため、条件が満たされ、ポリシーがトリガーされます。

期間時間枠を、誤検出を最小限に抑えるのに十分な長さを確保しながら、インシデントがタイムリーに開かれるように十分に短く設定する。

アライメント期間と期間時間枠を選択する

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

図は、アライメント期間によって、整列指定子と結合するデータサンプルの数が決定されることを示しています。多数のサンプルを組み合わせるには、長い期間を選択します。間隔を 1 つのサンプルに限定するには、短い期間を選択します。対照的に、期間時間枠では、条件が満たされるのに必要な値がしきい値を超えるまでの時間を指定します。アライメントされた単一の値がしきい値より大きい場合に条件が満たされるようにするには、期間時間枠をゼロに設定します。

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

1 つの アラート ポリシーには、最大 6 個の条件を含めることができます。

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

以前のインターフェース

コンバイナ オプションは、[ポリシーのトリガー] フィールドで構成します。

プレビューのインターフェース

コンバイナ オプションは、[複数条件トリガー] ステップで構成します。

API

コンバイナ オプションは、AlertPolicy 構造の [combiner] フィールドで構成します。

この表に、Cloud Console の設定、Cloud Monitoring API での同等の値、各設定の説明を一覧表示します。

Cloud Console
ポリシーによって値がトリガーされます
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 で条件の最近の履歴の一部が失われている場合があります。データが到着した後では遅延の証拠がないため、時系列データを後で調べてもこの問題が明らかにならないことがあります。

以前のインターフェース

データが到着しなくなったときに Monitoring が対応待ちのインシデントを閉じるまでの待機時間を構成できます。ただし、欠落データの置換値を Monitoring が選択する方法を構成することはできません。

データの受信が停止した後に対応待ちのインシデントを閉じるまでに Monitoring が待機する時間を構成するには、[Incident autoclose duration] フィールドを使用します。通知ステップで自動クローズの期間を設定します。デフォルトの自動クローズ期間は 7 日間です。

プレビューのインターフェース

データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか?同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか?最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか?

データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。

  • 欠損データの置換値を Monitoring が決定する方法を構成するには、[条件トリガー] ステップで設定した [評価の欠損データ] フィールドを使用します。再テストの時間枠が [再テストなし] に設定されている場合、このフィールドは無効になります。

  • データの受信が停止した後に対応待ちのインシデントを閉じるまでに Monitoring が待機する時間を構成するには、[Incident autoclose duration] フィールドを使用します。通知ステップで自動クローズの期間を設定します。デフォルトの自動クローズ期間は 7 日間です。

欠落データ フィールドのさまざまなオプションは次のとおりです。

Cloud Console
[欠落データの評価] フィールド
概要 詳細
欠落データがない 対応待ちのインシデントはオープンのままです。
新しいインシデントはオープンされません。

条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ち状態であり、自動クローズ期間にデータを受信しない場合、インシデントはクローズされます。

条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。

欠落データポイントが、ポリシーに違反する値として扱われる 対応待ちのインシデントはオープンのままです。
新しいインシデントをオープンできます。

条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータが到着しない場合、インシデントはクローズされます。

条件が満たされていない場合、この設定により、指標しきい値条件が指標不在条件のように動作します。再テストの時間枠で指定された時間内にデータを受信しない場合、条件は満たされたものとして評価されます。1 つの条件のアラート ポリシーの場合、条件が満たされるとインシデントが開かれます。

欠落データポイントが、ポリシーに違反しない値として扱われる 対応待ちのインシデントはクローズされます。
新しいインシデントはオープンされません。

条件が満たされている場合、条件は、データの受信が停止すると満たされなくなります。この条件でインシデントが対応待ちの場合、インシデントはクローズされます。

条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。

API

データの到着が停止した場合に Monitoring で指標しきい値の条件を評価する方法を構成できます。たとえば、インシデントが対応待ちで、予想される測定値が届かない場合、Monitoring でインシデントを開いたままにするか、すぐにクローズしますか?同様に、データの到着が停止し、対応待ちのインシデントがない場合、インシデントをオープンしますか?最後に、データの到着が停止した後、インシデントをオープンにしておく期間はどれくらいですか?

データが到着しなくなったときに Monitoring で指標しきい値の条件を評価する方法を指定する 2 つの構成可能なフィールドがあります。

  • 欠落データの置換値を Monitoring が決定する方法を構成するには、MetricThreshold 構造の evaluationMissingData フィールドを使用します。期間フィールドがゼロの場合、このフィールドは無視されます。

  • データが到着しなくなった後に対応待ちのインシデントを閉じるまで Monitoring が待機する時間を構成するには、AlertStrategy 構造の autoClose フィールドを使用します。

欠落データ フィールドのさまざまなオプションは次のとおりです。

API
      evaluationMissingData フィールド
概要 詳細
EVALUATION_MISSING_DATA_UNSPECIFIED 対応待ちのインシデントはオープンのままです。
新しいインシデントはオープンされません。

条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ち状態であり、自動クローズ期間にデータを受信しない場合、インシデントはクローズされます。

条件が満たされていない場合、データが到着しなくなっても、条件は引き続き満たされません。

EVALUATION_MISSING_DATA_ACTIVE 対応待ちのインシデントはオープンのままです。
新しいインシデントをオープンできます。

条件が満たされている場合、データが到着しなくなっても、条件は引き続き満たされます。この条件でインシデントが対応待ちの場合、インシデントは対応待ちのままになります。インシデントが対応待ちで、自動クローズ期間に 24 時間を加えた期間にデータを受信しない場合、インシデントはクローズされます。

条件が満たされていない場合、この設定により、指標しきい値条件が指標不在条件のように動作します。再テストの時間枠で指定された時間内にデータを受信しない場合、条件は満たされたものとして評価されます。1 つの条件のアラート ポリシーの場合、条件が満たされるとインシデントが開かれます。

EVALUATION_MISSING_DATA_INACTIVE 対応待ちのインシデントはクローズされます。
新しいインシデントはオープンされません。

条件が満たされている場合、条件は、データの受信が停止すると満たされなくなります。この条件でインシデントが対応待ちの場合、インシデントはクローズされます。

条件が満たされていない場合、データの到着が停止したとき、条件は引き続き満たされません。

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

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

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

詳細については、モニタリング エージェントの概要カスタム指標の使用ログベースの指標をご覧ください。

ポリシーごとの通知とインシデント

アラート ポリシーが無効になっている場合、ポリシーのインシデントは作成されず、通知は送信されません。

アラート ポリシーを有効にすると、インシデントを作成し、通知を送信できます。このセクションでは、ポリシーごとの対応待ちインシデントの数と、同じインシデントに複数の通知が表示される場合の制限について説明します。

ポリシーごとの対応待ちのインシデント数

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

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

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

インシデントごとの通知数

デフォルトでは、時系列によって条件が満たされると、通知が送信されます。次のいずれかに該当する場合は、複数の通知を受け取る可能性があります。

  • 条件は、複数の時系列をモニタリングします。

  • ポリシーには複数の条件が含まれています。

    • すべての条件が満たされている場合、条件が満たされるたびに、ポリシーによって通知が送信され、インシデントが作成されます。たとえば、2 つの条件を持つポリシーがあり、各条件が 1 つの時系列をモニタリングしているとします。このポリシーがトリガーされると、2 つの通知が送信され、2 つのインシデントが表示されます。

    • いずれかの条件が満たされる: 条件の新しい組み合わせが満たされるたびに、ポリシーによって通知が送信されます。たとえば、条件 A が満たされ、インシデントがオープンになり、通知が送信されるとします。後続の測定で条件 A と条件 B の両方が満たされたときに、そのインシデントがオープンのままの場合は、別の通知が送信されます。

Cloud Monitoring API を使用して作成されたアラート ポリシーでは、条件が満たされたときと条件が満たされなくなったときに通知されます。デフォルトでは、Google Cloud Console を使用して作成されたアラート ポリシーにより、インシデントが開かれたときに通知が行われます。インシデントが終了しても、通知されません。インシデントクローズ時に通知を有効にできます。

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

アラート ポリシーは、ポリシーを無効化および有効化することによって、一時停止および再開できます。たとえば、仮想マシン(VM)でメンテナンスを行う前に、そのインスタンスをモニタリングするアラート ポリシーを無効にできます。

アラート ポリシーを無効にすると、ポリシーはインシデントをトリガーまたはクローズできなくなりますが、Cloud Monitoring はポリシー条件を評価して結果を記録します。アラート ポリシーを無効にした後、未解決の問題をクローズするには、対応するインシデントをミュートします。この処理の詳細については、インシデントのミュートをご覧ください。

無効化されたポリシーが再度有効化されると、Monitoring によって直近の期間時間枠でのすべての条件の値が調べられます。これには、一時停止期間の前、期間中、および期間後のデータが含まれることがあります。期間時間枠が長い場合でも、再開直後にポリシーがトリガーされる可能性があります。

たとえば、モニタリング対象プロセスがメンテナンスのために 20 分間停止しているとします。プロセスを再起動して直ちにアラート ポリシーを再度有効化すると、Monitoring はプロセスが過去 5 分間稼働していないことを認識して、インシデントを開きます。

通知レイテンシ

通知レイテンシは、問題が最初に発生したときからポリシーがトリガーされるときまでの遅延です。

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

  • 指標収集の遅延: Cloud Monitoring が指標値を収集するために必要とする時間。Google Cloud の値の場合、ほとんどの指標は収集後 60 秒間表示されません。ただし、遅延は指標によって異なります。アラート ポリシーの計算では、60~90 秒の追加の遅延が発生します。AWS CloudWatch の指標の場合は、表示されるまでの遅延が数分に達する可能性があります。稼働時間チェックでは、これは(期間時間枠の終了時点から)平均で 2 分になります。

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

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

次のステップ