夜鶯 v9 活躍告警頁面，集中查看目前未恢復的告警事件、按業務組/級別/資料來源過濾、認領抑制刪除處置，以及通過聚合規則歸類大批次告警。
概述
活躍告警 = 目前仍在告警狀態、還沒恢復的事件集合。
側欄路徑：告警 → 告警事件 → 活躍告警 Tab，URL /alert-cur-events。同一頁面頂部有 活躍告警 / 歷史告警 兩個 Tab：
- 活躍告警：狀態 =
Triggered且未恢復的事件，告警一旦恢復就從這裡消失，轉到歷史告警。 - 歷史告警：所有產生過的告警事件（含已恢復的），用於事後回溯。
適用場景：
- 值班同學第一時間看「現在到底有哪些故障在燒」
- 大批次告警時按業務組/級別/資料來源快速收斂
- 標籤維度做聚合（比如按業務組、按主機 ident），看故障「成片爆發」的全貌
- 處置流程：查看詳情 → 認領 →（必要時）抑制相關派生告警 → 通知協作
活躍告警只展示尚未恢復的事件。如果某條規則的告警恢復了，它就不在這個列表裡；想看歷史得切到 歷史告警 Tab。
列表頁
頂部過濾欄
- 我的業務組 / 全部業務組：單選切換；「我的業務組」只顯示目前帳號所屬的業務組事件。
- 業務組下拉：在選定範圍內進一步選某一個具體業務組。
- 模糊搜尋：在事件規則名 + 標籤中搜，多個關鍵字用空格分隔（與邏輯）。比如輸入
disk dev-doris-001會同時匹配規則名含 disk 且標籤含 dev-doris-001 的事件。雙擊列表裡的標籤也會把這個標籤作為關鍵字加入搜尋。 - 自動重新整理：右上
Off / 5s / 15s / 30s / 1min / 5min，值班大屏建議開 30s。 - 時間範圍：預設不限（顯示所有未恢復事件，包括幾十天前就在燒的「老炮」）。可以設最近 1 小時之類來只看新爆發的。
左側過濾面板
| 分類 | 選項 | 說明 |
|---|---|---|
| 監控類型 | Metric / Host / Log | 即告警規則的 prod 欄位；指標類、主機類、日誌類 |
| 告警級別 | S1 (Critical) / S2 (Warning) / S3 (Info) | 多選 |
| 資料來源 | 目前實例所有啟用的資料來源 | 多選，支援搜尋 |
列表欄位
| 列 | 含義 |
|---|---|
| 事件 | 第一行：資料來源類型 logo + 資料來源名 + 規則名（點選開啟詳情抽屜）；第二行：事件標籤的視覺化展示 |
| 觸發時間 | 本次告警狀態最近一次被檢測到的時間 |
| 持續時長 | 從「首次觸發」到現在的時長，配有 12 格彩條 — 越靠右、顏色越紅表示持續越久（0-8h 綠、8-16h 黃、16-24h+ 紅） |
| 認領人 | 未認領 / 顯示認領人；點選「認領」按鈕自己接單 |
| 操作 | 行末三點選單：抑制 / 刪除 / 認領 / 取消認領 |
列表底部支援翻頁和「30/50/100 條/頁」切換。
聚合規則：把上百條告警折成幾張卡片
當活躍告警 > 50 條時，平鋪式列表很難看出「哪一類問題最多」。聚合規則 用 Go Template 對事件做歸類，把同一類事件折疊成一張卡片顯示在表格上方。
如上圖，選擇「By RuleName」後，24 條事件被歸為 11 個聚合結果：tes1 下 5 條、主機失聯告警 下 4 條……點選任一卡片，下方表格只顯示該卡片對應的事件。
常用聚合運算式（在「新增規則」裡填）：
| 場景 | 範本 |
|---|---|
| 按業務組 + 級別 | Group:{{.GroupName}} Severity:{{.Severity}} |
| 按規則名 | {{.RuleName}} |
| 按主機 ident | {{.TagsMap.instance}} 或 {{.TagsMap.ident}} |
| 按服務標籤 | {{.TagsMap.service}} |
可用欄位（常用）：.GroupName（業務組）、.RuleName（規則名）、.Severity（級別數字）、.TagsMap.<key>（任意標籤值）。
不熟悉 Go Template 也可以用「新增規則」按鈕裡給的幾個內建範例，選中後再改改。
批次操作
勾選列表行後會在列表上方出現批次操作按鈕：
- 批次刪除（OSS + PLUS）
- 批次認領 / 批次取消認領（PLUS 獨有）
適合「一次性把同一規則下的幾十條派生事件全部認領」或「把徹底無效的殭屍事件一次性清掉」。
詳情抽屜
點選事件標題（藍色連結）會從右側滑出告警詳情抽屜：
詳情欄位
| 欄位 | 說明 |
|---|---|
| 趨勢圖 | 頂部曲線，顯示告警指標在觸發前後一段時間的實際取值；紅色虛線 = 觸發時刻；右上可調時間範圍與 Step |
| 規則標題 | 點選跳轉到對應告警規則編輯頁 /alert-rules/edit/:id |
| Hash | 事件唯一指紋（基於規則 + 標籤生成），用於排查重複告警時直接複製比對 |
| 業務組 | 事件所屬業務組 |
| 規則備註 | 告警規則在建立時填的備註（「為什麼這條規則在告警」） |
| 資料來源 | 觸發該事件的資料來源實例名 |
| 告警級別 | S1 / S2 / S3 |
| 事件狀態 | Triggered（活躍）或 Recovered（恢復，僅歷史告警可見） |
| 事件標籤 | 觸發時刻該資料點附帶的全部標籤 key=value |
| 首次觸發時間 / 本次檢測時間 | 第一次進入告警狀態的時間 vs 最近一次確認仍在告警的時間 |
| 觸發時值 | 觸發瞬間的指標數值 |
| PromQL（或對應資料來源的查詢語句） | 告警規則用到的查詢語句，旁邊的 ▶️ 按鈕可直接在資料來源裡執行複算 |
| 執行頻率 / 持續時長 | 規則的查詢週期；觸發前要滿足條件的持續時長 |
| 通知規則 / 通知記錄 | 命中的通知規則；「查看詳情」可以看到這條事件被推送到了哪些媒介、是否成功 |
處置按鈕
抽屜底部 4 個操作按鈕：
- 抑制：用目前事件的標籤預填抑制規則表單，跳轉到
/alert-mutes/add，常用來快速壓制成片爆發的派生告警（比如某台機器當機引發的 N 條派生事件）。 - 刪除：物理刪除目前事件。
⚠️ 只有在確定該指標永遠不會再上報（標籤調整 / 機器下線）時才刪 — 這種事件不會自動恢復，留著也是噪音。其餘情況讓它自然恢復即可。
- 認領（PLUS）：把事件掛到自己名下，列表的「認領人」列會顯示目前使用者。值班場景用於「我接手了，別人不用重複處理」。
- 生成分享連結：產生一個免登入可存取的事件詳情連結（帶 token，預設 7 天有效），發到 IM 群裡給協作方查看；連結是只讀快照，看到的是產生時刻的事件狀態。
常見問題
Q1：為什麼列表裡的告警明明已經恢復了，還是顯示在活躍告警裡？
A：活躍告警基於告警引擎判定是否恢復而非「採集資料是否還在異常」。兩種最常見的原因：
- 指標已經停止上報（機器關機 / 標籤被改）：告警引擎查詢不到資料，沒法判定「恢復」，會停在 Triggered 狀態。這種情況手工 刪除事件 即可，或者新增主機失聯告警規則覆蓋該場景。
- 規則設定了「通知恢復」但沒設定恢復條件：檢查告警規則的「恢復閾值」和「持續時長」，確保資料回正常後能在指定時長內被判定為恢復。
Q2：「認領」和「抑制」有什麼區別？
A：
- 認領：標記「我在處理這條告警」，不會阻止任何後續動作 — 事件繼續在列表裡，通知規則也繼續推送（如果規則設定了重複通知）。主要是協作訊號：讓其他值班同學知道有人接手了。
- 抑制：基於標籤的事件過濾，命中抑制規則的事件不會再產生告警通知，也不在告警事件列表裡。用於「已知問題、暫時不要再吵」。
詳見 抑制規則 文件。
Q3：刪除事件之後，告警規則會重新產生這條事件嗎？
A：會。刪除只是把目前事件記錄清掉，告警規則本身沒被停用，下次查詢週期到了如果條件還滿足，會重新產生一條新的活躍告警事件（Hash 可能相同）。
所以別用刪除當「抑制」：要長期止吵，去 抑制規則 或者直接停用告警規則。
Q4：列表的「持續時長」顯示一週、一個月甚至幾年，這正常嗎？
A：通常是被遺忘的「殭屍告警」，由以下情況造成：
- 資料來源被刪除或停用，事件再也無法收到「恢復」訊號；
- 標籤 schema 變更後老事件無法被新規則覆蓋；
- 早期測試規則未清理。
定期清理思路：用左側的「資料來源」篩選過濾、按時間倒序排，把超過合理 SLA 的事件批次刪除。
