John Corrigan在他的文章中對分布式系統的指標和警報進行了提綱挈領的分析。
分布式系統的指標和警報允許運維人員檢測分布式系統的故障，并幫助他們快速診斷出錯位置。
指標
指標是按特定時間間隔收集的系統信息；指標存儲后可以進一步處理，例如進行可視化或觸發警報等。
作者認為，指標可以分為3類：輸入指標、輸出指標和過程指標。
輸入指標對系統的入口進行度量，例如，用戶請求數、請求的某個特征（資源/項目/產品）的數量，以及請求的來源、數據包大小等。 輸出指標對系統的輸出進行度量，例如，成功訂單數、不成功訂單數、大家關心的用戶請求響應時間等。好的輸出指標可以近似為每分鐘系統賺取的利潤。過程指標對系統內部操作進行度量，例如平均負載、可用內存、可用磁盤空間、可用inode數等，也可以對某個程序進行度量，例如某個API的重試次數等。作者指出，有時指標間沒有明確的界限：以HTTP代碼為例，2xx和5xx代碼是輸出指標，4xx一般是輸入指標，但是如果錯誤是對之前請求的數據進行操作后造成的，也可以當做輸出指標。3xx的類別完全取決于應用程序。在多個模塊、組件、服務等組成的大型系統中，每個模塊都可以有自己的3種指標。
作者認為，各個指標的用途不同：輸出指標代表問題是否存在以及確定問題的嚴重程度；輸入指標可以指出問題的位置是本系統還是上游系統；一旦確定故障點，可以通過過程指標深入了解問題。
作者強調，所有的指標都應該定期匯總，而且應當可以快速反映問題。好的指標在運行正常時不會出現波動，在出現問題時應反應靈敏。
警報
如果出現故障，系統應該報警：某個指標出現了異常的變化。
作者對警報進行了分級：
SEV 1：故障如果不及時處理會嚴重影響業務連續性，造成大量利潤損失或者違反法律法規 SEV 2：故障會影響業務，例如訂單成功率下降10%，客戶響應慢了10倍，導致部分員工不能工作等 SEV 3：故障導致系統出現嚴重問題，例如服務器嚴重過載，部分請求出現錯誤，但是不影響業務，輸出看起來比較正常 SEV 4：故障導致了一些異常但不嚴重作者認為，對警報相對應的反應是：
SEV 1：呼叫整個團隊，立即組織人馬處理，開始公關，迅速debug，申請大量資金。這種情況下最好不需要大量人手處理 SEV 2：呼叫有權限和經驗的相關人員，將debug作為最高優先事項 SEV 3：在Slack上記錄或開工單，盡快解決問題 SEV 4：除非資源足夠否則不干預，更多關注的是導致這種事件的數量、頻率等指標：這些深層次問題可以成為SEV 3事件總結
作者總結道，整個系統需要至少一個輸出指標，最好是每分鐘賺取利潤的近似值：例如，每分鐘投放的廣告、每分鐘的頁面展示數、每分鐘的流量、每小時上傳的圖片等。在響應中包含用時也是好辦法。
作者對數據的理解是：對于匯總指標，例如某些值的總和或平均值以及客戶請求的平均延遲，應該生成數個指標。記得要記錄指標包含的數據點數量，也可以考慮包括分位數（p0、p25、p50、p75、p90、p99和p100等）。有時，眾數和中位數也有用。如果輸入值呈正態分布，指標應包括標準差。
作者指出，對于SEV 1和SEV 2事件應當提供可預見的警報：
指標干凈，不會被隨機噪聲淹沒。在更長的時間內進行平均處理有可能可以降低噪聲，也可以動態修改平均值； 影響顯著，不能由噪音引起； 必須人為干預才能恢復，對于短時間自動恢復的問題不需要呼叫人員； 和故障強相關的時序指標，例如，MySQL的歷史列表不斷加長在幾個小時后幾乎一定會演變為故障。指標與故障的相關性必須極強，以免造成告警疲勞。在SEV 2 的情況下，如果故障概率是50%而工程師在睡覺，那么可以等到故障發生時再進行呼叫。作者提醒，如果某臺主機出現負載、CPU占用、磁盤空間、內存空間等指標報警，考慮是否出現架構弱點：不要為此設置警報，在此之前就把冗余和災備做好。
查看英文原文：Operational Metrics and Alerts for Distributed Software Systems
京公網安備 11010502049343號