CNCF案例研究：Uber

時間 2020-02-06

標籤 cncf 案例研究 uber 欄目硅谷简体版

原文原文鏈接

Uber怎樣使用其開源的Prometheus平臺監控4,000個微服務node

公司：Uber
地點：加利福尼亞州舊金山
行業：運輸技術linux

挑戰

因爲須要監控4,000個專有微服務和愈來愈多的開源系統，到2014年末，Uber的指標使用量已超過了他們基於Graphite和Nagios所能提供的。「許多團隊使用預先打包的Graphite監控軟件，並嘗試在Nagios中編寫腳原本檢查從這些軟件包中收集的指標，這很難大規模維護。」指標和系統監控技術負責人Rob Skillington說道。「此外，全部這些額外服務生成的指標數量，以及Graphite沒法在堆棧複製和管理方面進行擴展的事實。它不那麼動態，在咱們須要作出的任何改變中都須要大量的手動操做和停機時間。」ios

解決方法

Skillington的團隊評估了幾種技術，包括Atlas和OpenTSDB，但愈來愈多的開源系統爲Prometheus Metrics Exporter格式添加原生支持這一事實，使得該方向的規模有所提高。「咱們最終選擇了Prometheus，由於客戶端庫和功能是Uber工程師想要使用的，」Skillington說。「很明顯，使用標準的Prometheus exporter遠比編寫和維護本身的exporter好得多。總的來講，咱們喜歡社區建立的生態系統和支持的基礎設施。」他的團隊還構建並開源了M3平臺，這是一個針對Prometheus指標的可擴展和可配置的存儲。M3目前在Uber擁有超過66億個時間序列，每秒可累計達5億個指標，而且於全球存儲每秒2000萬個指標。git

影響

經過使用Prometheus和M3，Uber用於提取指標的存儲成本效率提升了8.53倍。該團隊估計，在Uber數據中心爲其先進技術部門創建監控系統的速度比以前的流程快4倍。「對於那些支持Prometheus指標的系統，咱們幾乎不用花任什麼時候間就能上，相對於咱們本身進入和手工操做所需的固定時間。」Skillington說。此外，該團隊如今減小了16.67倍的運營維護負擔：每週的高/低緊急通知數量從Cassandra的25個到M3DB的1.5個。github

「Prometheus增長了大量高質量的庫和常見的監控指標出口商（exporter），它導出指標的方式使咱們很容易繼續引入現有軟件並大規模使用。」後端

ROB SKILLINGTON，UBER指標和系統監測技術主管

在短短七年的時間裏，Uber已成爲全球700多個城市的平常便利。爲了幫助管理其指數式增加和由此產生的規模 - 移動應用程序已將車友和司機鏈接超過十億次 - 該公司開始將其單體分解爲微服務。網絡

但最初只有幾十個，很快成爲4,000個專有的後端微服務，須要進行監控、警報和異常檢測。最重要的是，Uber但願能夠觀察到服務運行的系統，例如Ubuntu，以及MySQL、Cassandra、Redis、Etcd、ZooKeeper和Kafka等開源軟件，它們都是在公司的數據中心、AWS和GCP的組合上運行。面對這種複雜性，「咱們使用Graphite和Nagios構建咱們本身的系統和組件進行監控」，指標和系統監控技術主管Rob Skillington說。架構

到2014年末，已經很明顯地Uber已經超過了這個DIY設置。「許多團隊使用預先打包的Graphite監控軟件，並嘗試在Nagios中編寫腳原本檢查從這些軟件包中收集的指標，這很難大規模維護。」指標和系統監控技術負責人Rob Skillington說道。「此外，全部這些額外服務生成的指標數量，以及Graphite沒法在堆棧複製和管理方面進行擴展的事實。它不那麼動態，在咱們須要作出的任何改變中都須要大量的手動操做和停機時間。」微服務

「開放式治理和普遍的行業參與使咱們感到放心，Prometheus能夠與咱們如今和將來須要監控的任何流行的開源軟件兼容。」區塊鏈

ROB SKILLINGTON，UBER指標和系統監測技術主管

Skillington的團隊評估了幾種技術，包括Atlas和OpenTSDB，但愈來愈多的開源系統爲Prometheus Metrics Exporter格式添加原生支持這一事實使得該方向的規模有所提高。「咱們最終選擇了Prometheus，由於客戶端庫和功能是Uber工程師想要使用的，」Skillington說。「很明顯，使用標準的Prometheus exporter遠比編寫和維護本身的exporter好得多。總的來講，咱們喜歡社區建立的生態系統和支持的基礎設施。」

此外，他補充說，「項目在CNCF上託管很是重要，由於這意味着咱們相信在一段時間內會有一個強大的社區。開放式治理和普遍的行業參與使咱們感到放心，Prometheus將與咱們如今和未來須要監控的幾乎任何流行的開源軟件兼容。」

根據該決定，該團隊尋找公司現有指標平臺的開源替代方案。發現沒有任何能夠做爲自助服務平臺運行，或者沒法知足公司的資源效率或規模目標，該團隊構建並開源了M3平臺，這是一個可擴展且可配置的Prometheus指標存儲。「剛開始，M3利用幾乎徹底開源的組件來完成基本功能，例如用於聚合的statsite，帶有日期分層壓縮策略的Cassandra用於時間序列存儲，以及用於索引的Elasticsearch。」Skillington說。「因爲運營負擔，成本效率和不斷增加的功能集，咱們逐漸超出了每個。」隨着時間的推移，Uber開發了替換組件：M3DB、M3 Query、M3 Coordinator和M3 Aggregator，這些做爲M3的一部分都是開源的。

「咱們並不是真正從事指標系統的寫做或賺錢業務，所以咱們但願社區可以使用咱們的M3平臺並使用它。但願它也有助於路線圖。」

ROB SKILLINGTON，UBER指標和系統監測技術主管

Uber的M3平臺目前擁有超過66億個時間序列，每秒可累計5億個指標，而且於全球存儲每秒2000萬個指標。

鑑於這些結果，Skillington的團隊正致力於加速在Uber採用Prometheus和M3。全部指標都已存儲在M3中，任何在本地或雲中運行的開源軟件主要由Prometheus Metrics Exporters監控。高達10％的Uber專有服務正在使用Prometheus指標客戶端庫。Skillington但願看到Prometheus和剛剛成爲CNCF沙箱項目的OpenMetrics提供兩種格式的單個客戶端庫融合。隨着時間的推移，Skillington表示，「咱們但願將全部專有服務以及咱們還沒有使用Prometheus/OpenMetrics監控的任何剩餘開源軟件轉換爲使用它。」

「不要解決已經解決的問題，」他說。「大多數人都以徹底端到端的方式評估開源指標基礎架構。狀況再也不是如此。今天，系統之間存在不少互操做性，最好能真正解決你平臺和設置所獨有的部分。」

ROB SKILLINGTON，UBER指標和系統監測技術主管

爲此，Skillington表示，與Prometheus的集成增長是一個優先事項，「不管是爲任何導出Prometheus指標的應用程序提供可觀察性，仍是使用node_exporter或其餘第三方Prometheus指標出口商進行系統監控。」他的團隊也確保任何在Uber產品以外運行的環境都會暴露Prometheus指標，並具備標準的Prometheus設置。此外，「咱們但願讓沒有經驗的團隊更容易本身運行Prometheus或M3。這種類型的軟件不須要複雜操做。」Skillington說。

對於開始這條監控路徑的其餘組織，Skillington提出了一些簡單的建議：「不要解決已經解決過的問題，」他說。「大多數人都以徹底端到端的方式評估開源指標基礎架構。狀況再也不是如此。今天，系統之間存在不少互操做性，最好能真正解決你平臺和設置所獨有的部分。」

這是Uber對M3的使命，如今團隊很樂意與其餘人分享。「就像其餘人所說的那樣，咱們並不是真正從事指標系統的寫做或賺錢業務，所以咱們但願社區可以採用咱們的M3平臺並使用它。但願它也有助於路線圖。」

KubeCon + CloudNativeCon中國論壇提案徵集（CFP）2月22日截止

KubeCon + CloudNativeCon 論壇讓用戶、開發人員、從業人員匯聚一堂，面對面進行交流合做。與會人員有 Kubernetes、Prometheus 及其餘雲原生計算基金會 (CNCF) 主辦項目的領導，和咱們一同探討雲原生生態系統發展方向。

中國開源峯會提案徵集（CFP）2月22日截止

在中國開源峯會上，與會者將共同合做及共享信息，瞭解最新和最有趣的開源技術，包括Linux、IoT、區塊鏈、AI、網絡等；並得到如何在開源社區中導向和引領的信息。

大會日期：