アラート ポリシーの詳細

このページでは、Stackdriver Monitoring アラート ポリシーの概念的な概要について詳細に説明します。このドキュメントの内容を理解することで、アラート ポリシーを効果的に活用できます。

アラート ポリシーの作成および管理については、以下をご覧ください。

ポリシー

アラート ポリシーは、サービスが異常とみなされる条件を定義します。その条件が満たされると、ポリシーによって新しいインシデントがトリガーされて開かれます。通知を構成している場合は、トリガーされたポリシーによって通知が送信されます。

ポリシーは個々のワークスペースに属し、各ワークスペースには最大で 500 個のポリシーを含めることができます。

条件

条件によって、アラート ポリシーがいつトリガーされるかが決まります。条件を記述するには、次のことを指定します。

  • 測定する指標。
  • その指標がいつ、把握したい状態に達したかを判断するためのテスト。

何をモニタリングするかに応じて、以下を参照する条件を作成できます。

  • モニタリングするリソース(個々の VM インスタンスまたはインスタンス グループ、サードパーティ アプリケーション、データベース、ロードバランサ、URL エンドポイントなど)。

  • リソースのパフォーマンスを測定する、事前定義された指標

  • ユーザーが独自に作成したカスタム指標ログベースの指標

条件のタイプ

条件は指標に基づいて構築され、たとえば、指標がある値に達したかどうかや、指標が急速に変化し始めたかどうかなどをモニタリングできます。指標はリソースに関連付けられていて、そのリソースのいくつかの特性(たとえば、VM グループ全体の平均 CPU 使用率)を測定します。指標の詳細については、指標、時系列、およびリソースをご覧ください。

すべての条件では、ある期間に、ある方法で動作する、ある指標、という 3 つがモニタリングされます。

すべての条件は、次の 2 つの一般的なタイプのいずれかとして実装されます。

  • 指標の不在条件では、特定の期間時間枠に対してデータが存在しない場合にトリガーされます。

    「指標の不在」条件では、そのポリシーのインストール以降、または最大時間枠(24 時間)内に、測定が 1 回以上成功(測定でデータが取得される)している必要があります。

    たとえば、「指標の不在」ポリシーで期間時間枠を 30 分に設定しているとします。指標データを書き込むサブシステムが一度もデータポイントを書き込んでいない場合、この条件は満たされません。サブシステムが 1 つ以上のデータポイントを出力していて、その後の 30 分間に追加のデータポイントが出力できない場合に条件が満たされます。

  • 指標しきい値条件は、特定の期間時間枠において指標がある値を上回った、または下回った場合にトリガーされます。

    「指標しきい値」条件のクラス内には、一般的なサブカテゴリに分類されるパターンがあります。

    • 指標の変化率(パーセント): 期間時間枠内で指標が特定のパーセント以上増加または減少した場合にトリガーされます。

      このタイプの条件では、しきい値との比較の前に、変化率の計算が時系列に適用されます。

      この条件では、過去 10 分間の指標の値の平均が、期間時間枠の直前に測定された 10 分間の平均値と比較されます。「指標の変化率」条件で使用される 10 分間のルックバック時間枠は固定値であり、変更できません。ただし、条件を作成するときに期間時間枠を指定できます。

    • グループ集計しきい値: リソース グループ全体で測定された指標がしきい値を上回った、または下回ったときにトリガーされます。

    • 稼働時間チェックの状態: 稼働時間チェックを作成済みであり、かつ、2 つ以上の地理的ロケーションから送信されたリクエストにリソースが正常にレスポンスを返すことができなかったときにトリガーされます。

      稼働時間チェックの結果は、Stackdriver Monitoring Console の [Uptime Checks Overview] ページにのみ表示されます。稼働時間チェックに関するアラート ポリシーを作成することによって、間接的にインシデントを開くことができ、オプションで稼働時間チェックが失敗したときに通知を送信できます。

    • プロセスの状態: (1)1 つの VM インスタンスまたはインスタンス グループで実行中のプロセスの数、および(2)ある文字列に一致するプロセスの数が、期間時間枠内に特定の数を上回るかまたは下回ったときにトリガーされます。

      この条件タイプでは、モニタリング対象リソースで Monitoring エージェントが実行されている必要があります。

各タイプの例は次のリンクから入手できます。

条件タイプ JSON の例
指標しきい値 表示
変化率 表示
グループ集計 表示
稼働時間チェック 表示
プロセスの状態 表示

条件の組み合わせ

1 つのポリシーに最大で 6 個の条件を含めることができます。複数の条件を使用する場合、ポリシーに違反する組み合わせを指定するための 3 つのオプションがあります。

  • OR: いずれかの条件が満たされている。
  • AND: 条件が 1 つ以上のリソースによって違反されている。異なるリソースが各条件にそれぞれ違反している場合も含む。
  • AND_WITH_RESOURCES: すべての条件が同じリソースによって違反されている(このオプションは、Monitoring API を使用して作成する条件でのみ使用できます)。

期間時間枠

条件には期間時間枠が含まれています。これは、トリガーする前に、条件が真であると評価される必要がある時間の長さです。条件の期間時間枠によって、アラート ポリシーが過剰反応することが回避されます。通知を絶え間なく送信するアラート ポリシーは結局無視されるため、誤検出を減らすことが望まれます。

経験則として、サービスの可用性が高ければ高いほど、または問題を検出しなかった場合の不利益が大きければ大きいほど、期間時間枠を短く指定します。

パフォーマンスは通常は変動するため、1 回の測定が条件と一致した場合にポリシーをトリガーすることは望ましくありません。代わりに、通常は測定が何回か連続して条件を満たした後に、アプリケーションが異常な状態にあるとみなします。

測定で条件が満たされないと、条件の期間時間枠はそのたびにリセットされます。

次の条件では、5 分の期間時間枠が指定されます。
連続する 5 分間で 2 秒を超える HTTP レイテンシ。

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

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

期間時間枠は、誤検出を減らすために十分な長さを確保しながら、インシデントがタイムリーに開かれるように十分に短くする必要があります。

ポリシーの動作

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

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

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

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

アラート ポリシーを無効化すると、そのポリシーはトリガー(または解決)されなくなりますが、Stackdriver によるポリシー条件の評価および結果の記録は停止されません。

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

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

異常インシデント

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

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

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

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

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

部分的な指標データ

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

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

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

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

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

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

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

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

アラート ポリシーは多くのリソースに適用できるため、リソース全体に影響を及ぼす問題が発生してポリシーがトリガーされると、リソースごとに対応待ちのインシデントが生じる可能性があります。システムの過負荷を防ぐため、1 つのポリシーの対応待ちインシデントの数は 5,000 に制限されています。

たとえば、ポリシーが 2,000(または 20,000)個の Compute Engine インスタンスに適用され、なんらかの原因でアラート条件を満たした場合、5,000 個までのインスタンスが対応待ち状態になります。ポリシーに対する対応待ちのインシデントが解決するまで、残りの違反は無視されます。

インシデントごとの通知

インシデントごとに送信される通知の数は、ポリシーでの条件によって異なります。

ポリシーに条件が 1 つのみ含まれている場合、その後の測定で引き続き条件が満たされた場合でも、インシデントが最初に開かれたときに通知が 1 つのみ送信されます。

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

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

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

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

通知レイテンシ

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

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

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

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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。