第十七篇：穩定性之告警體系

告警與可觀測性有這密不可分的關系，告警是先于使用者發現問題的手段之一，如果沒有告警系統，隻能通過人工進行定期檢查，即便是能夠發現問題也不能立馬定位到問題出現的原因，而且成本和效率也非常低下。

告警用途

告警用途主要有兩個方面，首先是通過監控資料，能夠做到先于使用者發現問題。告警系統通過對監控資料名額量化，監控資料變化，一旦發現問題之後，可以快速報給相應的工程師，快速處理問題，這樣能夠提升解決問題的效率，進而提升使用者體驗，而不用等着使用者過來回報問題，其次是能夠通過聚合相關名額快速定位問題，結合可觀測中的Log、Metrics、Tracing三大支柱，能夠讓相應的工程師快速定位問題産生的根本原因，而不是像無頭蒼蠅一樣在海量的資料中翻找。

快速感覺

快速感覺業務問題是展現告警的及時性和監控資料全面性，結合黑白監控兩部分資料做告警，如通過黑盒監控對服務端口存活監控，看端口是否存活，白盒監控資料名額更多是通過Log、Metrics、Tracing三者相結合來發現問題，如對服務的核心關鍵名額Metrics監控，能夠看出業務流量趨勢、錯誤率、響應時間、P95、P99耗時情況，通過Tracing分析調用鍊的耗時情況，分析能夠看到分段耗時，可以在通過Log去具體定位問題。

告警政策

告警政策是告警中比較重要的一環，首先告警政策配置項要能夠清楚結合業務場景和業務屬性配置适合告警的政策，而不是盲目的；其次是告警品質，告警那麼就是必須要處理的，而不是告警了，研發工程師忽略或者覺得沒事，告警頻率要是适度，選擇合适的，而不是過多的告警導緻告警泛濫，進而告警無效，或者告警過少發現不了問題，沒有及時響應。

政策配置

政策配置項，可以參考如下：

• 告警名額量化：如果告警名額不能量化的話，那麼是無法告警的，例如HTTP狀态碼 200、404，也可以自定義業務Code碼
• 告警類型：硬體類、軟體類針對不同的名額配置
• 告警級别：問題嚴重度按照P0-P4 （也是5個級别）
• 告警過濾：可以針對不同區間、包含等一系列規則将不需要的資料進行過濾，防止告警無效，如在配置監控可以将Http 狀态碼等于302 進行過濾掉。
• 告警規則：可以是包含、小于等于大于、字元串比對等
• 告警頻率：可以是基于時間視窗、其它自定義，如一分鐘出現多少次，則進行告警或出現就報警等
• 告警收斂：防止大規模的告警，導緻告警泛濫，如告警規則、機關時間内、出現多少次等
• 告警更新：如告警多久未處理則進行告警更新，上報到負責人等
• 通知形式：如釘釘群可@相應的主、備研發工程師；郵箱或者微信群等等

在政策配置時，可以參考如下，來確定告警任務合理性：

• 該規則是否能檢測到目前檢測不到的情況？該情況是否非常緊急、是否能通過人工介入解 決、是否嚴重或立即影響使用者？
• 能否判斷這個告警的嚴重程度？能否忽略這個告警？什麼情況下可以忽略？如何避免産生這種告警?
• 這個告警是否表明使用者正在受到影響？
• 收到告警後是否要執行某個操作？立即執行還是可以等到第二天早上再執行？該操作是否能安全地自動化？該操作的效果是長期的還是短期的？
• 是否其他人也會收到相關的告警，這樣是否必要?

告警品質

我們如何保證告警品質，首先是簡化告警，針對門檻值選擇采用保守政策，逐漸視情況配置門檻值，其次是告警的時效性，要確定告警的時效不能，問題出現很久了，才報警，這樣不符合告警系統的預期，再次是告警收斂，防止告警泛濫，可以适合進行告警合并，将問題在告警表現出來，再次告警類型、級别，針對不同類型的告警類型，告警優先級，進行分類，便于區分重要程度，及告警更新等處理，最後是告警任務可操作，告警任務是可随時配置，如開啟、暫停、關閉等，便于随時可控制，防止該告警任務出現不可控行為。

告警原則

• 收到緊急告警時應立即采取行動。但每天隻能應付幾次緊急告警，多了之後就麻木了。
• 每個緊急告警都應該是能處理的（actionable）。
• 處理緊急告警需要動腦。如果某個緊急告警隻需要一套固定的機械動作，那它就不應該被列為緊急告警。
• 緊急告警應彼此獨立，互無重疊。

告警處理

告警治理