監控是方法，告警是手段，解決是目的。

但是，大家有沒有遇到這種困惑。我收集了一大堆指標，但是我不知道哪些指標應該告警，也不知道如何把這些告警發送到對應的團隊或者個人，更不知道如何做告警升級。

我之前用 Prometheus+Altermanager 這一套的時候，為每個團隊弄一個釘釘群，然后打了一堆的標簽，匹配不同的標簽發送到不同的群，如果要做告警升級的話，很多時候都是通過閾值升級來完成，但是同一個告警通過時間來升級就不好辦。

但是夜鶯在做告警規則管理就沒那么復雜（復雜的事情他們給你做了），而且還很優雅。我在??《【夜鶯監控】初識夜鶯，還是強！》??提到過：Grafana 更擅長監控面板的管理，N9e 更擅長告警規則的管理。

今天，我們就來看看夜鶯到底是怎么玩的。

告警規則

兵馬未動，糧草先行。

要告警，得先知道我們的需求是什么，也就是要弄明白哪些指標需要告警。

比如說，在系統層面，我們要考慮 CPU、內存、磁盤、IO 等指標；在應用層面，我們要考慮應用的飽和度、失敗率以及延遲等；在業務層面，我們要考慮這次的交易失敗次數、哪里失敗等。

站在不同的層面，考慮的監控指標以及告警策略會不一樣。

夜鶯的告警規則分為內置規則和自定義規則。

內置規則旨在降低大家的使用門檻，為大家提供一套普適性的規則。主要有以下內容：

內置的告警規則不會生效，除非你把它拉到你的規則里。如果你看中了某個規則，就可以把它克隆到生效規則中。比如，我把 Linux TIME_WAIT 告警規則克隆到默認業務組中。

然后到告警規則總覽里就能看到默認業務組中新增了一條告警規則。

看到這里，腦海里是否有一點靈感了？

我們可以根據實際情況創建多個業務組，然后是否就可以把涉及到多個業務組的告警規則進行分開管理了？

假設我們有前臺以及中臺兩個團隊，就可以把指標分別歸類。

默認導入進來的規則原則上是沒有生效的，需要做一些額外配置。

點開告警規則名稱，進入配置頁面。

我們可以自定義告警條件、數據源、告警等級等配置。如上我們配置的信息歸納如下：

• 告警的數據源是 local_prometheus，這表示你的告警來自哪個集群。
• 告警條件是當 TIME_WAIT 總數大于 20000 才會觸發告警。
• 告警等級是二級，也就是一般重要等級。
• 執行頻率是每 15 秒執行一次，連續持續 60s 依然滿足告警規則，則會觸發告警

接下來就是額外的配置了，如下：

生效配置用來配置該告警規則在什么時間段，什么業務組生效。而通知配置則是配置通知媒介，也就是如果產生了告警，應該通過哪些渠道發到哪些地方。

不過，在通知配置處還可以做額外的配置：

• 啟動恢復通知，也就是如果告警恢復了，也會通過這個渠道告知負責人。
• 告警接收組，也就是業務組。
• 留觀時長，當告警恢復后，觀察多長時間才給業務組發恢復通知?？梢砸幈苣男┎▌有缘母婢粫l告警，一會發恢復等問題。
• 重復通知，也就是在這個時間段里，如果還未解決告警，就會再發送一次。當然，這里還不涉及告警升級。

看到這里，有沒有對普通的告警規則管理有一定的認識了？

除了克隆內置的告警規則，我們還可以自定義告警規則，不過整體上的配置和上面是一樣的。

屏蔽告警

一般被屏蔽的告警都不是很重要的告警。

那在什么情況下會屏蔽告警呢？

比如我們在做應用發版的時候，難免會遇到問題，這時候可以提前做一些屏蔽規則，以免產生告警信息。

屏蔽規則也是按業務組分的，我們可以新增一條規則，如下創建一條屏蔽消息中心告警的規則。

這樣在固定的時間窗口內，告警信息不再發送。

有的同學可能要說了，這樣一個一個添加，是不是稍顯麻煩？

如果是已經產生的活躍告警，可以一鍵屏蔽。

如果是歷史告警，也可以一鍵屏蔽。

除此之外呢？

想屏蔽啥，就自己加吧！

告警升級

如果一個告警在一段時間內還沒進行處理，怎么辦？

要么不是重要的告警——把規則刪了吧，留之無用。

要么是解決不了的告警——升級吧，讓更多人知道。

在夜鶯中，在訂閱規則中可以實現告警升級。

比如，我們配置如下：

如果 server=notice 的告警事件在 1 小時內還未解決，我們將告警等級升級為一級，并且將告警信息發送到更高級別的群里。

這里的規則也可以按業務團隊來進行分類管理。

除此之外還提供活躍告警和歷史告警，可以查看當前有哪些告警信息，以及歷史的告警記錄。

告警自愈

從事運維越久，其實會發現很多事情的處理都是重復性的，一些簡單重復的工作可以通過自動化腳本來進行處理，不僅能提升工作效率，也能在一定程度上降低人為操作的風險。

夜鶯提供了告警自愈功能。功能雖好，可不好貪杯哦。

處理一個告警，一定要先弄清楚背后的真正原因，這樣才能解決問題。所以對于告警自愈，一定要明白你做的這個自動化操作的風險很低并且實驗了很多次。不要存在cd /opt/aaa;rm -rf ./的操作。

在夜鶯中，使用ibex?模板來實現告警自愈。目前ibex-server?端需要自己部署，ibex-agent?端已經集成到Categraf中去了。

部署 ibex-server

到https://github.com/flashcatcloud/ibex/releases下載二進制包，下載下來過后里面有以下文件：

# ll
total 21536
drwxr-xr-x 3 root root     4096 Apr 19 10:44 etc
-rwxr-xr-x 1 root root 16105472 Nov 15  2021 ibex
-rw------- 1 root root  5931963 Jun  3  2022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root     4096 Nov 15  2021 sql

導入數據庫：

mysql -uroot -p <sql/ibex.sql

然后修改/etc/server.conf配置文件，主要修改數據庫的配置。

最后啟動服務端：

nohup ./ibex server &> server.log &

配置客戶端

在系統配置?->通知配置?->告警自愈模塊配置對應的服務端地址：

測試自愈

然后到告警自愈?->自愈腳本處添加腳本，如下：

保存退出，點擊創建任務：

如果里面的配置不需要修改或者修改對應的配置后，選擇立即執行：

到這，你以為就好了么？

反正我沒成功，到這里我不得不吐槽一下這個模塊：

• ibex-server 的部署有沒有前置條件？
• ibex-agent（categraf）有沒有前置條件？
• 自愈腳本執行失敗，不論是客戶端還是服務端都沒有具體的失敗日志
• N9e V6 版本的告警自愈配置入口怎么放到消息通知模塊？怪怪的
• 官方文檔這個模塊有點過于簡單

所以，我這里并沒有成功，前端拋了超時。

后端沒有日志。

總結

目前夜鶯能夠比較齊全的實現告警規則的管理，告警渠道分發以及告警消息抑制以及升級，而且 FlashDuty 可以接入不同的集群告警，在大部分企業中以及夠用了。

只是在測試告警自愈的時候，我沒有測試成功。應該是跟我的環境有關系：

• N9e 整體模塊是使用的 Helm 部署到 K8s 中的
• ibex-server 端卻是以二進制的形式直接部署在主機上的

不過具體的原因沒有排查出來，可用的排查信息太少了。