0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Splunkアラート新規作成で設定するパラメータ

Last updated at Posted at 2025-03-13

この記事では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

作成手順

  1. 目的のAppを開き、サーチ画面でアラートの対象とするデータを抽出するSPLを入力します。

    image.png

  2. 「名前を付けて保存」>「アラート」を選択します。

    image1.png

  3. 「アラートとして保存」画面が表示されるので、適切なパラメータ(後述)を指定して「保存」を選択。

    image.png

  4. 完成👍

    image3.png

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

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

パラメータ補足説明

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

失効

image4.png

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

seiseiaction_select.gif

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

seiseiaction_select_ex.gif

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

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

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

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

image5.png

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

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

「結果あたり」

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

alert-Copy of Page-3.drawio.png

「カスタム」

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

alert-Page-3.drawio (1).png

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

image7.png

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

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

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

alert-Copy of Copy of Page-3.drawio (1).png

抑制

image8.png

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

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

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

alert-w_suppression.drawio.png

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

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

alert-wo_suppression.drawio.png

「抑制」を利用することで、異常発生時にメールボックスや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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?