可伸縮的微服務告警系統設計指南

本文由公眾號EAWorld翻譯發表，轉載需註明出處。

作者：Shreyas Srivatsan

譯者：白小白 

原題：Observability at Scale: Building Uber’s Alerting Ecosystem

原文：

Uber的軟體架構由成千上萬的微服務組成，有賴於此，我們的團隊可以快速的自主迭代並支撐公司的全球擴張。這一架構支撐了大量的上層解決方案，如移動應用，內部基礎設施服務，以及擁有複雜配置的產品，相關配置會對產品在一、二線城市的表現產生不同的影響。 

為了保障對業務擴張的支撐，以及維持架構的穩定性，Uber的可見性團隊構建了一個健壯、可擴充套件的指標系統以及告警管道。這一系統可以監測相關服務， 以便在故障發生的第一時間延緩產生的影響並通知相關的工程師。

如圖中所示，uMonitor和Neris利用一個共有的管道來傳送通知並去重。稍後我們會深入瞭解這些系統，並探討如何推動建立更多的緩衝措施，和我們新的告警去重平臺Origami，以及在建立高“訊雜比”的告警系統方面如何應對挑戰。

訊雜比，英文名稱叫做SNR或S/N（SIGNAL-NOISE RATIO)，又稱為訊噪比。是指一個電子裝置或者電子系統中訊號與噪聲的比例。

此外，我們還建立了一個黑盒系統，用於偵測內部系統失敗或者資料中心整體當機所引發的更高一級的系統中斷。後續的文章會有討論。

1.Uber的告警系統

圖表1：在我們的告警體系中，相關服務向M3傳送指標資料，uMonitor會負責檢查M3中的資料併產生基於指標的告警資訊。主機檢測資訊會傳送到Neris併產生聚合和告警資訊。Uber外部可以對基礎設施API進行黑盒測試。

在Uber的體量下，傳統的現成解決方案無法滿足監控和告警的要求。我們採用開源的Nagios，結合Graphite的閾值檢測，以及後端的Carbon指標系統 ，輔以原始碼控制指令碼來解決這個問題。基於對Carbon指標系統伸縮性的考量，我們決定建立一個自有的大規模度量平臺，即M3。為了提升告警系統的可用性，我們自主研發了時序告警系統uMonitor，用於處理M3中儲存的指標資料。對於M3以外儲存的指標資料，我們建立了Neris來進行主機一級的告警檢測。

在uMonitor的開發過程中，靈活性和用例差異性是兩個重要的考慮因素。有些告警資訊是基於標準指標自動生成的，如端點錯誤或者CPU/記憶體佔用率過高等。還有些告警資訊是由某個團隊根據具體的需要所建立的指標生成的。uMonitor作為一個平臺系統，會對這些不同種類的用例所產生的指標進行處理，諸如：

• 告警的易管理性：迭代產生適用於告警資訊的功能和閾值。

• 彈性措施：利用尋呼、郵件和聊天系統傳送通知。支援自動化的緩解措施，如部署和配置變更的回滾等。

• 處理海量資訊：既可以響應小範圍的關鍵事件，又不至於在大範圍的中斷情況下讓工程團隊被報警資訊淹沒。

2.基於指標的告警系統：uMonitor

uMonitor由三個獨立元件組成：一個擁有告警管理API的儲存服務，可以對Cassandra告警和狀態資訊進行打包儲存；一個排程器，負責跟蹤所有的告警資訊，並時刻將報警檢查任務分發到workers；一組workers用來基於告警資訊自定義的指標執行檢查任務。

workers會將告警檢查的狀態資訊儲存在Cassandra儲存中，並透過激進的重試機制來確保相關的通知確實傳送成功。只要告警資訊持續產生，workers會負責進行不時的（通常是每小時1次的）重試告警。目前，uMonitor可以在1秒內使用125,000個告警配置來對140萬筆時序資料的7億個資料節點進行檢查。

圖表2：相關服務向M3傳送指標資料，uMonitor的排程器安排相關的workers進行相關指標檢查，如果檢查結果超過一定閾值，就傳送通知。

一條告警資訊由M3查詢（Graphite 或者M3QL）語句和閾值組成。閾值將決定告警是否觸發。查詢語句從M3返回時序資料，閾值會應用於對應的時序資料。一旦查詢的結果超過了閾值，告警就會觸發。藉助Cassandra儲存的狀態資訊，相關worker會維持一個狀態機，以確保告警觸發的狀態下相關的通知成功傳送，並在告警持續觸發的情況下不時的重發通知，以及在事態緩解的情況下將相關通知標記為解決。

閾值一般分為兩種：靜態閾值和反常閾值。對於一些具備特定的、穩定狀態的指標，或者我們可以構造查詢來透過數值計算返回常量值的指標（如成功/失敗比），通常使用靜態閾值。對於一些週期性的指標，如客戶在某市的行程次數或其他的業務指標，uMonitor使用Argos這個反常監測平臺來生成動態的閾值，以表徵基於歷史資料的反常數值。

3.主機告警元件：Neris

Neris是一個基於主機的內部告警系統，用於解決M3指標系統以外的高精度的海量指標資料。將主機指標系統設定在M3之外，是基於兩個原因。首先，要對每個資料中心的40,000個主機節點每分鐘所產生的150萬條主機指標資料進行檢查，基於主機的機制相對於從中心指標儲存庫查詢來說更加高效，嚴格意義上講，相關指標的提取和儲存是毫無意義的開銷。其次，當前M3的保留策略是，10秒的指標資料會儲存48小時，1分鐘的指標資料會儲存30天，對於主機指標來說，以如此的精度和保留策略儲存相關資料並沒無必要。開源的Nagios是以檢查為單位來編碼和部署的，這意味著基礎設施擴張時，主機指標系統無法自動伸縮，因此我們決定自己開發一個系統來應付需要。

Neris的機制，是在資料中心的每個主機上部署一個代理，並基於單主機每分鐘定時執行告警檢測。隨後，相關的檢查結果會傳送到一個聚合層，聚合層將聚合結果傳送給Origami。Origami負責決定傳送哪些告警資訊，傳送的優先順序將視告警的失敗次數以及潛在告警危急程度而定。基於Origami，Neris可以在每分鐘對我們每一個資料中心的主機集團進行150萬次檢測。

主機上的代理啟動時，Neris從一個名為Object Config的中心配置儲存拉取主機的告警定義資訊。Object Config這一機制廣泛的應用於Uber的底層基礎設施服務。哪些告警會被觸發取決於其角色。例如，執行Cassandra的主機會執行與Cassandra狀態、磁碟使用情況等指標相關的檢查。絕大多數主機級別的檢查由基礎設施平臺團隊負責建立和維護。

圖表3：在Neris的機制中，主機檢查基於資料中心的每個主機進行，並透過Neris聚合器實現聚合，並由Origami傳送告警通知。

4.處理規模資料

我們的告警平臺在處理海量資料方面一直面臨著巨大的挑戰。傳統的解決方案是，透過一條告警查詢返回多條時序資料，並且只有在一定比例的資料超過閾值的時候，才使用簡單的規則來觸發告警通知。uMonitor同樣允許使用者基於告警來設定告警。如果一條告警依賴於更大範疇的告警，則一旦上一級告警觸發的情況下，下級告警將被阻塞。

當查詢結果返回的是既定數量的時序資料，且依賴關係可清晰定義的時候，上述方法可以工作的很好。然而，急速擴張中的Uber需要在數以百計的城市運營多條產品線，數量級的挑戰需要更通用的解決方案。我們使用Origami來處理海量的任務。Neris將Origami作為主要的去重器和通知引擎，從而，uMonitor告警系統有了穩固的通知系統。

對於業務指標來說，Origami對於單城市/單產品/單應用版本的告警是用處巨大的。Origami允許使用者基於城市、產品和應用版本的組合來建立潛在的告警和檢查，並基於聚合策略來觸發告警，來接收某個城市、產品或者應用的通知。在更大範圍的系統中斷的情形下（如多個城市同時發生故障），Origami會傳送累積通知，用以表徵已觸發的告警列表。

在主機告警的場景下，Origami使我們可以基於告警的聚合狀態傳送不同嚴重程度的通知。以Cassandra叢集的磁碟使用率為例，此情形下的Origami通知策略如下：

• 當磁碟利用率超過70%的主機數小於3，則傳送郵件通知。

• 當磁碟利用率超過70%的主機數大於3，則傳送尋呼通知。

• 當磁碟利用率超過90%的主機數大於1，也傳送尋呼通知。

5.告警通知

處理告警系統的伸縮問題，最主要的挑戰來自於如何產生有用的告警通知。對於高優先順序的事件，告警行為一般採用的通知方式是尋呼待命的工程師，而對於一般的告知類事件，是透過郵件或者聊天工具來進行通知。我們關注的重點在於構建一些緩解行為來減輕事件的影響。絕大多數的系統中斷或者其他問題來源於配置變更或者部署問題。有些團隊需要處理非常複雜的緩解行為執行手冊，對此我們支援以webhook的方式傳送POST呼叫，並附加告警資訊完整的上下文資訊，來自動化對執行手冊的落地。此外，在更大範圍的系統問題發生時，利用Origami的去重管道，我們可以阻塞一些細粒度的通知，以免工程團隊被資訊也淹沒。

除了上述的手段以外，我們也致力於讓通知的相關性更高，並且匹配到正確的處理者。最新的成果是，當某個服務發生變更併產生告警時，我們可以定位到配置或部署變更的所有者，並直接通知他們相關事項。並且，透過把Jaeger的追蹤資訊與告警資訊進行結合繫結，我們可以為相關的服務失敗提供更多的上下文資訊。

6.告警管理

上面也講到，之所以花大力氣將uMonitor平臺化，是為了讓不同的團隊可以基於這個平臺，來處理特有的用例場景。對於不同的團隊，尤其對於需要維護專有硬體的團隊，以及需要為公司構建基礎設施平臺的團隊來說，在處理諸如儲存、指標管理、計算解決方案等場景的告警問題時，相關的設定和管理往往是特定的和專業化的。相關的告警設定儲存在團隊自有的Git庫中，並向Object Config進行同步。

從更宏觀的視角，uMonitor有三類告警：
- 針對所有服務來說，CPU、磁碟利用率和RPC狀態這些標準的指標，會自動生成告警資訊。
- 針對特定事件，經由UI產生一次性的告警資訊。
- 在uMonitor之上的一層，告警資訊的生成和管理透過指令碼和外部配置系統完成。

當團隊致力於偵測儘可能細粒度的告警事件的時候，一些初級的告警資訊就會產生爆發式增長。隨著Uber的全球擴張，如此細粒度的告警資訊的重要性隨之下降。對於支撐Uber移動應用的相關服務來說，相關的程式碼變更可以在幾小時內，就覆蓋到一部分城市的某些特定群體。在城市一級對平臺的健康度進行監測，發現問題並避免問題擴散，對我們來說尤其重要。此外，工程團隊和本地的運維團隊所需要管理的配置引數，也因城市而異。例如，某個城市的某條街道的遊行隊伍，或者其他事件導致的交通情況的變化，都會影響Uber騎手的匹配。

很多的團隊已經基於uMonitor構建了告警資訊的發生方案，以處理類似上述的這種場景。已經解決的挑戰包括：
- 迭代和生成多維告警資訊
- 基於特定的業務資訊（如某個國家和城市的節日）排程告警任務，並在uMonitor中儲存相關的配置，以避免產生錯誤的告警資訊
- 當靜態或者反常的閾值失效的時候，可以基於歷史資料，或者基於特定的業務線的潛在指標進行的複雜查詢，來生成新的閾值。

此外，上述的解決方案可以生成儀表盤。相關的資訊與產生的告警資訊同步。

uMonitor還提供了一個強有力的編輯介面，可以展示相關的因果聯絡。UI的編輯和驗證的功能十分重要，因為差異性以及峰值的存在，大部分的指標並不能用於告警。對於如何為告警建立更理想的查詢，可見性團隊會給出一些指導建議。

7.告警查詢

為了允許更加定製化的解決方案，Graphite查詢以及M3QL查詢語言所提供的功能很多，甚至有些過猶不及。下我們舉了一些示例，來展示如何讓查詢返回更多的常量，以使得相關指標更可用於告警：

- 使用一段時間內的移動均線指標，可以平滑掉指標中的峰值
- 在上一點的基礎上，結合採用維持策略，僅當超過閾值的狀況持續了一段時間之後，才傳送告警通知。
- 對於一些遵循升降模型的指標，採用導數函式確保無論是上升或者下降，相關指標不會太突兀。

- 使用比率或者百分比來進行告警，以使得指標不會因絕對值的變化而受到影響。

8.未來計劃

如何讓系統擴充套件的同時具備分鐘級的問題偵測能力，並且僅暴露合適的資訊給到使用者，避免不必要的告警資訊，在這方面的工作我們還只是剛剛起步。為了達成這樣的目標，告警管道的方方面面都進行著大量的工作，包括：更有效的指標收集，擴充套件和提升告警執行基礎設施的效能，構建更有效的UI和介面以處理不同來源資訊的相關性等等。

關於EAWorld：微服務，DevOps，資料治理，移動架構原創技術分享。