この記事はKibana Alertについての連続記事の一部です。
この記事ではKibana AlertにおけるRuleとは何かについて説明します。
Rule
Kibana AlertにおけるRuleとは、アラートをトリガーする条件・スケジュール・アクションを定義したオブジェクトです。定期的に評価が実行され、条件を満たした場合にAlertが生成され、Actionが実行されます。
Ruleの主要コンポーネント
Ruleは以下の要素で構成されます。
- ルールタイプ: どのような条件でアラートを検出するかを定義する種類。後述のカテゴリがある。
- 条件: ルールタイプごとに異なる検出条件。例えば、クエリの閾値や集計方法などを設定する。
- チェック間隔: ルールを評価する頻度。例えば「1分ごと」「5分ごと」などを設定する。
- アクション: 条件が満たされたときに実行するアクション。メール送信やWebhook呼び出しなど。
Ruleの作成
KibanaのUIからルールを作成する場合、ルールのカテゴリによって操作する画面が異なります。
- Stack / Observabilityルール: Stack Management > Rules 画面、またはObservability > Rules 画面で「Create rule」をクリックしてルールを作成します
- Securityルール: Elastic Security アプリ内の Detection Rules 画面から作成します
Ruleの保存形式
RuleはKibanaのSaved Objectsとして管理されます。Saved ObjectsはKibanaがElasticsearchの専用インデックスを使って内部データを永続化する仕組みです。
Ruleのデータは .kibana_alerting_cases インデックスに、Saved ObjectタイプとしてはRule Typeのカテゴリに関わらずすべて alert という名前で保存されます。どのRule Typeのルールも同じインデックス・同じSaved Objectタイプを共有しており、alertTypeId フィールドによってRule Typeが区別されます。
インデックス: .kibana_alerting_cases
Saved Objectタイプ: alert
alertTypeId(例):
- .index-threshold (Index threshold)
- .es-query (Elasticsearch query)
- siem.queryRule (Security: Custom Query Rule)
- observability.rules.custom_threshold (Custom threshold)
...
以下のクエリーで、このインデックスからすべてのRuleを取得できます。
GET .kibana_alerting_cases/_search
{
"query": {
"bool": {
"filter": [
{
"term": {
"type": "alert"
}
}
]
}
}
}
Ruleのアクセス制御のために、各RuleはAPIキーを持ちます。このAPIキーはRuleを作成・更新したユーザーの権限を引き継ぐ形で生成され、Saved Object内に暗号化された状態で保存されます。Rule評価時はこのAPIキーを使ってElasticsearchへのクエリが実行されます。
なお、Security Solutionのプリビルドルールのテンプレート(プリビルドルールの定義情報)は例外で、security-rule という別のSaved Objectタイプとして .kibana_security_solution インデックスに保存されます。これは実際にインスタンス化されたルール(alert タイプ)とは別物で、変更不可のテンプレートとして管理されます。
| 種別 | Saved Objectタイプ | インデックス |
|---|---|---|
| 全カテゴリーのRule | alert |
.kibana_alerting_cases |
| Security プリビルドルールのテンプレート | security-rule |
.kibana_security_solution |
Rule Typeのカテゴリ
KibanaのRule Typeは内部的に category フィールドを持ち、Stack rule (management) / Observability (observability) / Security Solution (securitySolution) の3カテゴリに分類されます。
このうちKibanaの機能として、Securityのカテゴリーは特別で、Elastic Securityアプリ内のルールはすべてこのカテゴリーに属します。アラートを検知した時の自動レスポンスやインシデント管理など、セキュリティユースケースに特化した機能が提供されます。そのため、Security SolutionカテゴリのルールはElastic Securityアプリ内でのみ表示され、Stack ManagementのRules画面には表示されません。
Stack ruleとObservabilityはKibana全体で利用される一般的なルールタイプですが、Observabilityは特にAPM・インフラ・ログなどのオブザーバビリティユースケースに特化したルールが含まれます。
このカテゴリーについては公式ドキュメントに明確な説明がないため、以下のAPIのレスポンスを調べる必要があります。
各カテゴリとそこに属するRule Typeの対応は以下の通りです。
Stack rule / management カテゴリ
Stack Managementで管理できる汎用ルール群です。Elasticsearchのクエリ・集計に基づく検出ルールのほか、Stack MonitoringのクラスターヘルスチェックやML異常検知ジョブの監視ルールも含まれます。
| Rule Type | 概要 |
|---|---|
| Elasticsearch query | Query DSL / KQL / Lucene / ES|QL でクエリを実行し、マッチ件数や集計値を閾値と比較する |
| Index threshold | インデックスのフィールド値をcount/average/sum/min/maxで集計し、閾値と比較する |
| Tracking containment | ドキュメントが指定した境界インデックスの範囲内に入ったかどうかを検出する |
| Transform health | Continuous Transformのヘルスチェックを定期実行し、異常時にアラートを生成する |
| Anomaly detection | ML異常検知ジョブの結果を監視し、異常スコアが閾値を超えた場合にアラートを生成する |
| Anomaly detection jobs health | ML異常検知ジョブ自体の稼働状態を監視する |
| Cluster health | Elasticsearchクラスターのヘルス状態を監視する |
| License expiration | Elasticライセンスの有効期限を監視する |
| CPU Usage | ノードのCPU使用率を監視する |
| Disk Usage | ノードのディスク使用率を監視する |
| Memory Usage (JVM) | ノードのJVMヒープ使用率を監視する |
| Thread pool search rejections | 検索スレッドプールのリジェクト数を監視する |
| Thread pool write rejections | 書き込みスレッドプールのリジェクト数を監視する |
| Missing monitoring data | モニタリングデータの欠損を検出する |
| Nodes changed | クラスターのノード構成変化を検出する |
| Elasticsearch version mismatch | クラスター内のElasticsearchバージョン不一致を検出する |
| Kibana version mismatch | KibanaとElasticsearchのバージョン不一致を検出する |
| Logstash version mismatch | LogstashとElasticsearchのバージョン不一致を検出する |
| CCR read exceptions | Cross-Cluster Replicationの読み取りエラーを検出する |
| Shard size | シャードのサイズを監視する |
| Degraded docs | インデックス内のdegraded(劣化)ドキュメントを検出する |
Observability rule / observability カテゴリ
Observabilityアプリ専用のルール群です。APM・インフラ・ログ・SLO・Synthetics・Uptimeなど、オブザーバビリティ特有のユースケースに対応しています。アラートはObservabilityアプリ内にのみ表示されます。
| Rule Type | 概要 |
|---|---|
| Custom threshold | メトリクスの任意の閾値を設定してアラートを生成する |
| Metric threshold | インフラメトリクスの閾値を監視する |
| Inventory | インベントリビューのメトリクスを監視する |
| Log threshold | ログのマッチ件数を閾値と比較する |
| APM Anomaly | APMのレイテンシ・エラー率などのML異常を検出する |
| Latency threshold | APMのトランザクションレイテンシの閾値を監視する |
| Error count threshold | APMのエラー件数の閾値を監視する |
| Failed transaction rate threshold | APMのトランザクション失敗率の閾値を監視する |
| SLO burn rate | SLOのエラーバジェット消費率を監視する |
| Synthetics monitor status | Syntheticsモニターのステータスを監視する |
| Synthetics TLS certificate | SyntheticsモニターのTLS証明書の有効期限を監視する |
| Uptime monitor status | Uptimeモニターのステータスを監視する |
| Uptime TLS | UptimeモニターのTLS証明書の有効期限を監視する |
| Uptime TLS (Legacy) | Uptimeモニター(旧形式)のTLS証明書の有効期限を監視する(レガシー) |
| Uptime Duration Anomaly | Uptimeモニターのレスポンス時間の異常を検出する |
| ES|QL Rule | ES|QLクエリを使ってオブザーバビリティデータを検出する |
Security rule / securitySolution カテゴリ
Elastic Securityアプリ専用のルール群です。不審なイベントやインシデントをプリビルドまたはカスタムのルールで検出します。アラートはElastic Securityアプリ内にのみ表示されます。
| Rule Type | 概要 |
|---|---|
| Custom Query Rule | KQL/EQL/Luceneクエリで不審なイベントを検出する |
| Saved Query Rule | 保存済みクエリを使って不審なイベントを検出する |
| Threshold Rule | イベント件数が閾値を超えた場合に検出する |
| Event Correlation Rule | EQL(Event Query Language)でイベント相関を検出する |
| ES|QL Rule | ES|QLクエリでセキュリティイベントを検出する |
| Indicator Match Rule | 脅威インテリジェンスのインジケータとイベントをマッチングして検出する |
| Machine Learning Rule | MLジョブの異常スコアをもとにセキュリティ脅威を検出する |
| New Terms Rule | 初めて出現した値(新規ユーザー・IPなど)を検出する |
| Attack Discovery Schedule | Attack Discoveryの自動スケジュール実行ルール |
| Security Solution notification (Legacy) | セキュリティ通知(レガシー形式) |
管理画面の使い分け
Kibanaにはルールやアラートを管理・閲覧するための画面が複数あり、それぞれ対象とするルールカテゴリが異なります。どの画面で何ができるのかを整理します。
| 画面 | 表示対象 |
|---|---|
| Stack Management > Rules | management・observabilityカテゴリのルール |
| Observability > Rules | observabilityカテゴリのルール(一部Stack rulesを含む) |
| Elastic Security > Detection Rules | securitySolutionカテゴリのルール |
Stack Management > Rules
management・observabilityカテゴリのルールを横断的に管理できるプラットフォーム共通の画面です。securitySolutionカテゴリのルールはここには表示されません。Securityルールは内部的に siem という専用のプロデューサーとして登録されており、Stack Managementの画面からは除外されています。
Observability > Rules
Observabilityアプリに特化したルール管理画面です。observabilityカテゴリのルールのみを対象とするため、Stack Managementより表示対象が絞られています。なお、Observabilityのユースケースでよく使われる一部のStack rulesルール(Elasticsearch query・ML Anomaly Detection・Degraded Docs)もここで管理できます。
Elastic Security > Detection Rules
Securityルールを管理する専用画面です。Stack ManagementやObservabilityの画面には表示されないため、Securityルールの作成・編集・有効化はすべてElastic Securityアプリ内で行います。
スケジュール
Ruleは定期的に評価され、条件が満たされた場合にAlertが生成されます。評価の頻度はRuleごとに設定でき、例えば「1分ごと」「5分ごと」などを指定できます。
スケジューラーの概要
Kibana AlertはKibanaのTask Managerと呼ばれるタスク実行基盤の上で動作しています。Task ManagerはElasticsearchをタスクストアとして利用し、ポーリング方式でタスクを管理・実行します。
Ruleが作成されると、Task Manager上にそのRuleに対応する繰り返しタスクが登録されます。このタスクは設定したチェック間隔ごとに runAt タイムスタンプが更新され、繰り返し実行されます。
Task Manager ポーリング → 期限タスクをClaimして実行 → Rule評価 → 次回 runAt を更新
キューイングの仕組み
Task Managerは以下のフローでタスクを処理します。
-
ポーリング: Task Managerは定期的(デフォルト3秒間隔)にElasticsearchへポーリングし、
runAt <= 現在時刻 + 30秒の条件を満たす実行可能なタスクを取得します。 - Claim(占有): 複数のKibanaインスタンスが同じタスクを重複実行しないよう、タスクに対してオーナーシップを取得(Claim)します。Claimはupdate-by-queryもしくはmgetベースの戦略で実装されており、クラスター内の競合(バージョンコンフリクト)を検知した場合はポーリング間隔を動的に延長してES負荷を低減します。
- Worker Pool: Task Managerはワーカープールを持ち、同時実行数を制御します。タスクはタイプごとに最大並列数が設定されており、容量を超えたタスクは次のポーリングサイクルまで待機します。
-
実行と再スケジュール: タスク実行後、次回の
runAtが計算され、Elasticsearchのタスクドキュメントが更新されます。
高負荷時の挙動:スケジュールの遅延
高負荷時にもタスクはスキップされません。Workerの空きがない場合、そのポーリングサイクルではタスクが取得されず、次のポーリングサイクルで再試行されます。ただし、以下のような遅延が発生する場合があります。
-
実行遅延: ワーカーが全て埋まっている間、タスクはキューで待機します。
runAtを過ぎても実行されない時間が長くなると、Ruleの評価に遅延が生じます。 -
スケジュールドリフトの制御: タスク遅延の閾値(
taskDelayThresholdForPreciseScheduling)を設定することで、次回のrunAtの計算方法を制御できます。- 遅延が閾値未満の場合: 元の
runAtから次回を計算する(スケジュールドリフトを防ぐ精密モード) - 遅延が閾値以上の場合: 実際の実行完了時刻から次回を計算する(遅延を許容するモード)
- 遅延が閾値未満の場合: 元の
-
タイムアウト: Ruleタイプごとに実行タイムアウトが設定されており(
ruleTaskTimeout)、超過した場合はその実行がキャンセルされ、次回のスケジュールは通常通り行われます。タイムアウト時にアクションを発火しないように設定(cancelAlertsOnRuleTimeout)することもできます。
GapとBackfill
スケジュールの遅延やKibanaノードのダウンにより、Ruleが予定通りに実行されなかった期間を Gap(ギャップ) と呼びます。Gapが生じると、その期間のデータが検査されず、アラートの「見逃し」が発生する可能性があります。
Kibanaにはこのようなgapを事後的に埋める Backfill(バックフィル) という仕組みが用意されており、過去の期間を指定して遡って再実行させることができます。Backfillは全カテゴリーのRuleで利用可能で、Security Solutionでは複数ルールを一括処理する専用APIも提供されています。
GapとBackfillの詳細な仕組みやAPIの使い方については、別記事で解説します。