監(jiān)控是方法，告警是手段，解決是目的。

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

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

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

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

告警規(guī)則

兵馬未動，糧草先行。

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

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

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

夜鶯的告警規(guī)則分為內(nèi)置規(guī)則和自定義規(guī)則。

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

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

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

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

我們可以根據(jù)實際情況創(chuàng)建多個業(yè)務組，然后是否就可以把涉及到多個業(yè)務組的告警規(guī)則進行分開管理了？

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

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

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

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

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

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

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

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

• 啟動恢復通知，也就是如果告警恢復了，也會通過這個渠道告知負責人。
• 告警接收組，也就是業(yè)務組。
• 留觀時長，當告警恢復后，觀察多長時間才給業(yè)務組發(fā)恢復通知?？梢砸?guī)避哪些波動性的告警，一會發(fā)告警，一會發(fā)恢復等問題。
• 重復通知，也就是在這個時間段里，如果還未解決告警，就會再發(fā)送一次。當然，這里還不涉及告警升級。

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

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

屏蔽告警

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

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

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

屏蔽規(guī)則也是按業(yè)務組分的，我們可以新增一條規(guī)則，如下創(chuàng)建一條屏蔽消息中心告警的規(guī)則。

這樣在固定的時間窗口內(nèi)，告警信息不再發(fā)送。

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

如果是已經(jīng)產(chǎn)生的活躍告警，可以一鍵屏蔽。

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

除此之外呢？

想屏蔽啥，就自己加吧！

告警升級

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

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

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

在夜鶯中，在訂閱規(guī)則中可以實現(xiàn)告警升級。

比如，我們配置如下：

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

這里的規(guī)則也可以按業(yè)務團隊來進行分類管理。

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

告警自愈

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

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

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

在夜鶯中，使用ibex?模板來實現(xiàn)告警自愈。目前ibex-server?端需要自己部署，ibex-agent?端已經(jīng)集成到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

導入數(shù)據(jù)庫：

mysql -uroot -p <sql/ibex.sql

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

最后啟動服務端：

nohup ./ibex server &> server.log &

配置客戶端

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

測試自愈

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

保存退出，點擊創(chuàng)建任務：

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

到這，你以為就好了么？

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

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

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

后端沒有日志。

總結(jié)

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

只是在測試告警自愈的時候，我沒有測試成功。應該是跟我的環(huán)境有關(guān)系：

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

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