為什麼要告警
一個業務系統維護了很長時間了，指不定什麼時候會出現問題。不過有些系統也是依賴微信、支付寶平臺的，大平臺都有自身的監控和告警能力幫忙分析和定位商戶系統問題，但並不是所有場景都能涵蓋到。所以個人負責的業務模組需要制定合理的告警機制，系統發生故障要第一時間知道，而不是被通知。
告警指標
常見的指標有請求量、失敗量、平均耗時等，其他指標可以根據業務自身的特點來提取上報。
告警閾值
告警的目的是出問題了，能夠馬上主動發現問題，簡單的問題甚至可以在被投訴和其他人發現前就能修復了。
如果一個系統上報的指標多了，經常會發生沒有設定告警閾值的情況。
尤其是對於後來新增的監控指標，尤其要注意是否設定監控閾值。
可以針對請求量、失敗量，失敗率，平均耗時，耗時中位數設定合理的閾值，觸發閾值後傳送告警通知。
告警處理
我們要明確告警的目的，告警是為了及時發現問題，然後快速處理並恢復業務系統。告警資訊要明確，不要誤告警。對於簡單且能快速處理的問題，可以允許間斷的傳送告警；而對於相對複雜並且很長時間才能解決的問題，持續的告警就沒有意義，這時需要遮蔽告警，問題修復之後再重新恢復告警機制。因此告警模組的靈活性配置是很重要的，根據業務場景可以配置不同的策略，另外也要支援遮蔽和恢復能力。
告警收斂
複雜的業務系統往往都是多例項部署的，如果每個例項都發生問題然後開始傳送告警資訊，那麼技術人員會收到很多條無意義的資訊，不利於告警資訊分析。這時就要考慮對告警資訊進行收集分析了，保證每個業務場景的告警資訊同一時間內只是傳送一次。及時多例項告警資訊做了收集分析，故障沒有及時處理，告警資訊會持續傳送，這是就要固定週期內傳送告警資訊，甚至可以通過配置進行遮蔽掉。告警一定要在系統故障的時候及時發出來，避免無意義的傳送，否則技術人員會產生牴觸心裡，甚至手機端直接遮蔽。
合理閾值
告警模組要支援不同的業務場景設定不同的告警閾值，如果是一個固定的閾值可能會引入一系列的誤告警。靈活的配置，配置中心的引入是少不了了。設定閾值時，要考慮同一個業務場景不同的時間段是不是需要設定不同的閾值，不同的業務場景需要設定不同的閾值。比如某個特殊業務場景，晚上的請求量比白天的請求量多；比如有的業務場景介面平均響應時間比其他的都長；比如某些業務場景在某個時間段不進行告警分析。
告警設計
成功量和失敗量的統計可以通過記憶體變數（AtomicLong）進行統計，或者使用RxJava提供的window操作符會在時間間隔內快取統計結果，類似於buffer快取一個list集合，區別在於window將這個結果集合封裝成了observable。
使用RxJava可以很方便統計一個視窗內服務的成功量、失敗量、延遲分佈情況。
像常用的中介軟體（redis、kafka、rocketmq、es）相關操作都可以通過切面利用RxJava統計健康和延遲情況，然後彙總到告警模組進行分析並觸發預警。
總結
希望本文章的告警設計思路可以給讀者帶來啟發。一個優秀的告警系統，可以減少人力監控，也是自動化運維的一種手段。對於技術人員來說，自己寫的業務程式碼出現問題一定要自己第一時間知道，而不是被人通知。如果現有的告警能力不能滿足你的要求，一定要從長遠的角度出發，制定告警方案，而不是把大部分精力都放在日誌查詢上。