監(jiān)控是方法，告警是手段，解決是目的。
但是，大家有沒有遇到這種困惑。我收集了一大堆指標(biāo)，但是我不知道哪些指標(biāo)應(yīng)該告警，也不知道如何把這些告警發(fā)送到對應(yīng)的團隊或者個人，更不知道如何做告警升級。
我之前用 prometheus+Altermanager 這一套的時候，為每個團隊弄一個釘釘群，然后打了一堆的標(biāo)簽，匹配不同的標(biāo)簽發(fā)送到不同的群，如果要做告警升級的話，很多時候都是通過閾值升級來完成，但是同一個告警通過時間來升級就不好辦。
但是夜鶯在做告警規(guī)則管理就沒那么復(fù)雜（復(fù)雜的事情他們給你做了），而且還很優(yōu)雅。我在??《【夜鶯監(jiān)控】初識夜鶯，還是強！》??提到過：Grafana 更擅長監(jiān)控面板的管理，N9e 更擅長告警規(guī)則的管理。
今天，我們就來看看夜鶯到底是怎么玩的。
告警規(guī)則
兵馬未動，糧草先行。
要告警，得先知道我們的需求是什么，也就是要弄明白哪些指標(biāo)需要告警。
比如說，在系統(tǒng)層面，我們要考慮 CPU、內(nèi)存、磁盤、IO 等指標(biāo)；在應(yīng)用層面，我們要考慮應(yīng)用的飽和度、失敗率以及延遲等；在業(yè)務(wù)層面，我們要考慮這次的交易失敗次數(shù)、哪里失敗等。
站在不同的層面，考慮的監(jiān)控指標(biāo)以及告警策略會不一樣。
夜鶯的告警規(guī)則分為內(nèi)置規(guī)則和自定義規(guī)則。
內(nèi)置規(guī)則旨在降低大家的使用門檻，為大家提供一套普適性的規(guī)則。主要有以下內(nèi)容：
內(nèi)置的告警規(guī)則不會生效，除非你把它拉到你的規(guī)則里。如果你看中了某個規(guī)則，就可以把它克隆到生效規(guī)則中。比如，我把 Linux TIME_WAIT 告警規(guī)則克隆到默認(rèn)業(yè)務(wù)組中。
然后到告警規(guī)則總覽里就能看到默認(rèn)業(yè)務(wù)組中新增了一條告警規(guī)則。
看到這里，腦海里是否有一點靈感了？
我們可以根據(jù)實際情況創(chuàng)建多個業(yè)務(wù)組，然后是否就可以把涉及到多個業(yè)務(wù)組的告警規(guī)則進行分開管理了？
假設(shè)我們有前臺以及中臺兩個團隊，就可以把指標(biāo)分別歸類。
默認(rèn)導(dǎo)入進來的規(guī)則原則上是沒有生效的，需要做一些額外配置。
點開告警規(guī)則名稱，進入配置頁面。
我們可以自定義告警條件、數(shù)據(jù)源、告警等級等配置。如上我們配置的信息歸納如下：
- 告警的數(shù)據(jù)源是 local_prometheus，這表示你的告警來自哪個集群。
- 告警條件是當(dāng) TIME_WAIT 總數(shù)大于 20000 才會觸發(fā)告警。
- 告警等級是二級，也就是一般重要等級。
- 執(zhí)行頻率是每 15 秒執(zhí)行一次，連續(xù)持續(xù) 60s 依然滿足告警規(guī)則，則會觸發(fā)告警
接下來就是額外的配置了，如下：
生效配置用來配置該告警規(guī)則在什么時間段，什么業(yè)務(wù)組生效。而通知配置則是配置通知媒介，也就是如果產(chǎn)生了告警，應(yīng)該通過哪些渠道發(fā)到哪些地方。
不過，在通知配置處還可以做額外的配置：
- 啟動恢復(fù)通知，也就是如果告警恢復(fù)了，也會通過這個渠道告知負(fù)責(zé)人。
- 告警接收組，也就是業(yè)務(wù)組。
- 留觀時長，當(dāng)告警恢復(fù)后，觀察多長時間才給業(yè)務(wù)組發(fā)恢復(fù)通知。可以規(guī)避哪些波動性的告警，一會發(fā)告警，一會發(fā)恢復(fù)等問題。
- 重復(fù)通知，也就是在這個時間段里，如果還未解決告警，就會再發(fā)送一次。當(dāng)然，這里還不涉及告警升級。
看到這里，有沒有對普通的告警規(guī)則管理有一定的認(rèn)識了？
除了克隆內(nèi)置的告警規(guī)則，我們還可以自定義告警規(guī)則，不過整體上的配置和上面是一樣的。
屏蔽告警
一般被屏蔽的告警都不是很重要的告警。
那在什么情況下會屏蔽告警呢？
比如我們在做應(yīng)用發(fā)版的時候，難免會遇到問題，這時候可以提前做一些屏蔽規(guī)則，以免產(chǎn)生告警信息。
屏蔽規(guī)則也是按業(yè)務(wù)組分的，我們可以新增一條規(guī)則，如下創(chuàng)建一條屏蔽消息中心告警的規(guī)則。
這樣在固定的時間窗口內(nèi)，告警信息不再發(fā)送。
有的同學(xué)可能要說了，這樣一個一個添加，是不是稍顯麻煩？
如果是已經(jīng)產(chǎn)生的活躍告警，可以一鍵屏蔽。
如果是歷史告警，也可以一鍵屏蔽。
除此之外呢？
想屏蔽啥，就自己加吧！
告警升級
如果一個告警在一段時間內(nèi)還沒進行處理，怎么辦？
要么不是重要的告警——把規(guī)則刪了吧，留之無用。
要么是解決不了的告警——升級吧，讓更多人知道。
在夜鶯中，在訂閱規(guī)則中可以實現(xiàn)告警升級。
比如，我們配置如下：
如果 server=notice 的告警事件在 1 小時內(nèi)還未解決，我們將告警等級升級為一級，并且將告警信息發(fā)送到更高級別的群里。
這里的規(guī)則也可以按業(yè)務(wù)團隊來進行分類管理。
除此之外還提供活躍告警和歷史告警，可以查看當(dāng)前有哪些告警信息，以及歷史的告警記錄。
告警自愈
從事運維越久，其實會發(fā)現(xiàn)很多事情的處理都是重復(fù)性的，一些簡單重復(fù)的工作可以通過自動化腳本來進行處理，不僅能提升工作效率，也能在一定程度上降低人為操作的風(fēng)險。
夜鶯提供了告警自愈功能。功能雖好，可不好貪杯哦。
處理一個告警，一定要先弄清楚背后的真正原因，這樣才能解決問題。所以對于告警自愈，一定要明白你做的這個自動化操作的風(fēng)險很低并且實驗了很多次。不要存在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 152021 ibex -rw------- 1 root root5931963 Jun32022 ibex-1.0.0.tar.gz drwxr-xr-x 2 root root 4096 Nov 152021 sql
導(dǎo)入數(shù)據(jù)庫：
mysql -uroot -p <sql><p>然后修改/etc/server.conf配置文件，主要修改數(shù)據(jù)庫的配置。</p> <p>最后啟動服務(wù)端：</p> <p></p> <pre class="brush:plain;toolbar:false;">nohup ./ibex server &> server.log &
配置客戶端
在系統(tǒng)配置?->通知配置?->告警自愈模塊配置對應(yīng)的服務(wù)端地址：
測試自愈
然后到告警自愈?->自愈腳本處添加腳本，如下：
保存退出，點擊創(chuàng)建任務(wù)：
如果里面的配置不需要修改或者修改對應(yīng)的配置后，選擇立即執(zhí)行：
到這，你以為就好了么？
反正我沒成功，到這里我不得不吐槽一下這個模塊：
- ibex-server 的部署有沒有前置條件？
- ibex-agent（categraf）有沒有前置條件？
- 自愈腳本執(zhí)行失敗，不論是客戶端還是服務(wù)端都沒有具體的失敗日志
- N9e V6 版本的告警自愈配置入口怎么放到消息通知模塊？怪怪的
- 官方文檔這個模塊有點過于簡單
所以，我這里并沒有成功，前端拋了超時。
后端沒有日志。
總結(jié)
目前夜鶯能夠比較齊全的實現(xiàn)告警規(guī)則的管理，告警渠道分發(fā)以及告警消息抑制以及升級，而且 FlashDuty 可以接入不同的集群告警，在大部分企業(yè)中以及夠用了。
只是在測試告警自愈的時候，我沒有測試成功。應(yīng)該是跟我的環(huán)境有關(guān)系：
- N9e 整體模塊是使用的 Helm 部署到 K8s 中的
- ibex-server 端卻是以二進制的形式直接部署在主機上的
不過具體的原因沒有排查出來，可用的排查信息太少了。
