Cloud Monitoring のアラート ポリシーに重大度レベルを追加

※この投稿は米国時間 2022 年 3 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

大量のアラートが配信されるシチュエーションにおいて、どのアラートが最も差し迫っているかを直感的に判断できるでしょうか。重大度レベルは、どの通知の優先度が高いのかをご自身やチームが正しく評価するための、アラートにおける重要なコンセプトです。このレベルを利用することで、オペレーションにおいて最も重要と思われる問題にフォーカスし、雑多な情報の中からトリアージを行えます。本日、アラート ポリシーにカスタム重大度レベルを作成し、このデータを通知に含めることで、より効果的なアラート通知とダウンストリームのサードパーティ サービス（Webhook、Cloud Pub/Sub、PagerDuty など）とのインテグレーションが可能になったことをお知らせします。

通知チャネルは、メール、Webhook、Cloud Pub/Sub、PagerDuty などを含むこうしたデータを受け入れるように強化されており、後日 Slack にも対応予定です。これにより、通知が消費される場所での重要度に応じた、さらなる自動化やカスタマイズが可能になります。

以下では、アラート ポリシーに静的および動的重大度レベルを追加する方法を順を追ってご説明します。

ユーザーラベルを作成して、静的重大度レベルをサポート

アラート ポリシーにユーザーラベルを追加すると、そのアラート ポリシーが生成したすべての通知とインシデントに表示されます。Alert Policy API を通じてアラート ポリシーにユーザーラベルを追加する方法については、こちらのドキュメントをご覧ください。

例を使って見てみましょう。CPU 使用率が特定のしきい値を超えたときに通知するアラート ポリシーを構成するとします。さらに、通知には以下の重大度レベルを表示させたいとします。

• INFO CPU 使用率が 70% から 80% の間の場合

• WARNING CPU 使用率が 80% から 90% の間の場合

• CRITICAL CPU 使用率が 90% を超える場合

これを実現するためには、以下のように定義されたユーザーラベルを使用して、異なる 3 つのアラート ポリシーを作成します。

CPU 使用率が 90% を超える場合にトリガーされるアラート ポリシー（A）を作成し、次のユーザーラベルを含めます。このポリシーにより生成されるすべてのインシデントには CRITICAL の値の重大度ラベルが含まれます。

リソース CPU 使用率が 80% を超える場合にトリガーされる 2 つめのポリシー（B）を作成し、次のユーザーラベルを含めます。このポリシーで生成されるすべてのインシデントには WARNING の値の重大度ラベルが含まれます。

リソース CPU 使用率が 70% を超える場合にトリガーされる 3 つめのポリシー（C）を作成し、次のユーザーラベルを含めます。このポリシーで生成されるすべてのインシデントには INFO の値の重大度ラベルが含まれます。

このシナリオでは、CPU 使用率がしきい値の 90% を超えると、A、B、そして C のポリシーがアラートをトリガーします。CPU 使用率が 85% まで減少すると、ポリシー A のインシデントは閉じられますが、ポリシー B と C のインシデントは対応待ちになったままです。CPU 使用率がさらに 75% まで減少すると、ポリシー B のインシデントは閉じられますが、ポリシー C のインシデントは対応待ちになったままです。CPU 使用率が 40% まで下がると、3 つすべてのポリシーで生成されたインシデントは自動的に閉じられます。

MQL を使用して動的重大度レベルを作成

アラート ポリシーのユーザーラベルは本来静的なものであり、変化するしきい値に基づいて動的にユーザーラベルを適用することはできません。さきほど述べた通り、以下のような値を持つユーザーラベルの重大度を含む通知を生成するためには、異なる 3 つのアラート ポリシーを作成する必要があります。

• INFO しきい値の 80% を下回る場合

• WARNING しきい値の 90% を下回る場合

• CRITICAL しきい値の 90% を上回る場合

1 つのアラート ポリシー内で、しきい値に基づく重大度レベルを動的に適用したい場合は、MQL を使用できます。インシデントに組み込まれる動的カスタム指標ラベルを持つアラート ポリシーを、MQL を利用して作成できます。MQL マップを経由すれば、どのしきい値のレベルがどの重大度ラベルになるかを指定できます。これはつまり、1 つのアラート ポリシーを作成するだけで、しきい値に基づく 3 つの重大度レベルという上記のシナリオを実現できるということです。

以下の MQL クエリのサンプルを見てみましょう。

この例では、CPU 使用率がしきい値の 70% を上回ったときにインシデントが作成されます。値が 70% から 80% の間である場合、インシデントは INFO の値を持つ重大度の指標ラベルを含みます。値が 80 から 90% の間である場合、重大度の指標ラベルには WARNING の値が含まれ、値が 90% を超える場合、重大度の指標ラベルには CRITICAL の値が含まれます。

上記のシナリオでは、CPU 使用率が 92% の値から始まった場合、インシデント A が重大度レベル CRITICAL で作成されます。その後、使用率が 73% に低下した場合、新しいインシデントである B が対応待ちとなります。このインシデントの重大度レベルは INFO です。一方、インシデント A も対応待ちのままとなります。値が 82% に跳ね上がると、新しいインシデントである C が重大度レベル WARNING で対応待ちとなり、インシデント A と B もまた対応待ちのままとなります。自動クローズがポリシーにおいて 30 分で構成されている場合、インシデント「A」はインシデント「B」が開始されてから 30 分後に自動クローズされ、インシデント「B」はインシデント「C」が開始されてから 30 分後に自動クローズされます。  値が 70% を下回ると、すべてのインシデントが閉じられます。

アラート ポリシーで、一度に 1 つのインシデントのみが正しい対応ラベルにおいて対応待ちになっていることを確認し、またインシデントが上記の例のように自動クローズされるまで待たずにすむようにするには、API リクエストで evaluationMissingData を EVALUATION_MISSING_DATA_INACTIVE にセットします。この項目は、指標ストリームにスパースまたは欠落したデータがある場合の処理方法をアラート ポリシーに通知し、必要に応じてインシデントを適切に閉じることができるようにします。MQL のアラート ポリシーを UI で作成する場合、[トリガーの設定] セクション内の [Advanced Options] のプルダウンから、[Missing data points treated as values that do not violate the policy condition] を選択します。

EVALUATION_MISSING_DATA_INACTIVE が上記のシナリオで指定された場合、インシデント A は、インシデント B が作成された時点で閉じられ、インシデント B はインシデント C が作成された時点で閉じられます。

通知チャネルにおける重大度ラベル

PagerDuty、Webhook、Pub/Sub のようなサードパーティ サービスに通知を送る場合、JSON ペイロードを解析し、その重大度に従って通知をルーティングすることで、重要な情報をチームが見逃さないようにできます。

アラート ポリシーのユーザーラベルを利用する場合、これらは policy_user_labels のキーで以下のような通知上のオブジェクトとして表示されます。

MQL で指標ラベルを利用する場合、metric のキーを持つオブジェクトでネストされたラベルのキーを持つオブジェクトとして、以下のように表示されます。

使ってみる

アラートは、Google Cloud のオペレーション スイートで取得されるほぼすべての指標、ログ、トレースに（またはそのデータがないということに対しても）構成できます。重大度レベルは、ご自身とチームが雑多な情報の中から問題を見つけ出し、その解決により最も良い影響を与えるための新しい方法を提供します。オブザーバビリティの詳細な動画シリーズの一環である、ログアラートの動画をぜひご覧ください。また、質問や機能リクエストがおありの場合、または Cloud Alerting を利用している他のお客様からのトピックをお読みになりたい場合は、Google Cloud コミュニティ サイトにぜひお越しください。