大規模的可觀察性：構建Uber的預警生態系統

Uber的軟件架構包含數千種微服務，這些微服務使團隊可以快速迭代並支持咱們公司的全球增加。這些微服務支持各類解決方案，例如移動應用程序，內部和基礎結構服務以及產品，以及會影響城市和郊區的這些產品的複雜配置。

爲了維持咱們的增加和架構，Uber的Observability團隊創建了一個強大的，可擴展的指標和警報管道，負責在服務出現問題時當即檢測，緩解並通知工程師。具體來講，咱們構建了兩個數據中心警報系統，分別稱爲uMonitor和Neris，它們流入同一通知和警報管道。 uMonitor是咱們基於指標的警報系統，它針對指標數據庫M3運行檢查，而Neris主要在主機級基礎架構中尋找警報。

Neris和uMonitor都利用公共管道發送通知和重複數據刪除。咱們將深刻研究這些系統，並討論如何採起更多的緩解措施，新的警報重複數據刪除平臺Origami，以及在建立高信噪比警報方面的挑戰。

此外，咱們還開發了黑匣子警報系統，能夠在內部系統出現故障或數據中心徹底中斷的狀況下檢測數據中心外部的高級別中斷。將來的博客文章將討論此設置。

報警系統

在咱們的警報體系結構中，服務將指標發送到M3。 uMonitor檢查M3是否存在基於指標的警報。主機檢查將發送到Neris進行彙總和警報。 Blackbox從Uber外部測試API基礎結構。

在Uber的規模上，監視和警報須要在傳統的現成解決方案以外進行思考。 Uber的警報始於Nagios，使用源代碼控制腳本針對指標發佈Graphite閾值檢查。因爲咱們的Carbon指標集羣存在可擴展性問題，咱們決定構建本身的大型指標平臺M3。爲了提升警報系統的可用性，咱們開發了uMonitor，這是咱們本身開發的基於時間序列指標的警報系統，用於存儲在M3中的指標。對於未存儲在M3中的指標，咱們構建了Neris以執行主機級警報檢查。

uMonitor的構建考慮了靈活性和用例多樣性。某些警報是根據標準指標自動生成的，例如端點錯誤和CPU /內存消耗。其餘警報由各個團隊建立，這些警報與特定於其需求的指標有關。咱們將uMonitor構建爲處理這些不一樣用例的平臺，特別是：

• 輕鬆管理警報：迭代肯定警報的適當功能和閾值
• 靈活的操做：諸如尋呼，電子郵件和聊天之類的通知。支持自動緩解措施，例如回滾部署和配置更改
• 處理高基數：可以在最小範圍內的關鍵問題上發出警報，但不能爲團隊提供大量中斷通知

使用uMonitor處理基於metrics的報警

uMonitor具備三個獨立的組件：具備警報管理API並封裝咱們的Cassandra警報和狀態存儲的存儲服務；以及調度程序，用於跟蹤全部警報，併爲每一個警報每分鐘將警報檢查任務分派給工做人員；以及根據警報定義的基礎指標執行警報檢查的工做人員。

工做人員在Cassandra存儲中維護警報檢查狀態，並確保經過主動重試機制至少發送一次通知。工人還負責每隔一段時間（一般每小時一次）從新發出警報，以繼續發出警報。目前，uMonitor具備125,000個警報配置，每秒可在140萬個時間序列中檢查7億個數據點。

警報定義具備M3查詢（Graphite或M3QL）和閾值，這些閾值肯定警報是否違反閾值。查詢從M3返回一個或多個時間序列，而且將閾值應用於每一個基礎序列。若是查詢違反閾值，則發送警報操做。工做人員在存儲在Cassandra中的狀態的幫助下維護着一個狀態機，該狀態機確保至少在觸發警報後發送通知，在觸發警報時按期從新發送，並在問題緩解後解決。

閾值有兩種類型：靜態閾值和異常閾值。對於具備特定穩態的指標，或者咱們能夠經過計算成功/失敗百分比等值來構造返回一致值的查詢，一般使用靜態閾值。對於諸如每一個城市的旅行計數和其餘業務指標之類的週期性指標，uMonitor利用咱們的異常檢測平臺Argos來生成動態閾值，用於根據歷史數據來表明指標的異常值。

利用Neris處理主機報警

Neris是咱們的基於主機的內部警報系統，旨在爲咱們的M3指標系統中不提供的高分辨率的每一個主機高基數指標。主機指標不在M3中的緣由有兩個。首先，檢查每一個數據中心每40,000個主機每分鐘生成的150萬個主機指標中的每一個指標，在主機上執行效率比在中央指標存儲中查詢要高。這樣，就不須要攝取和存儲指標的開銷。其次，直到最近，M3的保留策略致使10秒鐘的度量標準被存儲48小時，而一分鐘的度量標準被存儲30天，而且不須要使用該保留和解決方案來存儲主機度量標準。因爲Nagios要求爲每張支票編寫和部署代碼，但隨着咱們基礎架構的增加而沒法擴展，所以咱們決定在內部構建一個系統。

Neris的代理可在咱們數據中心的每臺主機上運行，​​並按期（每分鐘）對主機自己執行警報檢查。而後，代理將檢查結果發送到聚合層，聚合層又將聚合結果發送到Origami。Origami負責根據查看失敗警報數量和基礎警報的嚴重性的規則來決定要發送什麼警報。利用Origami，Neris在每一個數據中心的主機主機中每分鐘運行約150萬個檢查。

在每臺主機上啓動代理時，Neris會從名爲Object Config的中央配置存儲中提取主機的警報定義信息，該存儲被Uber的低級基礎架構服務普遍使用。肯定哪些警報將在給定主機上運行取決於其角色。例如，運行Cassandra的主機將進行與Cassandra的狀態，磁盤使用狀況和其餘指標有關的檢查。大多數此類主機級別檢查是由基礎架構平臺團隊建立和維護的。

處理高基數

高基數一直是咱們警報平臺的最大挑戰。傳統上，這是經過使警報查詢返回多個序列並僅在序列的某個百分比以上違反閾值時才觸發警報周圍的簡單規則來處理的。 uMonitor還容許用戶將警報設置爲依賴於其餘警報-跟蹤更大範圍問題的警報取決於更大範圍的警報，而且若是觸發更大範圍的警報，則從屬警報將被抑制。

只要查詢返回有限數量的序列，上述技術就能夠很好地工做，而且能夠輕鬆定義依賴項。可是，隨着Uber愈來愈多地在數百個城市中運營許多不一樣的產品線，基數挑戰已要求一種更通用的解決方案。咱們使用Origami來協助處理高基數。 Neris將Origami用做其主要的重複數據刪除和通知引擎，並啓用了uMonitor警報的合併通知。

對於業務指標，當咱們須要針對每一個城市，每一個產品，每一個應用版本發出警報時，Origami很是有用。 Origami容許用戶爲城市，產品和應用程序版本的組合建立基礎的警報/檢查，並在彙總策略上發出警報，以基於每一個城市/產品/應用程序的版本接收通知。在停電較大的狀況下（例如，當許多城市同時出現問題時），Origami將發送彙總通知，指示觸發的底層警報列表。

在主機警報方案中，Origami使咱們可以基於警報的彙總狀態發送各類嚴重性的通知。咱們來看一個有關Cassandra羣集上磁盤空間使用狀況的示例。在這種狀況下，對此的Origami通知政策可能相似於：

• 若是少於三臺的主機使用了70％的磁盤，則發送電子郵件通知
• 若是三個以上的主機有70％的磁盤使用率，則發送頁面
• 若是一個或多個主機磁盤使用率達到90％，則發送頁面

報警通知

有用的警報通知是擴展警報系統的主要挑戰。警報操做主要從通知開始，例如針對高優先級問題呼叫工程師，以及針對信息性問題使用聊天或電子郵件。如今，咱們的重點已轉向制定緩解措施。大多數事件和中斷都是因爲配置更改或部署而發生的。 uMonitor爲緩解操做提供了一流的支持，這些操做能夠回滾最近的配置更改和部署。對於具備更復雜的緩解運行手冊的團隊，咱們支持webhooks，這些Webhooks可針對具備警報完整上下文的端點進行POST調用，從而能夠運行緩解運行手冊。此外，經過利用Origami中的重複數據刪除管道，咱們能夠在發生較大故障時抑制更精細的粒度通知。

除上述內容外，咱們一直在努力使通知更加相關，並使通知針對合適的我的。最近的工做涉及識別配置/部署變動全部者，並在警報觸發他們已修改的服務時觸發他們。經過結合來自Jaeger的跟蹤信息和警報信息，咱們在圍繞相關服務故障的警報通知中提供更多上下文方面作出了額外的努力。

報警管理

如前所述，咱們一直致力於將uMonitor構建爲其餘團隊能夠針對特定用例創建的平臺。主機警報的設置和管理一般是專門的，主要用於維護本身專用硬件的團隊，以及正在爲公司構建基礎架構平臺（包括存儲，指標和計算解決方案）的團隊。警報是在團隊的單獨git存儲庫中配置的，這些存儲庫已同步到Object Config。

從較高的角度來看，uMonitor具備三類警報：

• 根據全部服務的CPU，磁盤使用率和RPC統計信息的標準指標自動生成警報
• 經過UI建立的一次性警報以檢測特定問題
• 經過uMonitor之上的腳本和外部配置系統建立和管理警報

隨着團隊努力以可能的最佳粒度檢測可警報的問題，咱們在最後一類警報中看到了最大的增加。對這種粒度的需求歸結於Uber的全球增加。支持Uber移動應用程序的服務的代碼更改一般會在幾個小時內推廣到特定的城市羣體。咱們很是重要的一點是，咱們必須在城市一級監視平臺的運行情況，以便在問題普遍傳播以前找出問題所在。此外，每一個城市的工程和本地操做團隊控制的配置參數也不一樣。例如，因爲遊行等正在進行的事件，城市中的騎手接送可能會被阻塞在街道上，或者其餘事件可能會致使交通變化。

許多團隊已經在uMonitor上構建了警報生成解決方案來解決此類用例。這些工具解決的一些挑戰是：

• 遍歷各個維度迭代並生成警報
• 根據特定的業務信息（例如特定國家/城市的假期）肯定警報時間表，並在uMonitor中配置該信息以防止虛假警報
• 若是靜態或當前異常閾值不起做用，請基於過去的數據或對適用於特定業務線的基礎指標的複雜查詢來肯定閾值（更多有關如下警報查詢）

此外，這些解決方案中的許多解決方案都會生成與所生成的警報同步的儀表板。

uMonitor還提供了功能強大的編輯和根本緣由UI。 UI的編輯和實驗方面相當重要，由於因爲變化和峯值，大多數指標沒法按原樣用於警報。可觀察性團隊爲如何建立更適合警報的查詢提供了指導。

報警查詢

Graphite查詢語言和M3QL提供了大量功能，可提供更多定製解決方案。下面，咱們概述了一些示例，這些示例說明了如何使查詢返回更一致的值以使指標更易於警戒：

• 提醒您說幾分鐘內移動指標的平均值，以消除指標的任何峯值
• 將以上內容與維持期結合使用，僅在閾值違例持續了必定時間後才發送通知
• 對於具備上下模式的指標，請使用導數函數以確保任一方向的峯值都不會太忽然
• 發出百分比/比率警報，以使度量標準不易受到度量標準大小變化的影響