這篇文章主要介紹“如何構建Uber的預警生態(tài)系統(tǒng)”，在日常操作中，相信很多人在如何構建Uber的預警生態(tài)系統(tǒng)問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何構建Uber的預警生態(tài)系統(tǒng)”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
創(chuàng)新互聯(lián)建站服務項目包括喀左網(wǎng)站建設、喀左網(wǎng)站制作、喀左網(wǎng)頁制作以及喀左網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，喀左網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到喀左省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
Uber的軟件架構包含數(shù)千種微服務，這些微服務使團隊能夠快速迭代并支持我們公司的全球增長。這些微服務支持各種解決方案，例如移動應用程序，內(nèi)部和基礎結構服務以及產(chǎn)品，以及會影響城市和郊區(qū)的這些產(chǎn)品的復雜配置。
為了維持我們的增長和架構，Uber的Observability團隊建立了一個強大的，可擴展的指標和警報管道，負責在服務出現(xiàn)問題時立即檢測，緩解并通知工程師。具體來說，我們構建了兩個數(shù)據(jù)中心警報系統(tǒng)，分別稱為uMonitor和Neris，它們流入同一通知和警報管道。uMonitor是我們基于指標的警報系統(tǒng)，它針對指標數(shù)據(jù)庫M3運行檢查，而Neris主要在主機級基礎架構中尋找警報。
Neris和uMonitor都利用公共管道發(fā)送通知和重復數(shù)據(jù)刪除。我們將深入研究這些系統(tǒng)，并討論如何采取更多的緩解措施，新的警報重復數(shù)據(jù)刪除平臺Origami，以及在創(chuàng)建高信噪比警報方面的挑戰(zhàn)。
此外，我們還開發(fā)了黑匣子警報系統(tǒng)，可以在內(nèi)部系統(tǒng)出現(xiàn)故障或數(shù)據(jù)中心完全中斷的情況下檢測數(shù)據(jù)中心外部的高級別中斷。未來的博客文章將討論此設置。
在我們的警報體系結構中，服務將指標發(fā)送到M3。uMonitor檢查M3是否存在基于指標的警報。主機檢查將發(fā)送到Neris進行匯總和警報。Blackbox從Uber外部測試API基礎結構。
在Uber的規(guī)模上，監(jiān)視和警報需要在傳統(tǒng)的現(xiàn)成解決方案之外進行思考。Uber的警報始于Nagios，使用源代碼控制腳本針對指標發(fā)布Graphite閾值檢查。由于我們的Carbon指標集群存在可擴展性問題，我們決定構建自己的大型指標平臺M3。為了提高警報系統(tǒng)的可用性，我們開發(fā)了uMonitor，這是我們自己開發(fā)的基于時間序列指標的警報系統(tǒng)，用于存儲在M3中的指標。對于未存儲在M3中的指標，我們構建了Neris以執(zhí)行主機級警報檢查。
uMonitor的構建考慮了靈活性和用例多樣性。某些警報是根據(jù)標準指標自動生成的，例如端點錯誤和CPU /內(nèi)存消耗。其他警報由各個團隊創(chuàng)建，這些警報與特定于其需求的指標有關。我們將uMonitor構建為處理這些不同用例的平臺，特別是：
輕松管理警報：迭代確定警報的適當功能和閾值
靈活的操作：諸如尋呼，電子郵件和聊天之類的通知。支持自動緩解措施，例如回滾部署和配置更改
處理高基數(shù)：能夠在最小范圍內(nèi)的關鍵問題上發(fā)出警報，但不能為團隊提供大量中斷通知
uMonitor具有三個獨立的組件：具有警報管理API并封裝我們的Cassandra警報和狀態(tài)存儲的存儲服務；以及調(diào)度程序，用于跟蹤所有警報，并為每個警報每分鐘將警報檢查任務分派給工作人員；以及根據(jù)警報定義的基礎指標執(zhí)行警報檢查的工作人員。
工作人員在Cassandra存儲中維護警報檢查狀態(tài)，并確保通過主動重試機制至少發(fā)送一次通知。工人還負責每隔一段時間（通常每小時一次）重新發(fā)出警報，以繼續(xù)發(fā)出警報。目前，uMonitor具有125,000個警報配置，每秒可在140萬個時間序列中檢查7億個數(shù)據(jù)點。
警報定義具有M3查詢（Graphite或M3QL）和閾值，這些閾值確定警報是否違反閾值。查詢從M3返回一個或多個時間序列，并且將閾值應用于每個基礎序列。如果查詢違反閾值，則發(fā)送警報操作。工作人員在存儲在Cassandra中的狀態(tài)的幫助下維護著一個狀態(tài)機，該狀態(tài)機確保至少在觸發(fā)警報后發(fā)送通知，在觸發(fā)警報時定期重新發(fā)送，并在問題緩解后解決。
閾值有兩種類型：靜態(tài)閾值和異常閾值。對于具有特定穩(wěn)態(tài)的指標，或者我們可以通過計算成功/失敗百分比等值來構造返回一致值的查詢，通常使用靜態(tài)閾值。對于諸如每個城市的旅行計數(shù)和其他業(yè)務指標之類的周期性指標，uMonitor利用我們的異常檢測平臺Argos來生成動態(tài)閾值，用于根據(jù)歷史數(shù)據(jù)來代表指標的異常值。
Neris是我們的基于主機的內(nèi)部警報系統(tǒng)，旨在為我們的M3指標系統(tǒng)中不提供的高分辨率的每個主機高基數(shù)指標。主機指標不在M3中的原因有兩個。首先，檢查每個數(shù)據(jù)中心每40,000個主機每分鐘生成的150萬個主機指標中的每個指標，在主機上執(zhí)行效率比在中央指標存儲中查詢要高。這樣，就不需要攝取和存儲指標的開銷。其次，直到最近，M3的保留策略導致10秒鐘的度量標準被存儲48小時，而一分鐘的度量標準被存儲30天，并且不需要使用該保留和解決方案來存儲主機度量標準。由于Nagios要求為每張支票編寫和部署代碼，但隨著我們基礎架構的增長而無法擴展，因此我們決定在內(nèi)部構建一個系統(tǒng)。
Neris的代理可在我們數(shù)據(jù)中心的每臺主機上運行，并定期（每分鐘）對主機本身執(zhí)行警報檢查。然后，代理將檢查結果發(fā)送到聚合層，聚合層又將聚合結果發(fā)送到Origami。Origami負責根據(jù)查看失敗警報數(shù)量和基礎警報的嚴重性的規(guī)則來決定要發(fā)送什么警報。利用Origami，Neris在每個數(shù)據(jù)中心的主機主機中每分鐘運行約150萬個檢查。
在每臺主機上啟動代理時，Neris會從名為Object Config的中央配置存儲中提取主機的警報定義信息，該存儲被Uber的低級基礎架構服務廣泛使用。確定哪些警報將在給定主機上運行取決于其角色。例如，運行Cassandra的主機將進行與Cassandra的狀態(tài)，磁盤使用情況和其他指標有關的檢查。大多數(shù)此類主機級別檢查是由基礎架構平臺團隊創(chuàng)建和維護的。
高基數(shù)一直是我們警報平臺的最大挑戰(zhàn)。傳統(tǒng)上，這是通過使警報查詢返回多個序列并僅在序列的某個百分比以上違反閾值時才觸發(fā)警報周圍的簡單規(guī)則來處理的。uMonitor還允許用戶將警報設置為依賴于其他警報-跟蹤更大范圍問題的警報取決于更大范圍的警報，并且如果觸發(fā)更大范圍的警報，則從屬警報將被抑制。
只要查詢返回有限數(shù)量的序列，上述技術就可以很好地工作，并且可以輕松定義依賴項。但是，隨著Uber越來越多地在數(shù)百個城市中運營許多不同的產(chǎn)品線，基數(shù)挑戰(zhàn)已要求一種更通用的解決方案。我們使用Origami來協(xié)助處理高基數(shù)。Neris將Origami用作其主要的重復數(shù)據(jù)刪除和通知引擎，并啟用了uMonitor警報的合并通知。
對于業(yè)務指標，當我們需要針對每個城市，每個產(chǎn)品，每個應用版本發(fā)出警報時，Origami非常有用。Origami允許用戶為城市，產(chǎn)品和應用程序版本的組合創(chuàng)建基礎的警報/檢查，并在匯總策略上發(fā)出警報，以基于每個城市/產(chǎn)品/應用程序的版本接收通知。在停電較大的情況下（例如，當許多城市同時出現(xiàn)問題時），Origami將發(fā)送匯總通知，指示觸發(fā)的底層警報列表。
在主機警報方案中，Origami使我們能夠基于警報的匯總狀態(tài)發(fā)送各種嚴重性的通知。我們來看一個有關Cassandra群集上磁盤空間使用情況的示例。在這種情況下，對此的Origami通知政策可能類似于：
如果少于三臺的主機使用了70％的磁盤，則發(fā)送電子郵件通知
如果三個以上的主機有70％的磁盤使用率，則發(fā)送頁面
如果一個或多個主機磁盤使用率達到90％，則發(fā)送頁面
有用的警報通知是擴展警報系統(tǒng)的主要挑戰(zhàn)。警報操作主要從通知開始，例如針對高優(yōu)先級問題呼叫工程師，以及針對信息性問題使用聊天或電子郵件。現(xiàn)在，我們的重點已轉(zhuǎn)向制定緩解措施。大多數(shù)事件和中斷都是由于配置更改或部署而發(fā)生的。uMonitor為緩解操作提供了一流的支持，這些操作可以回滾最近的配置更改和部署。對于具有更復雜的緩解運行手冊的團隊，我們支持webhooks，這些Webhooks可針對具有警報完整上下文的端點進行POST調(diào)用，從而可以運行緩解運行手冊。此外，通過利用Origami中的重復數(shù)據(jù)刪除管道，我們可以在發(fā)生較大故障時抑制更精細的粒度通知。
除上述內(nèi)容外，我們一直在努力使通知更加相關，并使通知針對合適的個人。最近的工作涉及識別配置/部署變更所有者，并在警報觸發(fā)他們已修改的服務時觸發(fā)他們。通過結合來自Jaeger的跟蹤信息和警報信息，我們在圍繞相關服務故障的警報通知中提供更多上下文方面做出了額外的努力。
如前所述，我們一直致力于將uMonitor構建為其他團隊可以針對特定用例建立的平臺。主機警報的設置和管理通常是專門的，主要用于維護自己專用硬件的團隊，以及正在為公司構建基礎架構平臺（包括存儲，指標和計算解決方案）的團隊。警報是在團隊的單獨git存儲庫中配置的，這些存儲庫已同步到Object Config。
從較高的角度來看，uMonitor具有三類警報：
根據(jù)所有服務的CPU，磁盤使用率和RPC統(tǒng)計信息的標準指標自動生成警報
通過UI創(chuàng)建的一次性警報以檢測特定問題
通過uMonitor之上的腳本和外部配置系統(tǒng)創(chuàng)建和管理警報
隨著團隊努力以可能的最佳粒度檢測可警報的問題，我們在最后一類警報中看到了最大的增長。對這種粒度的需求歸結于Uber的全球增長。支持Uber移動應用程序的服務的代碼更改通常會在幾個小時內(nèi)推廣到特定的城市群體。我們非常重要的一點是，我們必須在城市一級監(jiān)視平臺的運行狀況，以便在問題廣泛傳播之前找出問題所在。此外，每個城市的工程和本地操作團隊控制的配置參數(shù)也不同。例如，由于游行等正在進行的事件，城市中的騎手接送可能會被阻塞在街道上，或者其他事件可能會導致交通變化。
許多團隊已經(jīng)在uMonitor上構建了警報生成解決方案來解決此類用例。這些工具解決的一些挑戰(zhàn)是：
遍歷各個維度迭代并生成警報
根據(jù)特定的業(yè)務信息（例如特定國家/城市的假期）確定警報時間表，并在uMonitor中配置該信息以防止虛假警報
如果靜態(tài)或當前異常閾值不起作用，請基于過去的數(shù)據(jù)或?qū)m用于特定業(yè)務線的基礎指標的復雜查詢來確定閾值（更多有關以下警報查詢）
此外，這些解決方案中的許多解決方案都會生成與所生成的警報同步的儀表板。
uMonitor還提供了功能強大的編輯和根本原因UI。UI的編輯和實驗方面至關重要，因為由于變化和峰值，大多數(shù)指標無法按原樣用于警報?？捎^察性團隊為如何創(chuàng)建更適合警報的查詢提供了指導。
Graphite查詢語言和M3QL提供了大量功能，可提供更多定制解決方案。下面，我們概述了一些示例，這些示例說明了如何使查詢返回更一致的值以使指標更易于警惕：
提醒您說幾分鐘內(nèi)移動指標的平均值，以消除指標的任何峰值
將以上內(nèi)容與維持期結合使用，僅在閾值違例持續(xù)了一定時間后才發(fā)送通知
對于具有上下模式的指標，請使用導數(shù)函數(shù)以確保任一方向的峰值都不會太突然
發(fā)出百分比/比率警報，以使度量標準不易受到度量標準大小變化的影響
到此，關于“如何構建Uber的預警生態(tài)系統(tǒng)”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
網(wǎng)頁標題：如何構建Uber的預警生態(tài)系統(tǒng)
鏈接分享：http://weahome.cn/article/gcpded.html
重慶分公司
重慶分公司
