Kibana Alertでアラート（通知）を抑制する機能

この記事はKibana Alertについての連続記事の一部です。

この記事ではいくつかあるKibana Alertのアラート抑制機能について説明します。

アラート抑制の概要

Kibana Alertでは、条件が満たされるたびにAlertが生成され、Actionが実行されます。しかし実運用では、メンテナンス中の通知停止、一時的なノイズの抑制、頻繁に状態が変わるアラートの制御など、通知を意図的に抑制したいケースが多く存在します。

Kibanaはこれに対応するために複数の抑制機能を提供しています。それぞれ適用レベル（Rule・Action・Alert）や保存方式が異なります。

機能	適用レベル	主な用途
Maintenance Window	グローバル / カテゴリ	計画メンテナンス中の全通知停止
Snooze	Rule	特定ルールの一時停止
Flapping Detection	Alert（グローバル設定）	状態が頻繁に変化するアラートのノイズ抑制
Action Frequency / Throttle	Rule / Action	通知頻度の制限
Mute	Rule / Alert インスタンス	特定ルール・アラートの永続的な無効化
Alert Suppression	Alert（Security専用）	重複アラートの集約
Alerts Filter	Action	特定条件のアラートのみActionを実行

抑制の適用はRule実行時に以下の順序で評価されます。

1. Maintenance Window チェック
2. Muted Alert チェック
3. Alerts Filter チェック
4. NotifyWhen / Throttle チェック
5. Flapping による回復遅延

Maintenance Window

概要

Maintenance Window は、計画メンテナンスなどの期間中にアラートのActionを一時停止するための機能です。特定のRule Typeカテゴリや、KQLで絞り込んだアラートに対してのみ適用することもできます。

Maintenance Windowが有効な間、アラート自体は生成されますが（Ruleの評価は継続される）、Actionは実行されません。

適用レベル

グローバルレベル（特定のRuleに紐付くのではなく、Kibanaスペース横断で適用）

保存形式

Saved Objectタイプ maintenance-window として .kibana_alerting_cases インデックスに保存されます。

主要フィールド：

フィールド	説明
title	表示名
enabled	有効/無効
duration	ウィンドウの持続時間（ミリ秒）
expirationDate	ウィンドウの有効期限（ISO日付）
events	アクティブな時間帯の配列
rRule	繰り返しルール（iCal RRULE形式）
categoryIds	対象カテゴリ（未設定の場合は全カテゴリ）
scopedQuery	対象アラートを絞り込むKQLクエリ

仕組み

Rule実行時、有効なMaintenance Windowが取得されます（1分間キャッシュ）。各アラートに対して以下を評価し、一致した場合はActionの実行がスキップされます。

1. 現在時刻がMaintenance Windowのアクティブな時間帯に含まれるか
2. ルールのカテゴリが対象カテゴリに含まれるか
3. スコープドクエリが指定されている場合、アラートがそのKQLにマッチするか

既存アラートへの影響

Maintenance Windowを新規作成・有効化しても、すでにアクティブなアラートへのActionは止まりません。

Maintenance WindowはActionを抑制する対象を「MW期間中に初めて検出されたアラート」に限定しています。そのため、MW開始前からすでにアクティブだったアラートはMWの対象外となり、Actionは引き続き実行され続けます。

MW期間中に新たに検出されたアラートはActionが抑制されます。そのアラートがアクティブである間にMaintenance Windowが終了した場合は、次の評価サイクルからActionの実行が再開されます。

設定方法

Stack Management > Alerts and Insights > Maintenance Windows から作成できます。

Snooze

概要

Snooze は、特定のRuleを指定した期間だけ一時的に無効化する機能です。Maintenance Windowと異なり、個別のRuleに対して設定します。スヌーズ中もRuleの評価は行われますが、Actionは実行されません。

適用レベル

Ruleレベル（個別のRuleに対して設定）

保存形式

Ruleのデータ（インデックス .kibana_alerting_cases）のフィールドとして保存されます。

フィールド	説明
isSnoozedUntil	スヌーズ終了日時。単発スヌーズの場合に使用
snoozeSchedule	繰り返しスヌーズのスケジュール配列

snoozeSchedule の各要素：

フィールド	説明
duration	持続時間（ミリ秒）
rRule	繰り返しルール（iCal RRULE形式）
id	スヌーズスケジュールのID
skipRecurrences	スキップする特定の繰り返し日時

仕組み

スヌーズが有効かどうかはRule単位で評価されます。スヌーズ中であれば、そのRuleのすべてのActionのスケジューリングを丸ごとスキップします。個別アラートの状態は参照されません。

既存アラートへの影響

Ruleにスヌーズを設定すると、そのルールが生成している既存のアクティブアラートを含め、すべてのActionが次の評価サイクルから停止します。

スヌーズはアラートインスタンス単位ではなくRule単位で機能します。スヌーズを設定した直後の次の評価タイミングから、そのルール上のすべてのActionが実行されなくなります。スヌーズ期間が終了すると、自動的にActionの実行が再開されます。

設定方法

KibanaのRules一覧画面またはRule詳細画面から、Ruleのスヌーズを設定できます。期間を指定した単発スヌーズと、繰り返しスケジュールの両方に対応しています。

Flapping Detection

概要

Flapping Detection（フラッピング検出） は、短時間に「アクティブ」と「回復」を繰り返すノイジーなアラートを検出し、通知を抑制する機能です。閾値に達したアラートは「フラッピング状態」とみなされ、回復通知が一定回数の連続した回復を確認するまで遅延されます。

適用レベル

設定はグローバルレベル（またはRuleレベルで上書き可能）、フラッピング状態の追跡はAlertインスタンスレベルで行われます。

保存形式

グローバル設定はSaved Objectタイプ rules-settings として .kibana_alerting_cases インデックスに保存されます。

Ruleレベルの上書き設定はRuleのデータの flapping フィールドとして保存されます。

各アラートのフラッピング履歴は、アラートごとのメタデータとしてTask Managerが管理するタスク状態に保存され、評価サイクルをまたいで引き継がれます。

設定フィールド：

フィールド	デフォルト	説明
enabled	true	フラッピング検出の有効/無効
lookBackWindow	20	状態変化の履歴を保持する件数（1〜256）
statusChangeThreshold	4	フラッピングと判定する状態変化数（1〜256、lookBackWindow以下）

検出アルゴリズム

各アラートは直近の状態変化の履歴を持ちます。評価サイクルごとに以下の処理が行われます。

1. 前回と状態が変化したか記録し、直近 lookBackWindow 件分の履歴に追加
2. 履歴内の状態変化の回数をカウント
3. 状態変化数が statusChangeThreshold 以上であればフラッピングと判定

フラッピング中のアラートが回復した場合、回復通知はすぐには発火せず、statusChangeThreshold 回連続して回復が確認されるまで遅延されます（偽の回復通知を防ぐため）。

既存アラートへの影響

フラッピング検出の設定を変更すると、次の評価サイクルから新しい設定値で判定されます。ただし、それまでにアラートごとに蓄積された状態変化の履歴はリセットされません。

各アラートの状態変化履歴は評価サイクルをまたいで保持されます。たとえば「判定に使う履歴件数（lookBackWindow）」や「フラッピングと見なす変化数（statusChangeThreshold）」を変更しても、これまでの履歴は残ったまま新しい設定で再評価されます。

なお、フラッピングと判定されているアラートが回復に転じた後も、即座に「回復」扱いにはなりません。連続して一定回数の回復が確認されるまでアクティブアラートとして扱われ続けます。この挙動は設定変更後も同様に適用されます。

設定方法

Stack Management > Alerts and Insights > Rules Settings の「Alert Flapping Detection」セクションから設定できます。

Action Frequency / Throttle

概要

Action Frequency（旧称: Throttle）は、アラートが繰り返し発生したときにActionの実行頻度を制御する機能です。毎回通知するのではなく、ステータスが変わったときのみ、または一定間隔でのみ通知するよう設定できます。

適用レベル

Ruleレベル（全Actionへのデフォルト設定）およびActionレベル（個別のActionへの上書き設定）。Actionレベルの設定が優先されます。

保存形式

Ruleのデータに保存されます。

Ruleレベルのフィールド：

フィールド	説明
notifyWhen	通知タイミング（下記参照）
throttle	通知間隔（例: "5m", "1h"）。onThrottleInterval のときに使用

Actionレベルのフィールド（actions[].frequency）：

フィールド	説明
notifyWhen	RuleレベルのnotifyWhenを上書き
throttle	RuleレベルのthrottleをAction単位で上書き
summary	アラートをサマリー形式で通知するか

notifyWhen の値：

値	説明
onActiveAlert	アクティブなアラートがある毎チェックで通知
onActionGroupChange	アクショングループが変わったときのみ通知
onThrottleInterval	throttle で指定した間隔ごとに通知

仕組み

各アラートは「最後にActionが実行された時刻」を内部に記録しています。throttle設定が有効な場合、この時刻から指定の間隔が経過しているかどうかを毎サイクル確認し、まだ間隔内であればActionをスキップします。

既存アラートへの影響

throttle間隔を変更すると次の評価サイクルから新しい間隔で判定されますが、各アラートの「最後にActionを実行した時刻」はリセットされません。

各アラートの最終通知時刻は評価サイクルをまたいで保持されます。throttle間隔を変更した場合、変更前の最終通知時刻と変更後の間隔で次回の通知可否が判断されます。

例：あるアラートが10分前に最後に発火し、throttleを「5分」から「30分」に延長した場合、次の評価サイクルでは「最後の通知から10分しか経っていない」ため通知はスキップされます。意図せず通知が長時間来なくなる場合があるため注意が必要です。

通知タイミングの設定（onActionGroupChange → onActiveAlert など）を変更した場合は、次の評価サイクルから即座に新しいルールで動作します。

設定方法

Rule作成・編集画面のActions設定時に、各Actionの通知頻度を指定できます。

Mute（ミュート）

概要

Mute は、RuleまたはAlertインスタンスを永続的に無効化する機能です。Snoozeが「一時的な停止」であるのに対し、Muteは明示的に解除するまで効果が続きます。

適用レベル

• Ruleレベル（Mute All）: Ruleが生成するすべてのAlertのActionを無効化
• Alertインスタンスレベル: 特定のAlertインスタンスのみ無効化

保存形式

Ruleのデータに保存されます。

フィールド	説明
muteAll	Ruleの全Alertをミュート
mutedInstanceIds	ミュートする特定AlertインスタンスIDの配列

仕組み

Rule実行のたびにRuleの最新の設定が読み込まれます。ミュート対象のアラートIDは毎サイクル最新の状態で参照されるため、ミュートの設定変更は次の評価サイクルから即座に反映されます。

既存アラートへの影響

ミュートを設定すると、すでにアクティブなアラートも含めて、次の評価サイクルからActionが停止します。

ミュートはRuleの設定として保存され、評価のたびに最新の状態が参照されます。ルール全体をミュートした場合はそのルールのすべてのAction、インスタンス単位でミュートした場合は該当するアラートのActionが次のサイクルから実行されなくなります。ミュートを解除すれば次のサイクルから即座に再開されます。

インスタンスレベルのミュートはアラートのID（例: ホスト名など）に対して設定されるため、一度ミュートしたアラートが回復して再発生した場合も、同じIDであればミュートが継続されます。

設定方法

Rules一覧やRule詳細画面から「Mute rule」でRuleごとミュートできます。個別のAlertインスタンスのミュートはAlert一覧から操作できます。

Alert Suppression（Security Solution専用）

概要

Alert Suppression はElastic Security専用の機能です。同じフィールド値を持つ重複したアラートを集約・抑制します。Kibana Alert全体の抑制機能とは異なり、アラートの生成段階で重複を排除します。

適用レベル

Alertレベル（アラート生成時に重複を集約）

保存形式

SecurityルールのデータのパラメータとしてElasticsearchに保存されます。

フィールド	説明
group_by	集約するフィールド名（最大3つ）
duration	抑制期間（秒・分・時間で指定）
missing_fields_strategy	対象フィールドが存在しないイベントの扱い（個別生成または集約）

仕組みと既存アラートへの影響

Alert Suppressionはアラート生成時に適用されます。同じ集約キーを持つアクティブなアラートがすでに存在する場合、新たにマッチしたイベントは別のアラートを生成せず、既存アラートの抑制期間を延長し、抑制されたドキュメント数を加算します。抑制ウィンドウ内にマッチドキュメントが継続して届く限り、既存アラートは更新され続けます。

Alert Suppressionの設定を変更しても、変更前にすでに生成されたアラートには影響しません。 新しい設定は、設定変更後に新たに生成されるアラートからのみ有効になります。SnoozeやMuteのように既存アラートのActionを即座に止める効果はありません。

集約されたアラートには以下の情報が付与されます。

• 集約のキーとなったフィールドと値
• 集約期間の開始・終了日時
• 抑制されたドキュメント数

Alerts Filter

概要

Alerts Filter は、個別のActionに対してKQLまたは時間帯フィルターを設定し、特定の条件を満たすアラートが発生したときのみそのActionを実行する機能です。

適用レベル

Actionレベル（個別のActionに設定）

保存形式

RuleのデータのAction設定フィールドとして保存されます。

フィールド	説明
query.kql	KQLクエリ文字列
query.filters	Elasticsearchフィルター
query.dsl	ElasticsearchクエリDSL
timeframe	時間帯フィルター（曜日・時間帯・タイムゾーン）

仕組みと既存アラートへの影響

Alerts Filterは毎評価サイクルでその時点のアラートデータに対して動的に評価されます。アラートの作成時だけでなく、毎サイクルフィルター条件との照合が行われます。

フィルターの条件を変更すると、次の評価サイクルから即座に既存のアクティブアラートにも反映されます。 変更後の条件を満たさなくなったアラートはそのサイクルからActionの実行が止まり、逆に条件を満たすようになったアラートはそのサイクルからActionが実行されるようになります。

設定方法

Rule作成・編集画面のActions設定で、各Actionに「Filter」を追加することで設定できます。