夜鶯 v8 版本的事件處理器 Processor 介紹，包含 Relabel、Callback、Event Update、Event Drop、AI Summary 等處理器的使用方法。
事件處理器（Event Processor）是夜鶯 v8 版本引入的一個概念，當告警事件產生之後，在發送通知之前，可以使用事件處理器對告警事件做額外的處理，開源版本支援 Relabel、Callback、Event Update、Event Drop、AI Summary 5 類處理器，不同的處理器可以組成一個 Pipeline，對告警事件做一系列靈活的處理。場景比如：
- 跟內部的 CMDB 打通，附加一些更豐富的資訊到告警事件上
- 呼叫 DeepSeek 的介面，對告警事件做一些智慧分析，然後把分析結果附加到告警事件上
- 把所有告警事件發送到自己的系統，相當於映像一份，做後續的分析處理
- 一些特定的告警事件可以 Drop 掉，比如一些恢復事件不想發送通知
這裡涉及多個概念，通知規則、事件處理器（Processor）、事件處理管道（Pipeline），稍作解釋：
- 一個通知規則裡可以設定多個事件處理管道（Pipeline），順序執行
- 一個事件處理管道（Pipeline）裡可以設定多個事件處理器（Processor），也是順序執行
上面的截圖可以看出，入口選單在 通知-通知規則，通知規則可能會有很多，在新增或編輯某個具體的通知規則時，可以看到有個 事件處理 的設定區域，這裡可以引用多個提前建立好的事件管道（Pipeline），那在哪裡對事件管道（Pipeline）增刪改呢？入口比較隱藏，在 事件處理 右側那個小齒輪裡，點擊可以展開一個側拉板，在側拉板裡對事件管道（Pipeline）增刪改。
建立、編輯事件管道（Pipeline）時，又會展開一個新的側拉板，在這個新側拉板裡編輯 Pipeline，我們可以在 Pipeline 裡設定多個事件處理器（Processor）：
點擊事件處理器類型欄位旁邊的 使用說明 可以查看事件處理器的使用說明文件。
Relabel 處理器
Relabel 處理器，類似 Prometheus 中對監控指標的 Relabel 操作，只不過夜鶯這裡，是對告警事件的 Relabel，告警事件裡也有標籤欄位，也有需求對標籤做一些加工處理，所以這裡提供了 Relabel 處理器。
Relabel 處理器的具體使用說明，在夜鶯的頁面上點擊事件處理器類型欄位旁邊的 使用說明，即可查看。
Callback 處理器
事件觸發後，夜鶯可以透過 Callback 通知外部系統，外部系統可以根據事件內容進行自動化處理。比如我見過有些公司自研了一套告警通知的系統，不用夜鶯的通知機制，就直接把所有告警事件透過 Callback 處理器發送到自研的系統。
下面做一個簡單的演示：
- 首先建立一個「通知規則」，因為 Callback 處理器屬於某個 Pipeline，而 Pipeline 又屬於某個通知規則。
- 在「通知規則」裡，引用事件處理的 Pipeline，Pipeline 需要提前建立好（在通知規則編輯頁面，點擊處理器右側的小齒輪開啟側拉板，在側拉板裡建立、編輯 Pipeline），下面截圖是一個 Pipeline 的詳情頁面，裡邊有一個 Callback 處理器。
這裡的
http://10.99.1.107:8888/print是我的一個測試程式，可以把接收到的 HTTP 請求列印出來，方便演示。這個程式也是一個開源小程式，位址在 github gohttpd。
建立了 Pipeline 之後，回到通知規則頁面，在事件處理那裡，選擇剛才建立的 Pipeline。
接下來，就可以去設定「告警規則」做測試了，測試一下產生的告警能否被第三方程式接收到。
為了盡快看到效果，可以建立一個肯定會觸發閾值的告警規則，然後在通知規則那裡，選擇剛才建立的通知規則：
稍等片刻，去觀察 http://10.99.1.107:8888/print 這個程式是否收到回呼的 HTTP 請求。我的環境裡看到的結果如下：
從上圖可以看出，HTTP request 中包含了告警事件的資訊，其內容如下：
{
"id": 1097371,
"cate": "prometheus",
"cluster": "prom",
"datasource_id": 1,
"group_id": 2,
"group_name": "DBA-Postgres",
"hash": "54f5543591c6dc0e30139cae196a1eee",
"rule_id": 54,
"rule_name": "测试事件回调",
"rule_note": "",
"rule_prod": "metric",
"rule_algo": "",
"severity": 2,
"prom_for_duration": 0,
"prom_ql": "cpu_usage_active{ident=\"ulric-flashcat.local\"} > 0",
"rule_config": {
"queries": [{
"from": 0,
"prom_ql": "cpu_usage_active{ident=\"ulric-flashcat.local\"} > 0",
"range": {
"display": "now-undefineds to now-undefineds",
"end": "now-undefineds",
"start": "now-undefineds"
},
"severity": 2,
"to": 0,
"unit": "none"
}]
},
"prom_eval_interval": 15,
"callbacks": [],
"runbook_url": "",
"notify_recovered": 1,
"target_ident": "ulric-flashcat.local",
"target_note": "",
"trigger_time": 1749180264,
"trigger_value": "33.06867",
"trigger_values": "",
"trigger_values_json": {
"values_with_unit": {
"v": {
"value": 33.06867479671808,
"unit": "",
"text": "33.07",
"stat": 33.06867479671808
}
}
},
"tags": ["__name__=cpu_usage_active", "cpu=cpu-total", "ident=ulric-flashcat.local", "rulename=测试事件回调"],
"tags_map": {
"__name__": "cpu_usage_active",
"cpu": "cpu-total",
"ident": "ulric-flashcat.local",
"rulename": "测试事件回调"
},
"original_tags": ["", "", "", ""],
"annotations": {},
"is_recovered": false,
"last_eval_time": 1749180264,
"last_sent_time": 1749180264,
"notify_cur_number": 1,
"first_trigger_time": 1749180264,
"extra_config": {
"enrich_queries": []
},
"status": 0,
"claimant": "",
"sub_rule_id": 0,
"extra_info": null,
"target": null,
"recover_config": {
"judge_type": 0,
"recover_exp": ""
},
"rule_hash": "dc128d86d65326499bd03ecfbe56e4c3",
"extra_info_map": null,
"notify_rule_ids": [3],
"notify_version": 0,
"notify_rules": null
}
測試正常。如果您有類似需求，就可以使用這種 Callback 處理器來對接，在您的程式中做一些自動化的邏輯。
Event Update 處理器
事件處理器中，還有一個 Event Update 處理器，和 Callback 的設定方式一樣，這倆工作邏輯也很像，區別如下：
夜鶯在呼叫 Callback 位址的時候，是不關注 HTTP Response 的，而在呼叫 Event Update 的時候，會把 HTTP Response 的內容作為新的告警事件走後續處理。
所以，Event Update 如其名，就是用來修改告警事件的。通常用於附加一些額外資訊到告警事件中，比如：
- 把事件交給 AI 分析，得到一些結論性質的資訊，附加到事件中
- 去 CMDB 查詢一些元資訊，附加到事件中
注意，告警事件的結構不能亂改，比如直接在 JSON 頂層增加一個欄位，後續流程是不認的。通常建議把新內容附加到 annotations 欄位，我上面 Callback 處理器的例子中，annotations 是空的所以看不出來資料結構，實際 annotations 是一個 map 結構，map key 和 map value 都是字串類型，你要附加內容的時候，也需要遵循這個結構。
進階玩家也可以修改 Event 的其他欄位，但是你得清楚你的修改對後續的影響，普通使用者就只需要把內容附加到
annotations欄位，然後把整個新的 Event 序列化為 JSON 放到 HTTP Response 的 body 中即可。
Event Drop 處理器
事件處理器中，還有一個 Event Drop 處理器，顧名思義，就是用來丟棄告警事件的。比如：
- 有些場景，雖然產生了告警事件，但是不想走後面的通知邏輯，就可以使用 Event Drop 處理器來丟棄這個事件。
要 Drop 掉一些告警事件，那肯定要做過濾，通常可以利用標籤、註解、級別等各種欄位做過濾，這個過濾規則可能會寫的很複雜，那這個功能怎麼設計才能如此靈活呢？我們想了一個稍微複雜但是極度靈活的辦法，就是使用者直接使用 go template 語法設定一段 template，template 中可以引用告警事件，使用 if 等語法來做過濾。只要這個 go template 最終渲染的結果是 true，就會丟棄這個事件。
具體使用說明，在夜鶯的頁面上點擊 Event Drop 事件處理器類型欄位旁邊的 使用說明，即可查看。
AI Summary 處理器
AI Summary 處理器的文件也很齊全，如下圖：
點擊 AI Summary 事件處理器類型欄位旁邊的 使用說明，即可查看 AI Summary 處理器的使用說明文件。下面各個欄位右側都有一個小問號的 icon，滑鼠挪上去也可以看到相關提示說明。
