アラートの動作

アラート ポリシーは、動的かつ複雑な環境に存在するため、それらをうまく使用するには、その動作に影響を与える可能性のあるいくつかの変数について理解しておく必要があります。条件、条件の期間時間枠、通知チャネルによってモニタリングされる指標とリソースは互いに影響します。

このページでは、アラート ポリシーの動作の理解に役立つ追加情報について説明します。

アライメント期間と期間時間

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

アライメント期間

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

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

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

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

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

期間時間枠

単一の測定値が原因で条件が満たされることを防ぐには、期間(期間時間枠)を使用します。Google Cloud Console を使用している場合、[Configuration] ペインの [For] フィールドが期間時間枠に対応します。

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

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

上記に示されるように、アライメントされている値が start + 2m の時点でしきい値 を超えても、条件がアライメントされている値が 3 分のしきい値を超えるまでは条件が満たされません。これは start + 5m の時点で発生します。

図は、アライメント期間によって、いくつのデータサンプルが整列指定子と結合するかを示しています。長い期間を選択すると、多くのサンプルが結合されます。短い期間を選択した場合、その間隔に 1 つのデータポイントだけが含まれる可能性があります。対照的に、期間時間枠では、条件が満たされるのに必要な値がしきい値以上になるまでの時間を指定します。期間時間枠が 0 に設定されている場合、しきい値を超える値が 1 つあれば条件が満たされていることを意味します。

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

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

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

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

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

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

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

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

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

Cloud Monitoring API を使用している場合、またはアラート ポリシーに複数の条件がある場合は、個々の条件が満たされるタイミングを指定する必要があります。条件が満たされるとイベントが作成され、インシデントが開かれる可能性があります。

  • Google Cloud Console を使用している場合、ポリシー トリガーフィールドを使用します。
  • Cloud Monitoring API を使用している場合、combiner フィールドを使用します。

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

Cloud Console
ポリシーによって値がトリガーされます
Cloud Monitoring API
combiner の値
意味
いずれかの条件が満たされている OR いずれかのリソースがいずれかの条件を満たすと、インシデントが開かれます。
条件ごとに異なる
リソースであっても
すべての条件が満たされている

(デフォルト)
AND 各条件が 1 つ以上のリソースによって満たされている場合、異なるリソースがそれらの条件を満たしている場合であっても、インシデントが開かれます。
すべての条件が満たされている AND_WITH_MATCHING_RESOURCE 同じリソースが各条件を満たすと、インシデントが開かれます。この設定は、最も厳密な組み合わせ選択です。

このコンテキストで、met という用語は、条件の構成が true と評価されることを意味します。たとえば、構成が Any time series is above 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 usage is too high が満たされます。条件が「いずれかの条件を満たしている」と組み合わされている場合、条件が満たされるためインシデントが作成されます。条件が「すべての条件を満たしている」または「各条件で異なるリソースであってもすべての条件を満たしている」と組み合わされている場合、インシデントは作成されません。これらの組み合わせを選択している場合は、両方の条件が満たされる必要があります。

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

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

    追記ですが、vm2 が条件 CPU usage is too high を満たすと、インシデントも作成されます。これは、vm1 が条件 CPU usage is too high を満たすことと、vm2 が条件 CPU usage is too high を満たすことは、別個のイベントであるためです。

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

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

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

アラート ポリシーは、ポリシーを無効化および有効化することによって、一時停止および再開できます。たとえば、プロセスが 5 分を超えてダウンしているときに通知するアラート ポリシーがある場合、アップグレードやその他のメンテナンスのためにプロセスを停止するときに、そのアラート ポリシーを無効化できます。

アラート ポリシーを無効にすると、ポリシーはインシデントをトリガーまたは解決できなくなりますが、Cloud Monitoring はポリシー条件を評価して結果を記録します。アラート ポリシーを無効にし、対応待ちの問題を解決の状態にしたい場合は、それらのインシデントを手動で解決する必要があります。この処理の詳細については、クローズ済のインシデントをご覧ください。

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

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

異常インシデント

アラート ポリシー、特に「指標の不在」または「しきい値未満」のアラート ポリシーは、予定より早くまたは間違ってトリガーされ、[アラート] ウィンドウの [インシデント] ペインに表示されることがあります。

これは、データにギャップがあるときに発生しますが、ギャップが容易に識別できないこともあります。そのようなギャップは不明瞭なこともあります。また、補正されていることもあります。

たとえば、グラフでは、データのギャップは補間されています。数分のデータが失われている可能性がありますが、グラフでは視覚的連続性のために欠けている点がつながっています。基盤となるデータでのそのようなギャップは、アラート ポリシーをトリガーするのに十分であることがあります。

ログベースの指標でのポイントは到着が遅延して、最大で過去 10 分間バックフィルされることがあります。これによってギャップが効果的に修正され、データが到着したときにそのギャップが埋められます。このようにして、表示されなくなったログベースの指標のギャップによってアラート ポリシーがトリガーされていた可能性があります。

「指標の不在」および「しきい値未満」の条件は、クエリの遅延が小さく、リアルタイムで評価されます。条件のステータスは、評価された時刻と、対応するインシデントが Monitoring で表示される時刻との間で変化できます。

部分的な指標データ

測定が欠落している場合(たとえば、HTTP リクエストが数分間ない場合など)、ポリシーでは条件を評価するために、最後に記録された値が使用されます。

  1. 条件で、連続する 5 分間で 2 秒以上の HTTP レイテンシと指定されています。
  2. 連続する 3 分間で、HTTP レイテンシは 3 秒です。
  3. 連続する 2 分間で、HTTP リクエストがありません。この場合、条件では、この 2 分間に最後の測定(3 秒)が繰り越されます。
  4. 最後の 2 分間のデータがありませんが、合計 5 分後にポリシーがトリガーされます。

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

次のいずれかを行うことにより、これらの問題を最小化できます。

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

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

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

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

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

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

たとえば、ポリシーが 2,000(または 20,000)個の Compute Engine インスタンスに適用され、各インスタンスがアラートの条件を満たす場合、5,000 個のインシデントのみが開かれます。ポリシーに対する対応待ちのインシデントが解決するまで、満たされている残りの条件はどれも無視されます。

インシデントごとの通知

条件を満たす時系列ごとに通知が送信されます。その時系列が条件をもう満たさなくなると、別の通知が送信されます。条件がもう満たされなくなると、インシデントが解決されます。

ポリシーに複数の条件が含まれている場合は、ポリシーの設定方法に応じて複数の通知が送信されることがあります。

  • すべての条件が満たされたときにのみポリシーがトリガーされる場合、インシデントが最初に開かれたときにのみ、ポリシーによって通知が送信されます。

  • いずれかの条件が満たされたときにポリシーがトリガーされる場合、条件の新しい組み合わせが満たされるたびに、ポリシーによって通知が送信されます。例:

    1. 条件 A が満たされ、インシデントが開かれて通知が送信されます。
    2. その後の測定で条件 A と条件 B の両方が満たされたときに、このインシデントがまだ開いています。この場合、このインシデントは開いたままになり、別の通知が送信されます。

通知レイテンシ

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

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

  • 指標収集の遅延: Cloud Monitoring が指標値を収集するために必要とする時間。通常、Google Cloud 値は無視できます。AWS CloudWatch の指標の場合、これは数分になることがあります。稼働時間チェックでは、これは(期間時間枠の最後から)平均で 2 分になります。

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

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

次のステップ