Kibana AlertのObservabilityルール

この記事はKibana Alertingについての連続記事の一部で、Observabilityカテゴリのルールタイプに固有の設定と動作を解説します。

別記事でObservabilityカテゴリのRule Typeの一覧を紹介しました。この記事では、各ルールタイプの具体的な設定項目・動作について詳しく解説します。

Custom threshold と Metric threshold

どちらもObservabilityカテゴリに属するメトリクス閾値監視のRule Typeです。

• Custom threshold: データビューを使って任意のメトリクスを柔軟に監視する（新しいRule Type）
• Metric threshold: インフラメトリクス（Metrics Explorer）の閾値を監視する（旧来のRule Type）

機能面でいくつかの重要な違いがあるため、以降でポイントを説明します。

データなし（No Data）の扱い

Observabilityのメトリクスルールは「データが届かない状況」を検知するための設定を持っています。Custom threshold と Metric threshold では設定方式が異なります。

Custom threshold の場合

2つのチェックボックスが用意されており、グループ化（groupBy）の有無によって表示・動作が切り替わります。

alertOnNoData（Alert me if there's no data）

• グループ化（groupBy）を使用しない場合に適用される
• クエリ結果が全くない場合に NO_DATA アクショングループでアラートを発火するかどうかを制御する
• デフォルト: false（チェックなし）
• ユースケース例: 「ログが届かなくなったら通知する」「全体的なデータ欠落を検知する」

alertOnGroupDisappear（Alert me if a group stops reporting data）

• グループ化（groupBy）を使用する場合に適用される
• 以前の評価サイクルで存在していたグループが次の評価サイクルでデータを送信しなくなった場合に NO_DATA アクショングループでアラートを発火するかどうかを制御する
• デフォルト: false（チェックなし）。ただし、既存ルールとの後方互換性のため、明示的に false が設定されていない場合は true として動作する内部実装になっている
• ユースケース例: 「監視対象ホストが突然メトリクスを送らなくなったら通知する」

2つの設定の使い分け

groupBy の有無	有効な設定	検知する状況
groupByなし	alertOnNoData	全体的なデータ欠落
groupByあり	alertOnGroupDisappear	個別グループの消失

UIではチェックボックスが1つだけ表示され、groupByの有無に応じて自動的にどちらの設定に反映するかが切り替わります。

設定の組み合わせパターン

alertOnNoData	alertOnGroupDisappear	動作
true	false	グループ化なし監視でデータ欠落を検知する
false	true	グループ化あり監視で個別グループの消失を検知する
true	true	グループ消失も全体データ欠落も両方検知する

alertOnNoData = true かつ alertOnGroupDisappear = true の構成で、グループ化あり監視を行う場合の具体例を示します。

• T1 の評価で host-a、host-b、host-c の3グループが存在していた
• T2 の評価で全グループのデータが消失した

この場合、3件の NO_DATA アラートが発生します（消失したグループごとに1件）。alertOnGroupDisappear によってグループごとのアラートインスタンスが追跡されており、それぞれが個別に NO_DATA として報告されるためです。

Action設定では NO_DATA アクショングループに対して通知先や通知内容を個別に設定できます。これにより、「データが欠落した場合だけ別のチャンネルへ通知する」などの設定が可能です。

Metric threshold の場合

Metric threshold では noDataBehavior という単一パラメータを持ちます。UIでラジオボタンから以下の3択で選択します。

UI表示	動作
Recover active alerts	データがない場合、アラートを回復（Recovered）扱いにする（デフォルト）
Alert me about the missing data	データがない場合、NO_DATAアクショングループでアラートを発火する
Do nothing	データがない場合、直前の状態を維持する（アラートはアクティブのまま）

Metric threshold ではグループ化の有無に関わらず、この単一の設定で動作を制御します。これが Custom threshold との主な違いです。

両者の比較

項目	Custom threshold	Metric threshold
データなし設定の方式	2つのフラグ（alertOnNoData / alertOnGroupDisappear）	単一の noDataBehavior（3択）
groupByの有無による切り替え	あり（用途に応じた2つの設定）	なし（単一設定で統括）
デフォルト動作	アラートなし（false）	回復扱い（recover）

Warning threshold（警告閾値）

Metric threshold と Inventory では、条件ごとに Warning threshold（警告閾値） を追加できます。UIの「Add warning threshold」ボタンから追加します。

設定するとアクショングループが2段階になります。

• ALERT（重大）: 通常の閾値を超えた場合
• WARNING（警告）: 警告閾値を超えた場合（重大には達していない）

Action設定でWARNINGグループ向けのActionを別途設定できます。たとえば「重大はPagerDutyでオンコール対応、警告はSlackへの通知のみ」といった運用が可能です。

Custom threshold にはこの機能がありません（単一の ALERT アクショングループのみ）。

アクショングループの違い

ルールタイプによってアクショングループが異なります。Action設定ではこれらのグループごとに異なる通知先・通知内容を設定できます。

Rule Type	アクショングループ
Custom threshold	ALERT、NO_DATA、Recovered
Metric threshold	ALERT、WARNING、NO_DATA、Recovered

groupBy の動作

Custom threshold と Metric threshold ともに、groupByを設定するとグループごとに独立したAlertインスタンスが生成されます。

• groupBy: host.name の場合、host-a / host-b / host-c がそれぞれ別のAlertインスタンスになる
• AlertインスタンスのIDはグループの値（ホスト名など）になる

これは別記事（alerts.md）で説明したAlertインスタンスIDの概念に対応しています。インスタンスIDを使うことで、ホストごとにアラートの状態が独立して管理されます。

データソース・フィルターの設定方法の違い

項目	Custom threshold	Metric threshold
データソース指定	データビューを選択	Metrics Explorerのソース設定を使用
フィルター設定	Unified Search Bar（KQL + UI フィルター）を統合的に設定	KQL フィルターテキストを直接入力（より簡易なUI）

Inventory

インフラノード（host、container、Kubernetes pod 等）レベルのメトリクスを監視するRule Typeです。Metric threshold に近い設計ですが、監視対象がノードタイプに特化しています。

固有の設定

nodeType（ノードタイプ）

監視対象のノードタイプ（host、docker、k8s pod 等）を指定します。UIでノードタイプを選択すると、そのタイプに対応するプリセットメトリクスが選択できるようになります。

プリセットメトリクス

CPU使用率・メモリ使用率・ディスク使用率・ネットワーク送受信量など、インフラ監視でよく使われるメトリクスがプリセットとして用意されています。カスタムメトリクスも設定可能です。

Warning threshold（警告閾値）

Metric threshold と同様に警告閾値を設定でき、ALERT / WARNING の2段階アクショングループを利用できます。

alertOnNoData（データなし通知）

データがない場合にアラートを発火するかどうかを設定します。Custom threshold の alertOnNoData と同様の動作です。

Log threshold

ログの件数や比率を閾値と比較してアラートを生成するRule Typeです。メトリクスではなくログドキュメント数ベースの監視を行います。

固有の設定

Count ルールと Ratio ルールの2モード

Log threshold は2つの動作モードを持ちます。

• Count ルール: 条件に一致したログ件数が閾値を超えたらアラートを発火する
• Ratio ルール: 2つの条件（分子・分母）を設定し、その比率（割合）が閾値を超えたらアラートを発火する
  • 例: 「エラーログ数 / 全ログ数が10%を超えたらアラート」のような設定が可能

ログ検索条件（criteria）

KQLではなく、フィールド名・比較演算子・値の組み合わせで条件を定義します。利用できる比較演算子は以下の通りです。

演算子	意味
more than / more than or equals / less than / less than or equals / equals / does not equal	数値比較
matches / does not match	フィールド値との一致・不一致
matches phrase / does not match phrase	フレーズ一致・不一致

groupBy

フィールドごとにグループ化して個別にアラートを発火できます。

APM Anomaly

Machine Learning（ML）の異常検知機能を使ってAPMサービスの異常を検出するRule Typeです。固定閾値ではなく、統計的な異常をMLが自動的に判定します。

固有の設定

anomalySeverityType（異常の重大度レベル）

検知する異常の重大度レベルを選択します。

レベル	説明
critical	最も重大な異常のみ検知
major	重大・主要な異常を検知
minor	軽微な異常まで検知
warning	警告レベル以上の異常を検知

このレベル以上の異常が検出された場合にアラートが発火します。

anomalyDetectorTypes（検知する異常のタイプ）

監視する異常のタイプを指定します。複数タイプを同時に監視できます。

タイプ	説明
txLatency	レイテンシの異常
txThroughput	スループットの異常
txFailureRate	エラー率の異常

serviceName / transactionType / environment

対象サービス、トランザクションタイプ、環境（production / staging 等）でフィルタリングできます（いずれもオプション）。

時間ウィンドウの制約

MLの精度確保のため、最低30分以上の時間ウィンドウの設定が必要です。

APMルール（Latency threshold / Error count threshold / Failed transaction rate threshold）

3つのAPMルールはいずれもAPMのトランザクションデータを対象とした閾値監視です。共通の設定と、各ルール固有の設定があります。

共通の設定

設定項目	説明
serviceName	対象サービス名（オプション、未指定なら全サービス対象）
transactionType	トランザクションタイプ（オプション）
environment	対象環境（production / staging 等）
windowSize / windowUnit	評価期間（例: 5分、1時間）
groupBy	フィールドごとのグループ化（オプション）

Latency threshold 固有の設定

aggregationType（集計方法）

レイテンシの集計方法を以下から選択します。

選択肢	説明
avg	平均値
95th	95パーセンタイル
99th	99パーセンタイル

平均ではなく P95 / P99 で監視することで、遅い一部のリクエストを見逃さない設定が可能です。

transactionName

特定のトランザクション名に絞り込む（オプション）。

threshold

レイテンシの閾値をミリ秒単位で指定します。

Error count threshold 固有の設定

errorGroupingKey

特定のエラーグループ（スタックトレースのハッシュ）に絞り込みます（オプション）。特定の既知エラーのみを監視・除外する用途に使えます。

threshold

エラー件数の閾値を指定します。

Failed transaction rate threshold 固有の設定

threshold

トランザクション失敗率をパーセンテージ（0〜100）で指定します。

transactionName

特定のトランザクション名に絞り込む（オプション）。

SLO burn rate

SLO（Service Level Objective）のエラーバジェット消費速度（バーンレート）を監視するRule Typeです。他のルールと異なり、複数の優先度レベルを持つアクショングループを使えます。

固有の設定

sloId（監視対象のSLO ID）

監視対象のSLO IDを指定します（必須）。

windows（バーンレートウィンドウ）

バーンレートウィンドウの配列を設定します（必須）。

各ウィンドウには以下を設定します。

• longWindow（長期ウィンドウ）: 長い時間ウィンドウでのバーンレート閾値
• shortWindow（短期ウィンドウ）: 短い時間ウィンドウでのバーンレート閾値
• actionGroup: このウィンドウに対応するアクショングループ

デュアルウィンドウ評価: 長期・短期の両方でバーンレートが閾値を超えた場合のみアラートが発火します。短期間のスパイクによる偽陽性を減らす目的の設計です。

アクショングループ

SLO burn rate は最大5段階のアクショングループを持ちます。

アクショングループ	説明
Critical	最も優先度が高いアラート
High	高優先度のアラート
Medium	中優先度のアラート
Low	低優先度のアラート
Suppressed	別ルールによって抑制されたアラート

各グループに対して異なるActionを設定できます。たとえば「CriticalはPagerDutyで即座にオンコール対応、LowはSlackへの通知のみ」のような設定が可能です。

Synthetics monitor status

Syntheticsモニター（外形監視）のステータスを監視するRule Typeです。可用性監視（UP/DOWN状態）に特化しており、独自の設定が多くあります。

固有の設定

downThreshold（連続失敗回数の閾値）

何回連続してチェックが失敗したらアラートするかを指定します。

• デフォルト: 3回
• 一時的な失敗による偽陽性を減らす目的で設定します

locationsThreshold（ロケーション数の閾値）

何か所の観測ポイントで同時にダウンしたらアラートするかを指定します。

• デフォルト: 1か所
• 複数のロケーションから監視している場合、1か所のみの失敗はネットワーク問題の可能性があります。複数か所での同時確認を条件にすることで、誤報を抑制できます

window（評価ウィンドウ）

評価の基準となるウィンドウを2つの方式から選択します。

方式	説明
時間ベース	過去X分/時間の間のチェック結果を評価する
チェック数ベース	直近N回のチェック結果を評価する

recoveryStrategy（回復タイミングの制御）

アラートの回復タイミングを以下から選択します。

設定値	説明
firstUp	1回でもUPを確認したら即座に回復する
conditionNotMet	設定した条件（downThreshold等）が満たされなくなったら回復する

フィルター条件

監視対象を絞り込むためのフィルターを設定できます。

• モニターID
• タグ
• ロケーション
• モニタータイプ
• プロジェクト

ES|QL Rule（Observability版）

ES|QL（Elasticsearch Query Language）を使って任意のObservabilityデータを検索・集計してアラートを生成するRule Typeです。KQL/DSLでは難しい複雑な集計・変換・フィルタリングが可能な反面、閾値設定には制約があります。

固有の設定と制約

esqlQuery（ES|QLクエリ）

ES|QLクエリを記述します（必須）。通常のKQL/DSLでは難しい複雑な集計・変換・フィルタリングが可能です。

timeField（タイムスタンプフィールド）

時間ウィンドウの基準となるタイムスタンプフィールドを指定します（必須）。

閾値の制約

「クエリ結果が1件以上返ったらアラート」という動作に固定されており、数値の閾値は設定できません。閾値ではなく、ES|QLクエリ自体で絞り込み条件を表現する設計になっています。

groupBy の制約

Custom threshold のような任意フィールドでのグループ化はできません。「行ごと（row）」か「全体（all）」の2択となります。