作者 | 田曉旭

嘉賓 | 黃杰

運維行業流傳著一句話：“無監控，不運維”，監控的重要程度可見一斑。

隨著互聯網行業的不斷發展，各種監控工具多得不可勝數，如何利用這些工具構建一個完整好用的監控平臺呢？在近期召開的 QCon 上海 2019 大會現場，InfoQ 記者采訪了餓了么框架工具部、監控平臺負責人黃杰，他和我們分享了隨著業務和系統越來越復雜，餓了么的監控平臺是如何不斷演進的。

餓了么的監控痛點與架構設計??

與其它行業相比，外賣行業最顯著的特點就是它的高峰和低谷是非常明顯的，一般集中在中午的 10 點到 12 點和晚上的 5 點到 8 點，這樣的瞬時高峰對于整個系統的壓力會非常大，監控系統也不例外。

據黃杰介紹整個餓了么的業務發展是超高速的：“我加入餓了么的第一年，當時每天采集的原始數據差不多是 10 個 T，第二年就增長到了 80 個 T，第三年變成了 200T，而現在每天采集的原始數據可以達到 800T?！?/p>

在技術層面，監控系統不僅要支撐這樣快速發展的業務，同時還要兼顧穩定性。在穩定性方面，餓了么 CTO 雪峰對監控系統的要求是比餓了么整個系統可用性高一個 9，因為監控是整個系統的眼睛，如果眼睛出了問題，會影響很多判斷。

而在用戶層面，餓了么監控系統要解決兩類人的問題，第一類是 GOC 的問題，當系統出來問題的時候，怎么快速發現并恢復問題；第二類是開發人員，需要做到的是快速定位問題。

目前餓了么的監控系統覆蓋了所有應用及服務器，包括業務監控、全鏈路監控、PaaS、IaaS 等。如果分層來看的話，最上層是業務，理論上可以做到端到端，針對某些特定業務的監控，運維團隊會與業務團隊一起協作；第二層是應用，云數據中心和本地數據中心的應用都可以監控到；第三層是 PaaS，例如 MySQL、Redis；最底層是 IaaS，主要是關注應用跑在哪些機器上，容器、物理機還是虛擬機，服務器之間的機架、交換機，機房之間的專線等等。

整個監控平臺每天的增量數據大約有 800TB，高峰計算事件 7000W/s，1W多個報警規則。

最早，餓了么監控平臺的架構類似于 Pipeline 的架構，消息采集之后放到隊列里，然后去處理，處理之后再進行存儲。這種架構的缺點是如果一個環節出現問題，那么整個平臺都可能出現問題。除了穩定性，Pipeline 架構整體的開發效率也是一個問題，由于很多監控的邏輯需要去了解業務，再通過代碼來實現，所以實現一個監控項的整個周期會比較長。

因此，餓了么團隊把一些實時計算的邏輯抽象出來，放到自研的一個類 SQL 的實時計算平臺上，把收集到的無結構化的日志轉換成結構化的數據之后 (例如把一條普通的日志轉換成一條 SOA 調用的日志)，再通過 SQL 的方式計算出 Metrics，整個架構也慢慢的從 Pipeline 變成類似于 Lambda 架構，然后計算出來的 Metric 再回溯到 Kafka 中，這些 Metric 又可以被別的系統使用，如流式報警等。

根據重要程度，餓了么團隊又把集群分為關鍵和非關鍵集群，在非關鍵集群上做灰度上線，以保證整個升級過程對用戶無感，如果有問題，可以在非關鍵集群上提早暴露。

另外，在 Collector 這層還做了數據的動態 Load Balance，即根據用戶發送的數據類型提前 Sharding 到 Kafka 不同的 Partition 中，這樣的好處是 Kafka 后面的 Consumer 只需要處理一小部分數據即可，理論上來說隨著數據量的增加只需要水平增加機器就可以解決容量上的問題。

餓了么監控平臺的演進歷程??

開始的時候，餓了么的監控是由不同團隊負責的，直到 2017 年底，把原來 3 個團隊負責的監控系統整合成一個團隊來負責。“統一的好處還是很明顯的”，黃杰表示：“之前幾套監控系統還是比較割裂的，相互之間關聯性比較低，用戶需要在不同的監控系統中看不同維度的監控，有些新同學剛加入的時候，都不知道去哪里查看，而現在有故障出現，普通的開發人員就可以直接查看監控，定位到問題出現在哪里，相比之前，效率的提升還是很明顯的?！?/p>

最早，餓了么一共維護了三套監控系統，去年把三套系統合并成了一套。為什么要這么做呢？黃杰表示主要原因是三套系統來回切換在定位問題時是很浪費時間的。但是合并之后，推行新系統也遇到了一些難題，一是團隊內部的矛盾，因為之前三套系統采集的數據和后臺處理都是類似的，如何來統一呢？二是推行時遇到的外部矛盾，大家已經習慣了通過 Grafana 來查看業務大屏，如何讓用戶切換到新的平臺上是一個比較大的阻力，后來，餓了么團隊啟動了一個公司級項目來推進這個事情，花了半年左右的時間，把所有的監控都統一到了現在的平臺上。

從技術角度來看，餓了么監控平臺從單 IDC 到異地多活共經歷了三個階段。當開發和業務初具規模時，當時主要是使用 ETrace 來做全鏈路監控，使用 Statsd+Graphite+Grafana 做業務層監控，使用 Zabbix 來做運營團隊的業務監控；第二階段標志性的就是做了異地多活，引入 ELK 做日志檢索，使用自研的 ESM 系統替換掉 Zabbix，同時引入了自研的時序數據庫 LinDB；第三階段就是集成，把三個系統整合成到 EMonitor 系統，日志系統使用了阿里云的 SLS 產品，所有的時序數據存儲統一走 LinDB，目前 LinDB 也在做開源版本 (https://github.com/lindb/lindb)。

在黃杰看來，整個監控平臺在餓了么的發展和推行可以分為 3 個階段：

• 第一階段主要是在賣產品，在接近一年中，讓內部的員工接受并使用該平臺；

• 第二階段主要是查漏補缺，所有的監控不可能一蹴而就，是有個過程的，所以這個階段就是不斷完善之前缺少的監控部分；

• 第三階段是建立信任，通過前兩階段，內部員工漸漸享受到了監控平臺帶來的好處，這時要做的就是提升監控準確率，加深他們對平臺的信任感。

目前餓了么監控平臺采取的是自研 + 開源的開發模式，其中自研占據了 70%，分階段性只做 2-3 件很重要的事情，不斷打基礎的同時服務好用戶。

餓了么監控平臺的報警策略??

報警策略是很多企業都會面臨的挑戰，報警太少，可能會遺漏重大的錯誤，而報警太多，則會浪費時間和精力。黃杰表示：“我們沒有使用目前比較流行的機器學習或者人工智能，而是使用的比較傳統的報警策略，針對不同的數據類型提供不同的報警策略給用戶使用?！?/p>

餓了么的報警策略有以下三種：

• 趨勢型報警策略，主要的應用場景是業務大盤的 (黃金指標) 監控報警，因為外賣行業的數據特性還是非常強的，對于這類數據，餓了么團隊會依據歷史數據計算出一個基線數據，在計算基線數據的同時會去掉一些壓測或者異常的數據，因為這些數據是噪音數據，再結合當前數據的趨勢來預測將來的趨勢應該是怎么樣的，如果有偏離就會報警；

• 缺失報警策略，上面也講了整個報警是流式事件驅動性的，如果數據沒有了，整個報警就會失效，所以針對這種場景增加了缺失，以應對流量突然掉底的場景；

• 閾值報警策略，最基礎的閾值報警，用戶輸入一個條件，高于或者低于就會報警。但建議用戶把一些個數可以轉換成比率，例如失敗率>10%，比錯誤數>1000，更容易讓人理解。

采訪嘉賓

黃杰，餓了么框架工具部，監控平臺負責人。2015 年加入餓了么，負責整個監控平臺的構建及周邊工具鏈的建設。整個監控也經歷了餓了么異地多活地洗禮。之前曾在攜程、eBao 等多家公司工作，在監控、消息系統及大數據等領域積累了豐富經驗。

總結

以上是生活随笔為你收集整理的饿了么监控平台的架构设计与演进历程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。