Splunk ITSIアラートの設計 - ステップ5

「Splunk ITSIアラートの設計」ブログ連載もついに最終回を迎えました。ここまできたら最後のステップが待ちきれないことでしょう。今回は、アラートにスロットリングを適用します。前のステップまでで実用的なアラートを生成できるようになりましたが、スロットリングを行わないと、アラートが大量に送られることになります。理想は1エピソードにつきアラート1件です。1日または1時間に1件でも許容範囲かもしれませんが、重要イベント1件につきアラート1件は多すぎるでしょう。

NEAPでスロットリングを設定するのは簡単でわかりやすい、と言いたいところですが、残念ながらそうはいきません。このブログで説明する手順は、少しやりにくく、わかりにくいと感じるかもしれません。

説明

まず、何をしようとしているかを言葉で説明してから、実際の手順に移りましょう。

これから、環境全体で使用する最後の相関サーチを1つ作成します。このサーチでは、各エピソードグループを定期的にチェックし、alertableフィールドの値が1に設定された重要イベントが1件以上あるグループを見つけて、特殊な「アラートトリガー」重要イベントを生成します。この相関サーチが賢い点は、該当するイベントが複数あっても「アラートトリガー」イベントは1つしか生成されないことです。これがスロットリングの役割を果たします。最後に、NEAPのアクションで、「アラートトリガー」イベントがあるかどうかに基づいてアラートを生成するようにロジックを変更します。これで完成です。

アラートトリガーのための相関サーチ

このサーチは少し厄介ですが、我慢してお付き合いください。

((index=itsi_grouped_alerts) OR (index=itsi_tracked_alerts alertable=1))

| eventstats values(itsi_group_id) as itsi_group_id by event_id

| search index=itsi_tracked_alerts

| mvexpand itsi_group_id

| lookup itsi_notable_event_group_lookup _key AS itsi_group_id OUTPUT severity AS lookup_severity, status AS lookup_status, owner AS lookup_owner

| eval severity=coalesce(lookup_severity, severity), status=coalesce(lookup_status, status), owner=coalesce(lookup_owner, owner)

| search status < 5

| eventstats count(eval(alertable=1)) as alertable_count count(eval(alert_trigger=1)) as alert_trigger_count by itsi_group_id

| where alertable_count>0 AND alert_trigger_count<1

| dedup itsi_group_id

| eval alert_trigger=1

スロットル時間の長さの設定

上記の画像からわかるとおり、このサーチは、過去24時間以内に発生した重要イベントに対して実行するように設定されています。この時間範囲はスロットリングの期間を示すため、非常に重要です。エピソードが24時間以上続くと、サーチでalert_triggerイベントが返されなくなり、新たなサーチが開始されて、新たなアラートアクションが実行されます。このスロットリング時間の長さを調整したい場合は、サーチの実行時間を必要に合わせて調整するだけです。

よりスマートなスロットリング

上記の相関サーチでは、スロットリングの時間と対象すべてを制御しています。そのため、ルールのロジックを変更することで、いつでもスロットリングを調整できます。たとえば、エピソードが24時間以上続いていても、alertableが1の重要イベントが最後に発生したのが比較的前(たとえば10時間前)の場合は、新しいアラートは必要ないかもしれません。そのようなロジックをこの相関サーチに組み込んで、最後に発生したイベントが比較的新しい(たとえば過去60分以内に発生した)場合にのみアラートするように調整できます。そのロジックを組み込んだアラートトリガーの相関サーチを次に示します。

((index=itsi_grouped_alerts) OR (index=itsi_tracked_alerts alertable=1))

| eventstats values(itsi_group_id) as itsi_group_id by event_id

| search index=itsi_tracked_alerts

| mvexpand itsi_group_id

| lookup itsi_notable_event_group_lookup _key AS itsi_group_id OUTPUT severity AS lookup_severity, status AS lookup_status, owner AS lookup_owner

| eval severity=coalesce(lookup_severity, severity), status=coalesce(lookup_status, status), owner=coalesce(lookup_owner, owner)

| search status < 5

| eventstats count(eval(alertable=1)) as alertable_count count(eval(alert_trigger=1)) as alert_trigger_count max(_time) as latest_alertable_time by itsi_group_id

| eval seconds_since_last_alertable_notable = now() - latest_alertable_time

| where alertable_count>0 AND alert_trigger_count<1 AND seconds_since_last_alertable_notable < 3600

| dedup itsi_group_id

| eval alert_trigger=1

まとめ

これで完成です。すべてのステップが終わりました。この設計の便利さを感じていただけたでしょうか。この設計はメンテナンスがとても簡単で、パフォーマンスも高く、すべてのサービスで使用できます。きっとお役に立つと思います。ただし、これはあくまで設計であり、開始点にすぎません。ぜひ皆様の環境に合わせて使いやすいように改良、強化してください。ご意見やご要望がございましたら、下記の作者紹介のLinkedInリンクからご連絡ください。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。