系統(tǒng)監(jiān)控告警，是架構(gòu)設(shè)計中必不可少的一部分?？珊芏喙?，由于告警太多，工程師完全忽視告警消息，最終導(dǎo)致告警失效。為什么會這樣？根本原因，是分級告警策略的缺失。

啥是告警？

監(jiān)控平臺發(fā)現(xiàn)系統(tǒng)異常，向系統(tǒng)負(fù)責(zé)人發(fā)出文字（例如，郵件/短信），色彩（有些公司，編譯不過，CI平臺會亮紅燈），聲音（有些公司，有蜂鳴器嗡嗡響，研發(fā)壓力大呀）等警示，就是告警。

絕大部分公司，主要是通過文字發(fā)出系統(tǒng)異常告警信息。

文字告警有哪些常見的方法？

常見有三類，成本，到達(dá)率，實時性都不一樣：

• 短信：成本高，實時性好，到達(dá)率高；
• 郵件：成本低，實時性差，到達(dá)率高；
• 釘釘/微信：成本低，實時性中，到達(dá)率中；

啥是告警策略？

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

• 同一個集群的不同實例出問題，可能會造成重復(fù)告警，浪費帶寬資源，升高短信成本；
• 系統(tǒng)負(fù)責(zé)人短時間內(nèi)手機被告警短信刷屏，導(dǎo)致產(chǎn)生麻木感；
• 系統(tǒng)負(fù)責(zé)人短時間內(nèi)手機，郵箱，釘釘，微信同時對一個故障告警，導(dǎo)致員工產(chǎn)生巨大壓力；
• 員工不重視告警，無法判斷告警的優(yōu)先級，leader又不知情，導(dǎo)致事故影響擴大；

為了解決上述問題，針對不同的服務(wù)，在不同的時間段，不同的員工層級，應(yīng)該設(shè)定不同的告警策略，有哪些常見的告警策略呢？

(1) 模塊告警收斂策略：當(dāng)一個模塊/服務(wù)異常時，與其對應(yīng)的所有接口監(jiān)控，與其對應(yīng)集群的多有實例，都會告警，此時，應(yīng)該收斂為一個模塊/服務(wù)告警，常見的實現(xiàn)方式是，模塊/服務(wù)按照集群名稱做告警去重；

(2) 接口告警收斂策略：當(dāng)一個模塊/服務(wù)的一個接口異常，與其對應(yīng)集群的多個實例，都會告警，此時，應(yīng)該收斂為一個接口告警，常見的實現(xiàn)方式是，按照接口名稱做告警去重；

(3) 告警頻率收斂策略：對同一個服務(wù)或者接口，應(yīng)該在固定的時間內(nèi)，只發(fā)送有限的告警，常見的方式是，按照1分鐘1次限制告警次數(shù)，一來降低研發(fā)的緊張感與壓力感，二來節(jié)省成本；

(4) 不同時段區(qū)分告警方式策略：工作日工作時段在公司時，通過郵件/釘釘/微信發(fā)送告警能更加節(jié)省成本；半夜或者周末發(fā)生故障時，通過郵件發(fā)送告警能保證實時性；

(5) 逐層上報告警策略：每個模塊都應(yīng)該有負(fù)責(zé)人，原則上告警會發(fā)送給模塊的負(fù)責(zé)人，但如果告警連續(xù)1小時未恢復(fù)正常，告警會自動發(fā)送給系統(tǒng)負(fù)責(zé)人的直屬leader，如果告警連續(xù)3個小時未恢復(fù)正常，告警會自動發(fā)送給系統(tǒng)負(fù)責(zé)人的二級leader；

(6) 黑白跳動策略：當(dāng)系統(tǒng)由正常變?yōu)楫惓?，異?；謴?fù)正常，出現(xiàn)正反的變化時，都應(yīng)該發(fā)出告警；

畫外音：額，這么人性化，是“別人家”的公司么？

知其然，知其所以然。 思路比結(jié)論更重要。