この記事はKibana Alertについての連続記事の一部です。
Alertの概念・ライフサイクル・保存形式について解説します。
Alertとは
Kibana AlertingにおけるAlertとは、Ruleの条件が満たされたときに生成されるインスタンスです。RuleがAlertを「生成する」という表現をしますが、正確には「アラートの状態を管理する」というイメージに近く、条件が継続している間はアラートがアクティブな状態として追跡されます。
AlertとActionの違い
AlertとActionは混同されやすいですが、役割が異なります。
- Alert: 「条件が現在満たされているか」という状態を表すオブジェクト
- Action: Alertの状態変化をトリガーとして実行される処理（メール送信、Webhookなど）
Ruleの評価サイクルごとにAlertの状態が更新され、Actionはその状態変化に応じて実行されます。Snoozeを設定してActionを止めてもAlertは生成され続けるのはこのためです。
AlertインスタンスとインスタンスID
一つのRuleが複数のAlertを同時に生成することがあります。たとえば「複数のホストのCPU使用率を監視するルール」では、ホストAとホストBがそれぞれ独立したAlertインスタンスとして管理されます。
各AlertインスタンスはRule Type固有のインスタンスIDで識別されます。インスタンスIDは何をキーとして使うかRule Typeによって異なります。
| Rule Type | インスタンスIDの例 |
|---|---|
| Metric threshold（インフラメトリクス） | ホスト名、Kubernetesポッド名など |
| Log threshold（ログ） | 検出したログのグループ値 |
| Index threshold / ES Query | 固定ID（query matchedなど） |
| SLO burn rate | SLO ID |
| Security: Custom Query Rule | ドキュメントのフィールド値 |
Alertのライフサイクル
AlertはRuleの評価ごとに状態が遷移します。
状態の種類
| ステータス | 説明 |
|---|---|
active |
Ruleの条件が満たされており、アラートが発生中 |
recovered |
以前アクティブだったが、条件を満たさなくなった |
untracked |
Ruleの削除・無効化などにより追跡対象から外れた |
状態遷移の流れ
[条件を満たす]
↓
active ──────────────────────────────────────→ untracked
↓（条件を満たさなくなる） ↑
recovered （Ruleの削除・無効化）
↓（次の評価でも条件を満たさない場合）
（Elasticsearchから削除 or 保持期間経過後に自動削除）
アクティブアラートの引き継ぎ
Ruleは評価のたびにElasticsearchからTask Managerのタスク状態にアクティブなAlertインスタンスの情報（インスタンスID・状態・最終通知時刻・フラッピング履歴など）を保持しています。次の評価サイクルではこの情報を引き継いで「前回もアクティブだったか」「状態が変わったか」を判断します。
Untrackedへの遷移
以下のタイミングでAlertが untracked に遷移します。
- Ruleが削除されたとき
- Ruleが無効化（disabled）されたとき
- アクティブなAlertが長期間放置され、自動クリーンアップの対象になったとき
untracked になると kibana.alert.end に現在時刻が記録され、Actionは実行されなくなります。
Alertのアクショングループ（Action Group）
Alertには**アクショングループ（Action Group）**という概念があります。これはAlertの「状態の種類」をより細かく表現するもので、どのActionを実行するかの分岐に使われます。
組み込みアクショングループ
| グループ | 説明 |
|---|---|
| （Rule Type固有のデフォルトグループ） | Alertがアクティブなとき |
recovered |
Alertが回復したとき（自動回復が有効な場合） |
カスタムアクショングループの例
Rule TypeによってはAlertの重大度などに応じた複数のグループを定義できます。たとえばMetric threshold ruleでは critical・warning などのグループを定義して、それぞれに異なるActionを設定できます。
アクショングループが変化した場合（例: warning → critical）、Action Frequencyを onActionGroupChange に設定していると通知がトリガーされます。
autoRecoverAlerts
Rule Typeのオプションで autoRecoverAlerts が有効（デフォルト）の場合、条件を満たさなくなったAlertは自動的に recovered グループに遷移し、recover用のActionが実行されます。一部のRule Type（Security Solutionなど）はこの自動回復を無効にして、手動でのワークフロー管理を前提とした設計になっています。
Alertの保存形式
AlertはElasticsearchのインデックスに直接ドキュメントとして保存されます。保存先のインデックスはRule Typeのカテゴリによって異なります。
インデックスの命名規則
Alert用インデックスは以下のパターンで命名されます。
.alerts-{registrationContext}.alerts-{namespace}
実際のデータは以下の内部インデックスに書き込まれ、エイリアス経由でアクセスします。
（書き込み先） .internal.alerts-{registrationContext}.alerts-{namespace}-000001
（エイリアス） .alerts-{registrationContext}.alerts-{namespace}
カテゴリ別の保存先
| カテゴリ | インデックス例 |
|---|---|
| management（Stack rules） | .alerts-stack.alerts-default |
| observability（APM） | .alerts-observability.apm.alerts-default |
| observability（Logs） | .alerts-observability.logs.alerts-default |
| observability（Metrics） | .alerts-observability.metrics.alerts-default |
| observability（SLO） | .alerts-observability.slo.alerts-default |
| observability（Uptime/Synthetics） | .alerts-observability.uptime.alerts-default |
| securitySolution | .alerts-security.alerts-default |
default の部分はKibanaスペースIDになります。スペース production を使っている場合は *.alerts-production となります。
なお一部の古いRule Type（Stack MonitoringのクラスターヘルスチェックなどStack Managementに含まれる監視系）はこの仕組みを使わず、Event Logにのみ記録されます。
Alertドキュメントの検索例
以下のクエリでアクティブなAlertを取得できます。
GET .alerts-*/_search
{
"query": {
"term": {
"kibana.alert.status": "active"
}
}
}
特定のRuleのAlertに絞る場合は kibana.alert.rule.uuid を使います。
GET .alerts-*/_search
{
"query": {
"bool": {
"filter": [
{ "term": { "kibana.alert.rule.uuid": "<rule-id>" } },
{ "term": { "kibana.alert.status": "active" } }
]
}
}
}
主要フィールド
| フィールド | 説明 |
|---|---|
kibana.alert.status |
アラートのステータス（active / recovered / untracked） |
kibana.alert.instance.id |
アラートインスタンスのID（ホスト名など） |
kibana.alert.uuid |
アラートのUUID（アクティブ期間ごとに新たに採番） |
kibana.alert.start |
アラートが初めてアクティブになった日時 |
kibana.alert.end |
アラートが回復またはuntracked化した日時 |
kibana.alert.duration.us |
アラートの継続時間（マイクロ秒） |
kibana.alert.action_group |
現在のアクショングループID |
kibana.alert.reason |
アラートの理由（人間が読める説明文） |
kibana.alert.flapping |
フラッピング状態かどうか |
kibana.alert.maintenance_window_ids |
適用されているMaintenance WindowのID |
kibana.alert.workflow_status |
ワークフロー状態（open / acknowledged / closed） |
kibana.alert.rule.uuid |
親RuleのID |
kibana.alert.rule.name |
親Ruleの名前 |
kibana.alert.rule.type_id |
Rule TypeのID |
kibana.alert.rule.category |
Rule Typeの表示名 |
kibana.alert.rule.consumer |
Ruleのコンシューマ（stackAlertsなど） |
kibana.alert.rule.execution.uuid |
直近のRule実行UUID |
kibana.space_ids |
Ruleが属するKibanaスペースID |
kibana.version |
Alert生成時のKibanaバージョン |
KibanaでのAlertの閲覧
Alertの閲覧場所はRuleのカテゴリによって異なります。
Stack Management（managementカテゴリ）
Stack Management > Alerts and Insights > Alerts から閲覧できます。このページではすべてのカテゴリのAlertを横断的に表示できます。
Observabilityアプリ（observabilityカテゴリ）
Observability > Alerts からObservabilityカテゴリのAlertを閲覧できます。APM・インフラ・ログ・SLOなどのObservabilityルールが生成したAlertがここに表示されます。
Elastic Securityアプリ（securitySolutionカテゴリ）
Security > Alerts からSecurityカテゴリのAlertを閲覧できます。Security専用のトリアージ機能（ワークフロー管理、ケースへの追加、調査機能など）が利用できます。
Alertの共通UI機能
どの閲覧場所でも以下の操作が共通して利用できます。
- アラートのステータスによるフィルタリング
- ルール・期間・重大度などでの絞り込み
- アラートの詳細表示（発生日時・ルール情報・アクショングループなど）
- インスタンス単位のミュート設定
- ケース（Cases）への追加