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?

Kibana Alertにおけるルールとは

0
Posted at

この記事は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は以下のフローでタスクを処理します。

  1. ポーリング: Task Managerは定期的(デフォルト3秒間隔)にElasticsearchへポーリングし、runAt <= 現在時刻 + 30秒 の条件を満たす実行可能なタスクを取得します。
  2. Claim(占有): 複数のKibanaインスタンスが同じタスクを重複実行しないよう、タスクに対してオーナーシップを取得(Claim)します。Claimはupdate-by-queryもしくはmgetベースの戦略で実装されており、クラスター内の競合(バージョンコンフリクト)を検知した場合はポーリング間隔を動的に延長してES負荷を低減します。
  3. Worker Pool: Task Managerはワーカープールを持ち、同時実行数を制御します。タスクはタイプごとに最大並列数が設定されており、容量を超えたタスクは次のポーリングサイクルまで待機します。
  4. 実行と再スケジュール: タスク実行後、次回の 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の使い方については、別記事で解説します。

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?