Uber的基礎設施由數千個移動應用微服務、基礎設施和內部服務組成。爲了獲得這些服務的高可觀察性，Uber的Observability團隊構建了兩個內部監控解決方案：uMonitor（用於基於時間序列指標的警報和Neris（用於主機級別的檢查和指標）。這兩個系統都使用了通用管道來修改數據和去重。
Observability團隊高級軟件工程師Shreyas Srivatsan說，Uber的業務規模擴展很快就超過了他們初始監控和警報平臺的應對能力。最開始，他們採用了Nagios，並使用腳本對Carbon指標進行閾值檢查。但是，Nagios需要爲每個度量指標編寫和部署代碼，隨着團隊和產品的增長，這些種方式無法進行很好的擴展。大約在同一時間，他們的Carbon集羣也遇到了可擴展性問題。於是，Observability團隊決定構建自己的度量數據庫M3。
爲了處理M3中的指標，該團隊構建了uMonitor，這是一個基於時間序列指標的警報系統。在發佈時，uMonitor有125,000個警報配置，每秒檢查140多萬個時間序列的7億個數據點。uMonitor中的警報配置包含了一個查詢（Graphite或M3QL）和一個閾值。查詢從M3返回一個或多個時間序列，並將閾值應用於每個時間序列上。如果查詢違反了閾值，就會觸發警報。
uMonitor由三個獨立的組件組成：提供了警報管理API的存儲服務、調度程序和工作程序。存儲服務對Cassandra數據庫進行了包裝，用於存儲警報定義和警報的狀態機。調度程序負責跟蹤警報，並以分鐘爲間隔調度警報檢查。工作程序針對底層指標執行警報檢查，同時將狀態保存到Cassandra中，以確保它們不會過度警報。
uMonitor會自動生成標準指標，如端點錯誤或CPU/內存消耗。其他警報可以由每個團隊手動創建。目前，uMonitor支持兩種類型的警報閾值：靜態和異常。靜態閾值對於穩定狀態度量標準非常有用，例如總是返回一致值的查詢。異常閾值由Uber的異常檢測平臺Argos提供支持。這個系統基於歷史數據生成動態閾值。
Uber維護着第二個系統Neris，用於跟蹤不存在M3指標系統中的主機指標。Srivatsan說，他們發現在一個集中式數據庫中存儲“數據中心40,000臺主機每分鐘產生的150萬個主機指標”非常低效，所以他們選擇直接查詢主機。Neris在每臺主機上運行一個代理，對該主機執行警報檢查。在啓動時，代理從Uber的中央配置存儲（稱爲Object Config）中獲取配置。配置將決定主機的角色，主機負責設置適當的檢查。代理將這些檢查的結果發送到聚合層，然後聚合層將數據發送到Origami。Origami負責根據一系列規則來決定應該發送哪些警報，並對警報進行去重。
Srivatsan表示，“基數太高一直是我們警報平臺面臨的最大挑戰”。正如Aaron Sun所寫的，“監控系統環境中的基數是指存儲在時序數據庫中唯一的指標時序的數量”。最初，Uber通過讓警報查詢返回多個時序並且只有在足夠的時序超過閾值時才觸發警報來解決高基數問題。這種情況適用於返回有限數量的時序查詢。但是，當團隊需要針對每個城市、每個產品和每個應用程序版本查詢警報時，就不再適合使用這種方式了。
該團隊開始使用Origami來解決這些更復雜的問題。如上所述，Origami能夠進行數據去重和警報彙總。它還能夠針對城市、產品和應用程序版本的組合創建警報，然後基於彙總策略觸發警報。這些警報定義存儲在各個團隊的git存儲庫中，然後同步到Object Config。
隨着平臺的發展，警報已經從簡單地通知輪班待命的工程師演變成可以自動觸發回滾和其他緩解活動。uMonitor爲回滾提供了完全支持，也可以POST到路由以觸發更復雜的緩解策略。進一步的路線圖改進包括更有效的度量收集、簡化警報執行基礎設施，以及創建UI以便於跨多個源關聯數據。
查看英文原文：