CNCF案例研究:Uber
Uber怎樣使用其開源的Prometheus平臺監控4,000個微服務
公司:Uber
地點:加利福尼亞州舊金山
行業:運輸技術
挑戰
由於需要監控4,000個專有微服務和越來越多的開源系統,到2014年底,Uber的指標使用量已超過了他們基於Graphite和Nagios所能提供的。“許多團隊使用預先打包的Graphite監控軟體,並嘗試在Nagios中編寫指令碼來檢查從這些軟體包中收集的指標,這很難大規模維護。”指標和系統監控技術負責人Rob Skillington說道。“此外,所有這些額外服務生成的指標數量,以及Graphite無法在堆疊複製和管理方面進行擴充套件的事實。它不那麼動態,在我們需要做出的任何改變中都需要大量的手動操作和停機時間。”
解決方法
Skillington的團隊評估了幾種技術,包括Atlas和OpenTSDB,但越來越多的開源系統為Prometheus Metrics Exporter格式新增原生支援這一事實,使得該方向的規模有所提升。“我們最終選擇了Prometheus,因為客戶端庫和功能是Uber工程師想要使用的,”Skillington說。“很明顯,使用標準的Prometheus exporter遠比編寫和維護自己的exporter好得多。總的來說,我們喜歡社群建立的生態系統和支援的基礎設施。”他的團隊還構建並開源了 M3 平臺,這是一個針對Prometheus指標的可擴充套件和可配置的儲存。M3目前在Uber擁有超過66億個時間序列,每秒可累計達5億個指標,並且於全球儲存每秒2000萬個指標。
影響
通過使用Prometheus和M3,Uber用於提取指標的儲存成本效率提高了8.53倍。該團隊估計,在Uber資料中心為其先進技術部門建立監控系統的速度比之前的流程快4倍。“對於那些支援Prometheus指標的系統,我們幾乎不用花任何時間就能上,相對於我們自己進入和手工操作所需的固定時間。”Skillington說。此外,該團隊現在減少了16.67倍的運營維護負擔:每週的高/低緊急通知數量從Cassandra的25個到M3DB的1.5個。
“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萬個指標。
通過使用Prometheus和M3,Uber用於提取指標的儲存成本效率提高了8.53倍。該團隊估計,在Uber資料中心為其先進技術部門建立監控系統的速度比之前的流程快4倍。“對於那些支援Prometheus指標的系統,我們幾乎不用花任何時間就能上,相對於我們自己進入和手工操作所需的固定時間。”Skillington說。此外,該團隊現在減少了16.67倍的運營維護負擔:每週的高/低緊急通知數量從Cassandra的25個到M3DB的1.5個。
鑑於這些結果,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) 主辦專案的領導,和我們一同探討雲原生生態系統發展方向。
在中國開源峰會上,與會者將共同合作及共享資訊,瞭解最新和最有趣的開源技術,包括Linux、IoT、區塊鏈、AI、網路等;並獲得如何在開源社群中導向和引領的資訊。
大會日期:
- 提案徵集截止日期:太平洋標準時間 2 月 22 日,星期五,晚上 11:59
- 提案徵集通知日期:2019 年 4 月 8 日
- 會議日程通告日期:2019 年 4 月 10 日
- 會議活動舉辦日期:2019 年 6 月 24 至 26 日
提醒:這是一場社群會議。因此,讓我們儘量避開公然推銷產品和/或供應商銷售宣傳。