【夜鶯監控】告警管理，香！

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

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

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

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

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

警告規則

兵馬未動，糧草先行。

要告警，得先知道我們的需求是什麼，也就是要弄清楚哪些指標需要告警。

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

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

夜鶯的警告規則分為內建規則和自訂規則。

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

內建的警告規則不會生效，除非你把它拉到你的規則裡。如果你看中了某個規則，就可以把它複製到生效規則中。例如，我把 Linux TIME_WAIT 警告規則複製到預設業務群組中。

然後到警告規則總覽裡就能看到預設業務群組中新增了一條警告規則。

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

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

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

預設導入進來的規則原則上是沒有生效的，需要做一些額外設定。

點開告警規則名稱，進入設定頁面。

我們可以自訂警告條件、資料來源、警告等級等配置。如上我們配置的資訊歸納如下：

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

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

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

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

• 啟動恢復通知，也就是如果警告恢復了，也會透過這個管道告知負責人。
• 警告接收群組，也就是業務群組。
• 留觀時長，當警告恢復後，觀察多久才給業務組發恢復通知。可以規避哪些波動性的告警，一會發告警，一會發恢復等問題。
• 重複通知，也就是在這個時段裡，如果還未解決告警，就會再發送一次。當然，這裡還不涉及告警升級。

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

除了複製內建的警告規則，我們還可以自訂警告規則，不過整體上的配置和上面是一樣的。

屏蔽警告

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

那在什麼情況下會封鎖警報呢？

例如我們在做應用程式發版的時候，難免會遇到問題，這時候可以事先做一些屏蔽規則，以免產生警告訊息。

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

這樣在固定的時間視窗內，警告訊息就不再發送。

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

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

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

除此之外呢？

想屏蔽啥，就自己加吧！

警告升級

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

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

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

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

例如，我們配置如下：

如果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 152021 ibex
-rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz
drwxr-xr-x 2 root root 4096 Nov 152021 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 端卻是以二進位的形式直接部署在主機上的

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

以上是【夜鶯監控】告警管理，香！的詳細內容。更多資訊請關注PHP中文網其他相關文章！