一、背景介紹

我們知道 Zabbix 在監(jiān)控界占有不可撼動的地位，功能強(qiáng)大。但是對容器監(jiān)控顯得力不從心。為解決監(jiān)控容器的問題，思必馳引入了 Prometheus 技術(shù).并和 OpsMind 共同研發(fā)了一整套監(jiān)控平臺和分級告警配置引擎系統(tǒng)。

思必馳的監(jiān)控系統(tǒng)的演進(jìn)經(jīng)過如下幾個(gè)階段：

• 人肉堆積階段——采用比較原始的模式，例如系統(tǒng)監(jiān)測采用 Zabbix,網(wǎng)絡(luò)監(jiān)測采用 Cacti 等，八仙過海各顯神通，所有的數(shù)據(jù)都是一個(gè)個(gè)海上孤島。
• 平臺化建設(shè)——當(dāng)意識到以上問題時(shí)，開始了新一代監(jiān)測系統(tǒng)的平臺化建設(shè)，首先是去 ZC,把整個(gè)監(jiān)測系統(tǒng)的技術(shù)棧統(tǒng)一到 Prometheus。
• 監(jiān)測數(shù)據(jù)的分析和統(tǒng)計(jì)——當(dāng)數(shù)據(jù)匯總以后，很多之前割裂的信息達(dá)到空前的整合，可以基于海量的監(jiān)測數(shù)據(jù)進(jìn)行大數(shù)據(jù)分析，例如容量評估等。
• 研發(fā)和運(yùn)維共同合作階段——把研發(fā)和運(yùn)維有機(jī)的結(jié)合在一起，因?yàn)榻y(tǒng)一了技術(shù)棧，而 Prometheus 的技術(shù)特性天生為研發(fā)幫助運(yùn)維改進(jìn)系統(tǒng)可靠性提供的有利的保障，可以用不同開發(fā)語言來進(jìn)行埋點(diǎn)，上報(bào)各種個(gè)性化的監(jiān)測需求。
• 平臺可控性建設(shè)——因?yàn)橛辛藦?qiáng)大監(jiān)測系統(tǒng)，便可以洞悉整個(gè)站點(diǎn)，使 SRE 成為可能。

二、平臺建設(shè)目標(biāo)

建設(shè)新一代監(jiān)控平臺我們需要什么？

多樣化的自主接入

接入的數(shù)據(jù)將不再只局限于基礎(chǔ)監(jiān)測，網(wǎng)絡(luò)監(jiān)測，而且從不同的角度來洞悉整個(gè)系統(tǒng)，那么你就需要方便可靠的監(jiān)測數(shù)據(jù)采集系統(tǒng)。

指標(biāo)的靈活配置

監(jiān)測指標(biāo)海量以后隨之帶來的則是配置問題，不同的監(jiān)測指標(biāo)有不同的度量值，不再是以前簡單的邏輯運(yùn)算，會變得相當(dāng)復(fù)雜。

監(jiān)測指標(biāo)的可視化

把海量的監(jiān)測指標(biāo)有機(jī)的結(jié)合起來，針對某個(gè)系統(tǒng)來進(jìn)行集中的 Dashboard 展示，或者是詳盡的可視化的問題排查。

告警的配置和分級通知

為了避免告警風(fēng)暴，讓最有價(jià)值的告警信息出現(xiàn)并通知到相關(guān)的部門和小組，需要對不同告警對象進(jìn)行分級管理。

平臺的擴(kuò)展能力

原生的 Prometheus 并沒有一個(gè)很好的企業(yè)級解決方案，并且不支持集群化，需要管理和優(yōu)化 Prometheus 進(jìn)行企業(yè)平臺的開發(fā)

通過引入 Prometheus 的企業(yè)級解決方案，輔以二次開發(fā)，以上問題得以跨越。

• 提升 Prometheus 的各項(xiàng)能力。

image

• Agent 采用無侵入方式，不用賣點(diǎn)。

image

• 告警配置自助化和完全下放。

image

三、建設(shè)過程

今天我們主要講一下告警配置引擎。

告警的通知形式

絕大部分公司，可能都沒有考慮系統(tǒng)監(jiān)控告警策略，一旦發(fā)生異常，就發(fā)郵件/短信通知系統(tǒng)負(fù)責(zé)人，這樣可能導(dǎo)致這樣一些問題：

• 同一個(gè)集群的不同實(shí)例出問題，可能會造成重復(fù)告警，浪費(fèi)帶寬資源，升高短信成本；

• 系統(tǒng)負(fù)責(zé)人短時(shí)間內(nèi)手機(jī)被告警短信刷屏，導(dǎo)致產(chǎn)生麻木感；

• 系統(tǒng)負(fù)責(zé)人短時(shí)間內(nèi)手機(jī)，郵箱，釘釘，微信同時(shí)對一個(gè)故障告警，導(dǎo)致產(chǎn)生巨大壓力；

• 員工不重視告警，無法判斷告警的優(yōu)先級，Leader 又不知情，導(dǎo)致事故影響擴(kuò)大；

告警的通知渠道

目前傳統(tǒng)的四種文字告警的方式，其成本，到達(dá)率，實(shí)時(shí)性都不一樣：

短信：成本高，實(shí)時(shí)性好，到達(dá)率高

郵件：成本低，實(shí)時(shí)性差，到達(dá)率高

釘釘/微信：成本低，實(shí)時(shí)性中，到達(dá)率中

為了解決上述問題，針對不同的服務(wù)，在不同的時(shí)間段，不同的員工層級，應(yīng)該設(shè)定不同的告警策略，我們采用了 OpsMind 設(shè)計(jì)的告警配置引擎。他主要解決以下幾個(gè)問題：

1. 告警頻率收斂策略：對同一個(gè)服務(wù)或者接口，應(yīng)該在固定的時(shí)間內(nèi)，只發(fā)送有限的告警，常見的方式是，按照1分鐘1次限制告警次數(shù)，一來降低研發(fā)的緊張感與壓力感，二來節(jié)省計(jì)算成本。
2. 不同時(shí)段區(qū)分告警方式策略：工作日工作時(shí)段在公司時(shí)，通過郵件/釘釘/微信發(fā)送告警能更加節(jié)省成本；半夜或者周末發(fā)生故障時(shí)，通過郵件發(fā)送告警能保證實(shí)時(shí)性；另外可以通過時(shí)間段的設(shè)置屏蔽部分服務(wù)自動重啟時(shí)所帶來的誤告警。
3. 逐層上報(bào)告警策略：每個(gè)模塊都應(yīng)該有負(fù)責(zé)人，原則上告警會發(fā)送給模塊的負(fù)責(zé)人，但如果告警連續(xù)一小時(shí)未恢復(fù)正常，告警會自動發(fā)送給系統(tǒng)負(fù)責(zé)人的直屬 Leader，如果告警連續(xù)一個(gè)小時(shí)未恢復(fù)正常，告警會自動發(fā)送給系統(tǒng)負(fù)責(zé)人的二級 Leader。
4. 黑白跳動策略：當(dāng)系統(tǒng)由正常變?yōu)楫惓＃惓；謴?fù)正常，出現(xiàn)正反的變化時(shí)，都應(yīng)該發(fā)出告警。
5. 告警分級策略：針對不同的告警對象設(shè)置不同的觸發(fā)閾值，并推送對應(yīng)負(fù)責(zé)人。實(shí)現(xiàn)一個(gè)指標(biāo)項(xiàng)的告警規(guī)則在一個(gè)策略里完成配置。
6. 篩查告警策略：通過存儲引擎層面的掃描，篩查已經(jīng)失效的告警策略，并通知負(fù)責(zé)人，做到重要告警不漏報(bào)。

四、總結(jié)

• 統(tǒng)一監(jiān)控平臺，不能一異常就告警，太不人性化，要實(shí)現(xiàn)統(tǒng)一的分級告警策略；

• 不同時(shí)段區(qū)分告警方式策略：工作日/非工作日，白天/夜晚區(qū)分；

• 逐層上報(bào)告警策略：先模塊負(fù)責(zé)人告警，n 分鐘未恢復(fù)升級，m 分鐘未恢復(fù)再升級；

• 黑白跳動策略：當(dāng)系統(tǒng)由正常變?yōu)楫惓＃惓；謴?fù)正常都通報(bào)；

• 告警篩查：自動篩查失效的告警策略，避免漏報(bào)。