在夜鶯新版本中，告警規則直接使用 promql 來配置，閾值就包含在 promql 裡面，所以恢復時是無法拿到當前值的，因為恢復時監控資料不達閾值，不達閾值就不會返回資料，所以也就無法拿到當前值。Prometheus 也是類似的問題，不過可以透過 go template 中的 query 函式曲線救國，但是不夠直觀，學習曲線較高。今天給大家介紹兩種實現思路來解決這個問題。
- 思路一：查詢的 promql 中不包含閾值，只包含過濾條件，直接去查詢原始資料，告警引擎查到原始資料之後做閾值判定，不管是否觸發閾值，都可以拿到當前值。
- 思路二：查詢的 promql 中包含閾值，恢復時拿著相關標籤去做二次查詢，這樣也可以拿到當前值。這種方式和 go template 中的 query 函式類似，相對會直觀一些。
下面我以 Flashduty 產品為例，截圖說明具體配置方式。
Flashduty 是一個告警事件中心，其產品介紹地址：https://flashcat.cloud/product/flashduty/ 。核心提供兩個能力：1）告警事件中心，可以把夜鶯、Zabbix、Prometheus、雲監控等各類監控系統的告警匯聚在一個地方，做統一的告警收斂、聚合降噪、排班、認領、升級、派發、協作；2）Flashduty 也直接提供告警引擎的能力，可以對接 VictoriaMetrics、M3DB、Prometheus、ClickHouse、MySQL、Oracle、Postgres 等資料來源，直接查詢資料來源的資料做告警判定，不需要額外的監控系統，告警事件的產生和分發，Flashduty 一肩挑。
方案一
以 Memcached 的某個告警規則舉例，查詢條件裡不寫閾值，判定規則裡寫閾值，如下圖所示：
這種方式需要先查到當前值，再拿著當前值去做判定，所以不管是告警時還是恢復時，都可以拿到當前值。這種方式非常直觀，大部分場景都適用。對於一個查詢條件過濾到很多時序的場景，這種方式會查到特別多的資料，對告警引擎也是個壓力。可以嘗試方案二。
方案二
在 Flashduty 中，方案二稱為「資料存在」的告警方式，這種方式只要查到資料就告警。需要在查詢條件的 promql 中寫閾值，比如：
cpu_usage_active{ident=~"dev-n9e.*", cpu="cpu-total"} > 85具體頁面配置如下：
這種設定方式就和 Nightingale、Prometheus 的做法一樣了，自然會面臨一樣的問題，無法在告警判定時拿到閾值。針對這種寫法，Flashduty 提供了一種方法，透過配置關聯查詢語句曲線救國拿到觸發時的值，還是以 cpu_usage_active 這個指標為例，可以配置這樣的關聯查詢以及備註描述：
其中關聯查詢的名字設定為 X（當然，你可以設定為其他名字），關聯查詢的語句也是一個 promql，用於精確查詢具體的值，這裡的 promql 可以引用標籤變數，比如上例中的 ident="${ident}"，${ident} 就表示告警事件中的 ident 標籤。之後在備註描述中寫 if else 語句，針對告警、恢復兩種情況分別寫不同的獲取值的方式。
關聯查詢其實非常靈活，不止是用於獲取恢復時的值。比如 A 指標告警的時候想順帶看到 B 指標的值，或者日誌告警 Error 數量觸發閾值時看到日誌詳情，都可以使用關聯查詢來做到。
Flashduty 的告警引擎功能當前是公測階段，歡迎免費體驗，註冊地址：
https://console.flashcat.cloud/
歡迎加我好友，交流可觀測性相關話題或瞭解我們的商業產品，我的微訊號：picobyte，加好友請備註您的公司、姓名、來意 🤝
擴充套件閱讀：
- 方法論：面向故障處理的可觀測性體系建設
- 小總結：從CTO視角來看：如何搭建運維/SRE能力
- 鄙人專欄：運維監控系統實戰筆記