アラートルールスキーマ

アラートルールは alert_rules テーブルに保存され、POST /v1/alert-rules で送信されます。このページはワイヤーフォーマットです。真実の出所：internal/manager/model/alert/model.go。

ワイヤー形式

{
  "rule_key": "host_cpu_high",
  "kind": "metric_raw",
  "name": "Host CPU pegged",
  "source_type": "ongrid_builtin",
  "scope_type": "host",
  "join_mode": "all",
  "severity": "warning",
  "enabled": true,
  "conditions": [
    { "expr": "node_cpu_usage_percent > 90" }
  ],
  "labels":      { "team": "sre", "service": "host" },
  "annotations": { "summary": "CPU on {{$labels.device_id}} above 90%" },
  "runbook_url": "https://wiki.example.com/runbooks/host-cpu",
  "notify_channel_ids": [12, 17],
  "notify_window_seconds": 600,
  "notify_min_fires": 3
}

フィールドリファレンス

Identity

フィールド	型	必須	説明
rule_key	string	はい	dedupe キーと incident.rule で使われる安定 lower_snake 識別子。一意。
name	string	はい	表示名。
enabled	bool	いいえ（デフォルト true）	無効ルールは evaluator にスキップされ、「active」フィルターから隠される。

Source / scope

フィールド	型	必須	説明
source_type	enum	はい	ongrid_builtin、prometheus_external。組み込みルールは正典の rule_key 値を持つ。外部ルールはインポートされた Prometheus アラートルールファイルから来る。
scope_type	enum	はい	host、global、monitoring_pipeline。evaluator がどのディメンションでグルーピングするかを決める —— host は device_id ごとに 1 つのインシデント、global はシステム全体で 1 つ、monitoring_pipeline は内部パイプラインヘルスルール用。
join_mode	enum	はい	all（すべての条件がマッチ必要）、any（いずれかの条件がマッチ）。conditions の要素が複数のときのみ関係する。

Kind

kind は evaluator が conditions をどう解釈するかを判別します。各 kind が異なるサブ evaluator を駆動します。

Kind	ステータス	何をするか	Conditions の形
metric_threshold	UI のみ入力	フレンドリーフォーム。biz レイヤーが保存時に metric_raw に書き直す。この kind をディスクで見ることはない。	[{ "metric": "cpu_pct", "operator": ">=", "threshold": 90, "window": "5m", "for": "2m", "aggregator": "avg" }]
metric_raw	live	任意の PromQL。ticker 駆動。	[{ "expr": "rate(http_500[5m]) > 0.1" }]
metric_anomaly	live	ローリングベースラインからの逸脱（z スコア）。PromQuerier 経由 ticker 駆動。	[{ "metric": "node_cpu_usage_percent", "window": "1h", "z_threshold": 3.0 }]
metric_forecast	live	将来ウィンドウ内に静的しきい値をまたぐ線形外挿（predict_linear）。	[{ "metric": "node_filesystem_avail_bytes", "window": "1h", "forecast_for": "24h", "below": 1073741824 }]
metric_burn_rate	live	SLO エラーバジェット multi-window multi-burn-rate（Google SRE Workbook）。	[{ "good": "sum(rate(http_2xx[1h]))", "total": "sum(rate(http_total[1h]))", "slo": 0.999, "long": "1h", "short": "5m" }]
log_match	live（Phase-B）	ヒットすると発火する LogQL パターン。	[{ "expr": "{device_id=\"{{.device_id}}\"} |= \"panic\"" }]
log_volume	live（Phase-B）	しきい値超えの LogQL ストリームレート。	[{ "expr": "sum(rate({app=\"foo\"}[5m])) > 100" }]
trace_latency	live（Phase-B）	サービスのしきい値超え TraceQL p95 / p99。	[{ "service": "payments", "percentile": 95, "above_ms": 800, "window": "5m" }]
trace_error_rate	live（Phase-B）	しきい値超えの TraceQL エラースパン分率。	[{ "service": "payments", "above_percent": 1.0, "window": "5m" }]

完全な Go enum は model/alert/model.go にあります：

const (
    RuleKindMetricThreshold = "metric_threshold" // UI-only input
    RuleKindMetricAnomaly   = "metric_anomaly"
    RuleKindMetricForecast  = "metric_forecast"
    RuleKindMetricBurnRate  = "metric_burn_rate"
    RuleKindMetricRaw       = "metric_raw"
    RuleKindLogMatch        = "log_match"
    RuleKindLogVolume       = "log_volume"
    RuleKindTraceLatency    = "trace_latency"
    RuleKindTraceErrorRate  = "trace_error_rate"
)

レガシー kind（edge_offline、prom_query、ingest_health、edge_absence、health_ingest、event_internal）は保存時にサイレントに metric_raw にエイリアスされます。

Conditions

conditions は配列です。各要素の形は kind に依存します —— 上の表を参照。join_mode は全要素がマッチ必要（all）か、いずれか（any）かを決めます。

metric_threshold（UI フォーム）では、各 condition は RuleCondition：

type RuleCondition struct {
    Metric     string  `json:"metric"`            // e.g. "cpu_pct"
    Operator   string  `json:"operator"`          // ">", ">=", "<", "<=", "=="
    Threshold  float64 `json:"threshold"`         // numeric trigger
    Window     string  `json:"window,omitempty"`  // e.g. "5m"
    For        string  `json:"for,omitempty"`     // sustain duration
    Aggregator string  `json:"aggregator,omitempty"` // avg / max / min
}

biz レイヤーは保存時にこれらを正典のクローズドセットホストメトリクス（node_cpu_usage_percent、node_memory_used_percent、node_filesystem_used_percent、node_load1、…）を使って metric_raw expr にコンパイルします。

Severity

値	扱い
info	記録される。通知はチャネルの match_severity_min でゲート（ほとんどのチャネルはこのフロアをスキップ）
warning	デフォルト
critical	サイレンスされない限り常に通知

チャネルの match_severity_min を warning にすると warning + critical を受け入れます。critical は critical のみ。空は何でも受け入れます。

Labels と annotations

JSON として保存される自由形式の key/value マップ。

• labels は発火時にインシデントの labels に追加され、グルーピング / dedupe に使われます。よくあるもの：service、team、env。
• annotations は発火時にインシデントスナップショットに対する Go テンプレート構文でテンプレート展開されます —— たとえば summary: "CPU on {{$labels.device_id}} above 90%"。

Runbook

runbook_url はインシデント詳細とチャット画面で AI 調査レポートの隣に逐語表示されます。社内 runbook / プレイブックにリンクするのに使用してください。

通知ダンピング

フィールド	型	デフォルト	説明
notify_window_seconds	int	0	ダンピング用ローリングウィンドウ。0 で無効。
notify_min_fires	int	0	通知送信前にウィンドウ内で発火する最小回数。0 で無効。
notify_channel_ids	int[]	空	特定チャネル ID に通知をピン留め（チャネル自身の enabled / severity / scope フィルターに従う）。空 = グローバルルーター。

末尾の notify_window_seconds 内で notify_min_fires 回未満発火するルールは、タイムラインに repeat_suppressed イベントを書きます（ダンピングが効いたことが分かるように）が、通知 しません。両方ゼロ = ダンピングオフ、すべての発火が cooldown + silence + 抑制ゲートに従って通知。

混合（一方がゼロ、もう一方が >0）は biz レイヤーで invalid_argument: notify_window_seconds and notify_min_fires must both be zero or both > 0 で拒否されます。

インシデントライフサイクル

上のフィールドは ルール（トリガー定義）を記述します。ルールが発火すると以下のステータスを持つ インシデント（alert_incidents テーブル）を生成します：

open ─┬─> acknowledged ─> resolved
      ├─> silenced ─> resolved
      └─> resolved

インシデントは基底条件が 1 完全 evaluator サイクルクリアされると自動解決します。ステートマシンは internal/manager/biz/alert/ に文書化されています。

イベントタイプ

各状態遷移は alert_events 行を記録します。安定イベントタイプ文字列：

イベントタイプ	いつ
firing	ルール初回発火（インシデント作成または再オープン）
repeat_suppressed	cooldown / ダンピングウィンドウ内の発火
acknowledged	ユーザーが Ack をクリック
silenced	ユーザーが N 時間サイレンス
resolved	条件クリアまたはユーザーが Resolve をクリック
reopened	削除前に解決済みインシデントが再発火
note	ユーザー追加コメント
notification_sent	1 チャネル配信成功
notification_failed	1 チャネル配信失敗
inhibited	より高い severity のアクティブインシデントに抑制された
ai_initial_diagnosis	インシデント初回発火時に書かれる、プロアクティブな AI investigator の初回テイク

チャネルタイプ

POST /v1/notification-channels が受け入れるもの：

タイプ	channel_type 値	ソース
Webhook	webhook	env または UI
Slack	slack	env または UI
Larksuite / Feishu	feishu	env または UI
DingTalk	dingtalk	env または UI
WeCom（企业微信）	wecom	UI のみ
Telegram	telegram	UI のみ

レガシー log チャネルタイプは 2026-05 に削除されました —— alert_events 自体が配信監査です。

関連

• REST API —— これらのオブジェクトのエンドポイント。
• 機能 → アラート —— operator 向けツアー。
• チャネル —— チャット画面へのアウトバウンド配信の配線。