簡析Uber的可伸縮監控：uMonitor和Neris

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架構

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以便於跨多個源關聯資料。

檢視英文原文：

https://www.infoq.com/news/2018/12/observability-uber