この記事ではSplunkを利用してアラートを作成する際に設定するパラメータの内容を説明します。「アラートとして保存」画面の日本語が不明瞭だと感じたので、画面入力項目の内容を重点的に説明します。

（初の投稿なので拙い部分はご容赦ください…。）

前提条件

Splunk Enterprise9.2.x以上を利用していること。
ログインするユーザーに schedule_search 権限が付与されたロールが割り当てられていること。
（リアルタイムアラートを利用する場合のみ）ログインするユーザーに schedule_rtsearch 権限が付与されたロールが割り当てられていること。

アラート機能とは？

Splunkで扱うメトリクス（※１）を監視し、一定の閾値を超えたタイミングでイベントを発生させる機能です。
Splunkでは発生したイベントをもとに、特定の送信先にメールやSlackメッセージを送信したり、Webhookを利用してHTTPリクエストを送信したりすることができます。この時、メールやSlackにはアラートの原因となったメトリクスに関連する情報（例えばCPU利用率が閾値を上回ったサーバのIPアドレスなど）を含めることができます（※２）。
アラート機能を利用する代表的なシナリオとしては、サーバーやIoT機器のリソースや稼働状態の監視が挙げられます。例えば、管理しているサーバーのCPU使用率が80%を超えた場合に、指定したユーザー（サーバー管理者など）にメールやSlackに通知を送信することが可能です。
また、Splunkではメトリクスをリアルタイムに監視することができます。例えば、CPU使用率が80%を超えた段階ですぐにサーバー管理者は通知を受け取ることができるため、迅速な対応が可能になります。

アラートの基本的な作成手順

今回作成するアラート

今回はメトリクスとして、Splunkインデックスに対するI/Oスループットを利用します。スループットが20kbps以上に到達した場合にI/O逼迫のアラートを生成するようにします。
スループットは30秒ごとに更新されます。

※20kbpsで逼迫するようなストレージは今時あまり使われていませんが…。

index=_internal source="/opt/splunk/var/log/splunk/metrics.log" group="thruput" name=index_thruput instantaneous_kbps
| sort - _time
| head limit=1

作成手順

目的のAppを開き、サーチ画面でアラートの対象とするデータを抽出するSPLを入力します。
「名前を付けて保存」>「アラート」を選択します。
「アラートとして保存」画面が表示されるので、適切なパラメータ（後述）を指定して「保存」を選択。
完成👍

「アラートとして保存」画面入力項目

項目名	説明	選択肢
タイトル	アラートのタイトル
詳細	アラートを説明する詳細
権限	アラートを共有する範囲	・プライベート・App内で共有
アラートタイプ	実行タイミングを指定	・リアルタイム（※３）・スケジュール済み・毎時間実行・毎日実行・毎週実行・毎月実行・Cronスケジュールを実行（※４）
時間範囲（※５）	サーチの対象とする時間範囲
：	（不明※６）
失効（※７）	アクティビティ > 「生成されたアラート（Triggered Alerts）」画面にアラートが残存する期間を指定する（アクションに「生成アラートに加える」を指定した場合）（※８）
⭐️次の条件の時にアラートを生成	SPLから生成されたイベント/テーブルに対して、アラートを生成する条件を指定	・結果あたり：サーチが結果を返した場合はいつでもアラートを生成（※５）・結果数：サーチ結果数に基づいてアラートを生成・ホスト数：結果中のホスト数に基づいて生成・ソース数：結果中のソース数に基づいて生成・カスタム：自分で設定した条件で生成
生成条件(またはトリガー)	SPLの結果として抽出されたイベント一つ一つにつきアラートを生成する（各結果について）のか、SPLの結果がいくつだろうと一回だけアラートを生成するのか（1回）を選択	・１回・各結果について
抑制	アラートが生成された際、次にアラートが生成される最低の時間間隔を設定
アクション生成	イベント・テーブルが⭐️で指定した条件を満たした時に実施するアクションを指定	（デフォルトの場合）・Log Event ・結果をルックアップに出力・結果を遠隔測定エンドポイントに出力する・スクリプトを実行・メール送信・Send to Splunk Mobile ・Webhook ・生成アラートに加える

パラメータ補足説明

一部表記だけではわかりづらいパラメータについて詳細説明します

失効

このパラメータは、「アクション生成」のアクションとして「生成アラートに加える」を選択した場合のみに意味を持つパラメータです（下動画）。

このパラメータは、アクティビティ > 「生成されたアラート（Triggered Alerts）」画面にアラートが残存する期間を指定します（下動画）。

アラートが生成されてから指定した期間が経過すると、「生成されたアラート（Triggered Alerts）」画面には当該アラートが表示されなくなります。

「アクション生成」に他のアクションのみを指定した場合、「失効」パラメータは無視されるようです。

「生成アラートに加える」をアクションに設定しない限りは意識しなくてよいパラメータです。（※９）

次の条件の時にアラートを生成

アラートが生成される条件を指定することができます。選択肢としては以下の５つ（または４つ）が用意されています。

結果あたり：サーチが結果を返した場合はいつでもアラートを生成（※５）
結果数：サーチ結果数に基づいてアラートを生成
ホスト数：結果中のホスト数に基づいて生成
ソース数：結果中のソース数に基づいて生成
カスタム：自分で設定した条件で生成

「結果あたり」

５つの選択肢のうち特に「結果あたり」は、アラートのもとになるSPLから一件でもテーブル・イベントが抽出された場合に実行する条件です（※１０）。

「カスタム」

最初に設定したSPLで抽出されたテーブル・イベントを入力にして、さらにSPLを実行します。ここで指定するSPLから一件以上のイベントが返される場合にアラートが生成されるようになります[2]。

生成条件(またはトリガー)

アラートを生成する際、SPLから生成された結果に対して１回アラートを生成するのか、結果に含まれるイベントそれぞれについてアラートを生成するのかを選択します。

「1回」を生成条件として適用した場合、アラートに設定したSPLから出力されたイベントの数が何件であっても、一回のみアラートを生成します。

「各結果に対して」を適用した場合、SPLから出力されたイベントそれぞれについてアラートを生成します。「1回」を選択した場合と異なり、出力されたイベントの数に応じてアラート生成の回数が変化します（下図）。

抑制

閾値を条件にしていると、いっぺんに大量のアラートが発生してしまう可能性があります（※１１）。

これを防ぐために「抑制」パラメータを利用します。「抑制」パラメータを指定すると、最後のアラートが発生してからここに指定した期間は、なにがあっても当該アラートを生成しないように設定できます。

以下の図のように、10:00に発生したアラートは、「次に対する生成を抑制」で指定した60分経過するまで再度生成されません（たとえその間ずっとメトリクスが閾値を上回っていたとしても）。

入力項目「次に対する生成を抑制」で、アラートを生成しないようにする期間を設定します。

また「生成条件」として「各結果に対して」を選択した場合、「フィールド値を含む結果を抑制」というパラメータが表示されます。このパラメータには、一続きのアラートであることを識別するためのフィールド名を入力します。フィールドはコンマ区切りで複数指定することが可能です[3]。

例えば、フィールド名として server_id を指定した場合を考えます。あるserver_id を持つアラートが生成された場合、同じ server_id を持つアラートは指定された期間抑制されます。その一方で、異なる server_id を持つアラートは抑制期間内であっても生成されることになります。

注釈

※１：ここでは時系列形式で与えられる数値データのことを指します。例えばサーバのCPU使用率やディスクIO、IoTセンサから取得した湿度の推移などが該当します。

※２：こういったアラート機能はSplunkだけではなく、NagiosやPrometheus、InfluxDBでも実装されています。

※３：schedule_rtsearch権限がユーザーに付与されていない場合、表示されません。

※４：SPLが実行されるタイミングをCron形式で指定することができます。

※５：Splunkバージョンによっては表示されない場合があります。

※６：このパラメータは本当にわかりませんでした。どなたか情報をお持ちであればご教授いただけると幸いです。

※７：この「失効」パラメータに指定した内容は、「アクション生成」パラメータとして「生成アラートに加える」を指定した場合以外は無視されるようです。

※８：Splunk公式ドキュメントには以下の記載があります[1]。

Change the Expires setting. This setting controls the lifespan of triggered alert records, which appear on the Triggered Alerts page.

※９：ならばアラート自体のパラメータとしてではなく、アクションのパラメータとして設定させる方がよいのではという気もしますが…。

※１０：実質「結果数」を選択して「0より大きい」とした場合と等価ですかね。

※１１：例えば「CPU使用率が80%以上」であることを条件にしたアラートを考えます。サーバは決められた時間（5秒など）ごとに自身のリソース状況を監視し、結果をSplunkに報告します。ここでサーバにもしも何かトラブルが発生し、CPU80%の状態が数分続いたとします。

この場合、CPU80%になった時点で一回だけアラートが発生し、それ以降は同じ事象に対するアラートが発生しないという挙動が理想的です。しかし実際は、CPU80%の状態が継続している限りSplunkは5秒ごとにアラートを生成し続けます（下図）。

「抑制」を利用することで、異常発生時にメールボックスやSlackが同じ内容のものだらけになったり、メールサーバの容量を圧迫したりすることを防ぎます。

参考

[1] https://docs.splunk.com/Documentation/Splunk/9.4.1/Alert/Definescheduledalerts

[2] https://docs.splunk.com/Documentation/Splunk/9.4.1/Alert/AlertTriggerConditions

[3] https://docs.splunk.com/Documentation/Splunk/9.4.1/Alert/ThrottleAlerts