このステップでは、これまでのステップで生成されるようになった重要イベントに対するアクションを設定します。「Splunk ITSIアラートの設計 - 概要」で、設計は今後更新される可能性があると申し上げましたが、このステップと次のステップは特に今後コンセプトが大きく変わる可能性があります。もし、このアラート設計を実現するもっと良い方法をご存じであれば、ぜひお知らせください。LinkedInからご連絡いただければ幸いです。それまでは私の現在の設計で進めて、いずれ進化させましょう。
「alertable」フィールドの作成
ステップ3では、環境内の問題を検出するための相関サーチをいくつか作成しました。ステップ4ではまず、検出される問題の中で、実用性を考えてアラートすべき問題をより分けます。次に、重要イベントに「alertable」という名前のフィールドを作成し、それをフラグとして、特に緊急性が高く担当者に速やかにアラートを送信する必要があるイベントではその値を1に設定します。アラートするほどでもないイベントでは0に設定します。その後、イベントのalertableフィールドの値に基づいて、重要イベントの集計ポリシー(NEAP)のアクションルールを作成します。
例：サービスの健全性スコアが「重大」になったときにアラートする
例として、ステップ1で作成した1つ目の相関サーチにalertableフィールドロジックを追加します。この相関サーチでは、健全性スコアが「低」以上になったときに重要イベントが生成されますが、アラートは「重大」のときにのみ生成します。サービス低下のイベントを生成する最初の相関サーチに戻って、次のようにSPLを更新します。
`service_health_data` alert_level>2
| `acme_itsi_summary_to_itsi_tracked_alerts_field_mapping`
| eval alertable = if (alert_level>5,1,0)
テストと確認
テスト用サービスの健全性を「正常」の状態から「高」、「重大」へと変化させます。サービスの健全性が「高」になると、重要イベントが生成され、alertableフィールドが作成されて、値が0に設定されるはずです。その後「重大」になると、重要イベントのalertableが1に変わるはずです。
集計ポリシーのアクション設定
次に、ステップ2で作成したNEAPのアクションセクションで、alertableが1のときにアクションを実行するように設定します。
アクションメールではトークンを使用しています。これは、この設計について理解しておくべき重要な特徴です。環境全体でNEAPを1つにまとめる必要があるため、アクションスクリプトでトークン化を使用して、重要イベントのグループごとに適切なチームまたは担当者に通知を送れるようにしています。その方法はたくさんありますが、alert_groupごとにメールアドレスまたは連絡先を割り当てる2つ目のルックアップを使う方法をお勧めします。
ここでは2つのルックアップを自動実行しています。1つ目のルックアップでalert_groupフィールドを作成し、2つ目のルックアップでそのalert_groupに適切なメールアドレスを指定します。この場合、意図したとおりに動作させるには、2つの自動ルックアップ定義が辞書式順序で正しく並ぶように名前を指定する必要があります。
まとめ
これで、alertableが1の重要イベントが発生したときにメールが送られる(またはその他の指定したアクションが実行される)はずです。要約すると、このステップでは作成した相関サーチを確認し、アラートの対象とする問題を決めて、適切なalertableロジックを追加します。上記のalertableロジックの例は極めて単純ですが、このとおりにする必要はありません。状況に合わせて複雑なalertableロジックを記述することもできます。たとえば、一部のサービスでは重大度が「高」でアラートし、それ以外では「重大」でアラートするようにしたり、特定のKPIが「重大」のときのみアラートするなど、alertableを1または0に設定するロジックを必要に応じて拡張、強化できます。
最後に、お気づきかもしれませんが、このままでは大量のメールを受け取ることになります。それでは困ります。現時点では、アクションのスロットリングを実装していないため、alertableが1の重要イベントが新たに発生するたびにアクションが実行されます。スロットリングを使用すれば、アクションの実行を1エピソードにつき1回のみに抑えることができます。次回の最後のステップでは、その手順をご説明します。
順調ですね。ステップ5に進みましょう。
