この記事ではSplunkを利用してアラートを作成する際に設定するパラメータの内容を説明します。「アラートとして保存」画面の日本語が不明瞭だと感じたので、画面入力項目の内容を重点的に説明します。
(初の投稿なので拙い部分はご容赦ください…。)
前提条件
- Splunk Enterprise9.2.x以上を利用していること。
- ログインするユーザーに
schedule_search
権限が付与されたロールが割り当てられていること。 - (リアルタイムアラートを利用する場合のみ)ログインするユーザーに
schedule_rtsearch
権限が付与されたロールが割り当てられていること。
アラート機能とは?
- Splunkで扱うメトリクス(※1)を監視し、一定の閾値を超えたタイミングでイベントを発生させる機能です。
- Splunkでは発生したイベントをもとに、特定の送信先にメールやSlackメッセージを送信したり、Webhookを利用してHTTPリクエストを送信したりすることができます。この時、メールやSlackにはアラートの原因となったメトリクスに関連する情報(例えばCPU利用率が閾値を上回ったサーバのIPアドレスなど)を含めることができます(※2)。
- アラート機能を利用する代表的なシナリオとしては、サーバーや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内で共有 |
アラートタイプ | 実行タイミングを指定 | ・リアルタイム(※3) ・スケジュール済み ・毎時間実行 ・毎日実行 ・毎週実行 ・毎月実行 ・Cronスケジュールを実行(※4) |
時間範囲(※5) | サーチの対象とする時間範囲 | |
: | (不明※6) | |
失効(※7) | アクティビティ > 「生成されたアラート(Triggered Alerts)」画面にアラートが残存する期間を指定する(アクションに「生成アラートに加える」を指定した場合)(※8) | |
⭐️次の条件の時にアラートを生成 | SPLから生成されたイベント/テーブルに対して、アラートを生成する条件を指定 | ・結果あたり:サーチが結果を返した場合はいつでもアラートを生成(※5) ・結果数:サーチ結果数に基づいてアラートを生成 ・ホスト数:結果中のホスト数に基づいて生成 ・ソース数:結果中のソース数に基づいて生成 ・カスタム:自分で設定した条件で生成 |
生成条件(またはトリガー) | SPLの結果として抽出されたイベント一つ一つにつきアラートを生成する(各結果について)のか、SPLの結果がいくつだろうと一回だけアラートを生成するのか(1回)を選択 | ・1回 ・各結果について |
抑制 | アラートが生成された際、次にアラートが生成される最低の時間間隔を設定 | |
アクション生成 | イベント・テーブルが⭐️で指定した条件を満たした時に実施するアクションを指定 | (デフォルトの場合) ・Log Event ・結果をルックアップに出力 ・結果を遠隔測定エンドポイントに出力する ・スクリプトを実行 ・メール送信 ・Send to Splunk Mobile ・Webhook ・生成アラートに加える |
パラメータ補足説明
一部表記だけではわかりづらいパラメータについて詳細説明します
失効
このパラメータは、「アクション生成」のアクションとして「生成アラートに加える」を選択した場合のみに意味を持つパラメータです(下動画)。
このパラメータは、アクティビティ > 「生成されたアラート(Triggered Alerts)」画面にアラートが残存する期間を指定します(下動画)。
アラートが生成されてから指定した期間が経過すると、「生成されたアラート(Triggered Alerts)」画面には当該アラートが表示されなくなります。
「アクション生成」に他のアクションのみを指定した場合、「失効」パラメータは無視されるようです。
「生成アラートに加える」をアクションに設定しない限りは意識しなくてよいパラメータです。(※9)
次の条件の時にアラートを生成
アラートが生成される条件を指定することができます。選択肢としては以下の5つ(または4つ)が用意されています。
- 結果あたり:サーチが結果を返した場合はいつでもアラートを生成(※5)
- 結果数:サーチ結果数に基づいてアラートを生成
- ホスト数:結果中のホスト数に基づいて生成
- ソース数:結果中のソース数に基づいて生成
- カスタム:自分で設定した条件で生成
「結果あたり」
5つの選択肢のうち特に「結果あたり」は、アラートのもとになるSPLから一件でもテーブル・イベントが抽出された場合に実行する条件です(※10)。
「カスタム」
最初に設定したSPLで抽出されたテーブル・イベントを入力にして、さらにSPLを実行します。ここで指定するSPLから一件以上のイベントが返される場合にアラートが生成されるようになります[2]。
生成条件(またはトリガー)
アラートを生成する際、SPLから生成された結果に対して1回アラートを生成するのか、結果に含まれるイベントそれぞれについてアラートを生成するのかを選択します。
「1回」を生成条件として適用した場合、アラートに設定したSPLから出力されたイベントの数が何件であっても、一回のみアラートを生成します。
「各結果に対して」を適用した場合、SPLから出力されたイベントそれぞれについてアラートを生成します。「1回」を選択した場合と異なり、出力されたイベントの数に応じてアラート生成の回数が変化します(下図)。
抑制
閾値を条件にしていると、いっぺんに大量のアラートが発生してしまう可能性があります(※11)。
これを防ぐために「抑制」パラメータを利用します。「抑制」パラメータを指定すると、最後のアラートが発生してからここに指定した期間は、なにがあっても当該アラートを生成しないように設定できます。
以下の図のように、10:00に発生したアラートは、「次に対する生成を抑制」で指定した60分経過するまで再度生成されません(たとえその間ずっとメトリクスが閾値を上回っていたとしても)。
入力項目「次に対する生成を抑制」で、アラートを生成しないようにする期間を設定します。
また「生成条件」として「各結果に対して」を選択した場合、「フィールド値を含む結果を抑制」というパラメータが表示されます。このパラメータには、一続きのアラートであることを識別するためのフィールド名を入力します。フィールドはコンマ区切りで複数指定することが可能です[3]。
例えば、フィールド名として server_id
を指定した場合を考えます。 あるserver_id
を持つアラートが生成された場合、同じ server_id
を持つアラートは指定された期間抑制されます。その一方で、異なる server_id
を持つアラートは抑制期間内であっても生成されることになります。
注釈
※1:ここでは時系列形式で与えられる数値データのことを指します。例えばサーバのCPU使用率やディスクIO、IoTセンサから取得した湿度の推移などが該当します。
※2:こういったアラート機能はSplunkだけではなく、NagiosやPrometheus、InfluxDBでも実装されています。
※3:schedule_rtsearch権限がユーザーに付与されていない場合、表示されません。
※4:SPLが実行されるタイミングをCron形式で指定することができます。
※5:Splunkバージョンによっては表示されない場合があります。
※6:このパラメータは本当にわかりませんでした。どなたか情報をお持ちであればご教授いただけると幸いです。
※7:この「失効」パラメータに指定した内容は、「アクション生成」パラメータとして「生成アラートに加える」を指定した場合以外は無視されるようです。
※8:Splunk公式ドキュメントには以下の記載があります[1]。
Change the Expires setting. This setting controls the lifespan of triggered alert records, which appear on the Triggered Alerts page.
※9:ならばアラート自体のパラメータとしてではなく、アクションのパラメータとして設定させる方がよいのではという気もしますが…。
※10:実質「結果数」を選択して「0より大きい」とした場合と等価ですかね。
※11:例えば「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