柔軟になったアラート通知設定を活用してインシデント対応を効率化する

アラートとAI機能に関する大規模変更についてでお伝えした通り、弊社では今後1年間の間にアラートとAI機能の改善と旧機能の廃止を検討しています。

本ブログ執筆時点で、以下の新しいアラート/AI機能が段階的に開放されていますので、本ブログではこれらの変更について実際の画面を使いながら説明していきます。

• アラート通知先の新しい登録方法
• 問題発生時のコンテキストに応じた通知先の変更
• アラート通知時の通知内容の拡充

今回の変更で新たに導入された重要な要素はDestinationsとWorkflowsで、Alerts & AI 画面上では「ENRICH & NOTIFY」というセクションに表示されています。Destinationsは、アラート通知先のエンドポイントを登録します。Workflowは、アラート条件（Alert Condition）に合致する問題（Issue）が発生した場合の通知先と通知内容を定めたルールを登録します。

従来のアラートの定義方法では、アラート条件（Alert Condition）と通知先（Channel）が密に関連付いていたため、問題発生時のコンテキストに応じて通知先を変更するような柔軟なアラート運用はできませんでした。例えば、Warningレベルの問題が発生した時はSlack通知のみとし、Criticalレベルの問題が発生した時はメールやインシデント管理システムに通知する、といったようなことです。また、問題が発生しているアプリケーションによって通知先のチャネルを動的に変えるといったこともできませんでした。そのため、コンテキストに応じて通知先を分ける場合には、アラート定義を都度別に作成する必要があり、アラート定義が煩雑になってしまうという問題がありました。今回の変更によって、アラート条件を満たす問題が発生した際の通知先（Destinations)は、Workflowsによって柔軟に変更できるようになったため上記の問題を解決することができます。

また、従来のアラート定義方法では、通知内容はあらかじめ決められた情報のみに限られており、アラートが通知された時の状況把握に必要な情報を都度取得する必要がありました。新たに導入されたWorkflowでは通知する際にコンテキスト情報を付与するための仕組みが備わっており、状況把握に必要なデータを添えた上でアラート通知を行うことができるようになったため、アラート通知時の初動を早くすることが可能になります。

それでは具体的に設定方法を見ていきましょう。アラート条件の定義方法は従来と変わらないため、ここではアラート条件は既に定義されていることを前提とします。

アラート通知先の登録（Destinations)

上記の通り、従来はChannelメニューで通知先を登録していましたが、新しい設定方法ではDestinationsから通知先を登録できます。

本ブログ執筆時点では「Add a destination」にあるJIRA, ServiceNow, Slack, Webhook（, およびWorkflowsで説明するEmail）が通知先として利用可能です。いずれかのボタンをクリックすると設定画面が表示されます。

以下はWebhookを通知先とする場合の設定例です。Destinationsではエンドポイントの情報のみを登録します。実際の通知内容に相当するWebhookのペイロードは、この段階で設定するのではなく後で説明するWorkflowにて設定します。ペイロードはコンテキストに応じて変更したい場合が多いため、静的に定義するのではなく動的に柔軟に変えられるようにするためです。

Destinationsで通知先の登録がされ、アラート通知が行われ始めると通知状況が確認できるようになっています。設定ミスやエンドポイントの不具合によって通知エラーがある場合はすぐに気づくことができるようになりました。

通知先や通知内容の設定（Workflows)

Workflowsでは、アラート条件に合致した問題をどの通知先にどのように通知するかを決めます。全ての問題を通知対象とすることも可能ですし、上述の例のようにWarningレベルの問題や特定のアプリケーションの問題だけ通知したり、状況に応じてSlackチャネルなどの通知先を変えることができます。

「Add a workflow」ボタンから新しくWorkflowを定義できます。Workflowの主な設定項目は以下です。

• Workflowの名称
• 通知対象とする問題（Issue）のフィルタ条件：全ての問題か、もしくはWarningレベルの問題など、特定の条件に合致するものに限定することができます
• 通知に付与するコンテキスト情報：NRQLを使って、アラート通知時にNRDBから任意のデータを取得して補足情報として付与することができます
• 通知先：Destinationで登録した通知先とその詳細を設定します。Slackのチャネルの選択、Webhookのペイロード、ServiceNowのインシデントの属性指定など。

通知対象とする問題（Issue）のフィルタ条件の指定

フィルタ条件では対象とする問題やエンティティの属性によって通知対象とするか否かを指定することができます。例えば下の画像の例ではタグに設定されたチームと問題の深刻度によって通知先を指定する例です。アラート条件を共通にしながらも、柔軟に通知先を変えられるので煩雑なアラート定義から解放されますね。

通知に付与するコンテキスト情報の指定

アラート通知を受けても状況把握するためには通知を受けた後に情報収集をする必要があり、それによって初動が遅れることも少なくありません。問題が発生した時のコンテキスト情報を通知に付与することができれば、問題の把握と原因調査を効率化することができるようになります。

あらかじめ定義されたNRQLが通知時に実行されることによって通知内容に付与するデータを取得します。例えば、TransactionErrorイベントやLogイベントに対するNRQLであれば、エラーレートが上がった場合に多く発生しているエラーの詳細情報を付与することができます。

なお、クエリの中では変数を利用することが可能です。変数には、問題が発しているエンティティの名称などが格納されています。例えば、etitiesData.namesには問題の発生しているエンティティ名が格納されていますが、以下の画像にあるようにようなクエリを書くことで関係のないエンティティは除外して必要なエンティティの情報のみにフィルタすることができます。どのような変数が使えるかはドキュメントを参照してください。

通知先の設定

アラート条件が合致した場合に通知する通知先を設定します。Destinationsで設定済みのエンドポイントから選択し、通知内容をカスタマイズします。

以下はSlackの例です。どのチャネルに通知するかを設定します。

以下はWebhookの例です。任意のWebhookペイロードを設定できます。ここでも変数が利用可能です。

設定が完了したら「Send test notification 」で意図通り通知されるか確認しましょう。

通知結果の確認

最後に通知された結果を確認してみます。以下はSlackの例です。

発生した問題や対象のエンティティの情報はこれまでと同様ですが、それに加えて上記で設定したコンテキスト情報が付与されています。コンテキスト情報の表示のされ方は通知先によって変わりますが、Slackやメールの場合はテーブルやチャート形式、WebhookやServiceNowなどのインシデント管理サービスの場合はJSONデータに含まれる形で取得できます。

まとめ

以上、本ブログでは柔軟になったアラート通知の設定方法について実画面を使って説明してきました。通知条件の柔軟性の向上により煩雑な通知設定から解放され、またコンテキスト情報の付与によりインシデント対応の初動を早めることが可能になりました。是非お試しください。

※スクリーンショットなどは本ブログ執筆時点でのものです。サービス改善等により変更される可能性があることご承知おきください。