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

但是，大家有沒(méi)有遇到這種困惑。我收集了一大堆指標(biāo)，但是我不知道哪些指標(biāo)應(yīng)該告警，也不知道如何把這些告警發(fā)送到對(duì)應(yīng)的團(tuán)隊(duì)或者個(gè)人，更不知道如何做告警升級(jí)。

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

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

今天，我們就來(lái)看看夜鶯到底是怎么玩的。

告警規(guī)則

兵馬未動(dòng)，糧草先行。

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

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

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

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

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

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

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

看到這里，腦海里是否有一點(diǎn)靈感了？

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

假設(shè)我們有前臺(tái)以及中臺(tái)兩個(gè)團(tuán)隊(duì)，就可以把指標(biāo)分別歸類。

默認(rèn)導(dǎo)入進(jìn)來(lái)的規(guī)則原則上是沒(méi)有生效的，需要做一些額外配置。

點(diǎn)開(kāi)告警規(guī)則名稱，進(jìn)入配置頁(yè)面。

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

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

接下來(lái)就是額外的配置了，如下：

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

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

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

看到這里，有沒(méi)有對(duì)普通的告警規(guī)則管理有一定的認(rèn)識(shí)了？

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

屏蔽告警

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

那在什么情況下會(huì)屏蔽告警呢？

比如我們?cè)谧鰬?yīng)用發(fā)版的時(shí)候，難免會(huì)遇到問(wèn)題，這時(shí)候可以提前做一些屏蔽規(guī)則，以免產(chǎn)生告警信息。

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

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

有的同學(xué)可能要說(shuō)了，這樣一個(gè)一個(gè)添加，是不是稍顯麻煩？

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

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

除此之外呢？

想屏蔽啥，就自己加吧！

告警升級(jí)

如果一個(gè)告警在一段時(shí)間內(nèi)還沒(méi)進(jìn)行處理，怎么辦？

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

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

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

比如，我們配置如下：

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

這里的規(guī)則也可以按業(yè)務(wù)團(tuán)隊(duì)來(lái)進(jìn)行分類管理。

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

告警自愈

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

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

處理一個(gè)告警，一定要先弄清楚背后的真正原因，這樣才能解決問(wèn)題。所以對(duì)于告警自愈，一定要明白你做的這個(gè)自動(dòng)化操作的風(fēng)險(xiǎn)很低并且實(shí)驗(yàn)了很多次。不要存在cd /opt/aaa;rm -rf ./的操作。

在夜鶯中，使用ibex?模板來(lái)實(shí)現(xiàn)告警自愈。目前ibex-server?端需要自己部署，ibex-agent?端已經(jīng)集成到Categraf中去了。

部署 ibex-server

到https://github.com/flashcatcloud/ibex/releases下載二進(jìn)制包，下載下來(lái)過(guò)后里面有以下文件：

# 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

導(dǎo)入數(shù)據(jù)庫(kù)：

mysql -uroot -p <sql/ibex.sql

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

最后啟動(dòng)服務(wù)端：

nohup ./ibex server &> server.log &

配置客戶端

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

測(cè)試自愈

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

保存退出，點(diǎn)擊創(chuàng)建任務(wù)：

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

到這，你以為就好了么？

反正我沒(méi)成功，到這里我不得不吐槽一下這個(gè)模塊：

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

所以，我這里并沒(méi)有成功，前端拋了超時(shí)。

后端沒(méi)有日志。

總結(jié)

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

只是在測(cè)試告警自愈的時(shí)候，我沒(méi)有測(cè)試成功。應(yīng)該是跟我的環(huán)境有關(guān)系：

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

不過(guò)具體的原因沒(méi)有排查出來(lái)，可用的排查信息太少了。