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 日
提醒：這是一場社群會議。因此，讓我們儘量避開公然推銷產品和/或供應商銷售宣傳。