Categories
程式開發

餓了麼監控體系:從架構的減法中演進而來


本文由 dbaplus 社群授權轉載。

大家好!很榮幸有這樣的機會和大家交流,今天分享的主題為《餓了麼監控體系的演進》。

我差不多是2015年中加入餓了麼,主要是負責餓了麼整個監控平台的搭建,從0開始搭建這套監控系統。

今天主要從以下四塊給大家講一下,整個過程我們遇到了哪些問題,怎麼來解決這些問題,以及用怎麼樣的設計來支撐起這個系統。

一、背景

其實整個餓了麼監控系統在演進過程中主要分為如下3個階段:

餓了麼監控體系:從架構的減法中演進而來 1

  • 第一階段:主要由Statsd/Graphite/Grafana負責業務層的監控,ETrace負責全鏈路監控,Zabbix負責服務器層面的監控,ELog負責分佈式日誌搜索;
  • 第二階段:整個餓了麼也從單IDC演進成異地多活架構,所以對監控也提出了更高的要求,基於這個我們也自研LinDB,以支持多活架構下的監控,Zabbix慢慢被ESM/InfluxDB/Grafana所替換,使用ELK替換原來的日誌方案;
  • 第三階段:主要做一個減法,即把原來StatsD/Graphite/ETrace/ESM/InfluxDB統一到了EMonitor+LinDB這樣的平台,以提供給用戶一套統一的監控平台,日誌開始使用阿里雲的SLS;

二、遇到的問題

在這過程中我們主要遇到了哪些問題,然後我們怎麼去解決這些問題。

餓了麼監控體系:從架構的減法中演進而來 2

之前也介紹了原來有多套監控系統,當出現問題的時候,需要從多套監控系統裡面回來切換,其實這種上下文的切換是很影響定位問題的時間,一旦故障時間很長的話就意味著故障的影響範圍也會變大。

那我們怎麼來解決這個問題呢?

我們希望有這麼樣一套系統能針對於任何人員快速上手。圍繞著快速發現問題和快速定位問題這兩個點,來構建這套系統。

餓了麼監控體系:從架構的減法中演進而來 3

其實監控也可以像業務架構一下進行分層,如上圖,可以分為,業務監控,應用監控,PaaS層監控及IaaS層監控。

不同用戶在每一層的視角是不一樣的,但是如何把各層的數據串聯起來是一個關鍵點。

再結合Logging/Tracing/Metric三者的關係,我們是通過Tracing把上面各層的關係給串聯起來。

餓了麼監控體系:從架構的減法中演進而來 4

最終,我們提供了一套一站式的監控平台,同時支持PC和Mobile 2個平台。

餓了麼監控體系:從架構的減法中演進而來 5

三、場景化

餓了麼監控體系:從架構的減法中演進而來 6

首先,我們來看一下業務監控,很多公司的業務監控都是用Grafana來做可視化,餓了麼原來也一直用Grafana,現在已經全部使用EMonitor。

相比Grafana,EMonitor會更多的與別的監控集成,如一個業務監控有問題,點擊一下有問題的曲線就可以到相關的應用監控,也可以比較方便的也報警配置集成。同時所有的Dashboard都與具體的業務線有關。

同時系統也是自動的集成發布及報警事件,如果與相關曲線有關的應用有報警或者變更,就會直接在圖上畫上紅線(報警)和綠線(變更),這些使用都不需要額外的操作,都是系統自動完成的。

40%~50%的事故都是與變更有關係,這樣當有變更導致的問題可以直接在監控上看到,馬上回滾解決問題。

餓了麼監控體系:從架構的減法中演進而來 7

說完業務監控,我們再來看一下應用層監控,這塊主要依託於全鏈路監控,主要用於問題的定位。

大家可以看到,這塊基本上覆蓋了整個應用所有內部及依賴的監控,而且這些基本上都使用方是透明的,使用方只需要使用我們部門提供的基礎服務就可以了,會在這些基礎的SDK進行監控埋點。

同時,有時直接放一個當前的監控數據,很難反應問題,因為不知道相比之前是變好了,還是變差了,所以我們會對所有的監控曲線都做同比和環比,這樣就可以直觀的反應問題。

接下來我以幾個日常排障中使用比較多的功能介紹一下。

餓了麼監控體系:從架構的減法中演進而來 8

首先來看一下,錯誤異常。

基本上當出問題的時候,大家都會上來看一下有沒有報異常什麼的,針對於異常我們也增加了當某個異常出現的時候,到底影響了哪些接口的請求,以方便業務方做判斷。

餓了麼監控體系:從架構的減法中演進而來 9

再來看一下SOA相關的監控,SOA會反應當一個服務有問題的時候,是自身有問題還是依賴的服務有問題,可以看到一個服務的RT,成功率,及哪些調用方等。

那麼當應用所依賴的基礎設施有問題的時候,怎麼辦呢?

其實這部分可以分兩部分來看,一部分是Client是不是有問題,還有一部分是Server端有沒有問題,因為有了Client的訪問數據,所以就可以很方便的知道這個應用使用了哪些基礎設施,這些基礎設施有沒有問題。

餓了麼監控體系:從架構的減法中演進而來 10

這裡主要講一下數據庫,因為日常來說業務開發跟數據庫打交道是非常多的,所以我們在DAL這層做了很多監控,基本上做到了針對每條SQL都做了監控,可以看到每條SQL的RT,成功率等。主庫怎麼樣、從庫怎麼樣。

針對IaaS層的監控,我們自研了一套監控系統,來採集服務器CPU/Memory/Network等數據,同時也支持使用方根據自己的需求來寫自己的Plugin來採集數據,如怎麼來監控Redis/ MySQL等。

餓了麼監控體系:從架構的減法中演進而來 11

說了這麼多,基本上都是監控圖表,那麼怎麼來查看日誌呢?

其實這個是整個系統的另外一個亮點,應該所有的這些圖表都是可以支持下鑽的,如發現有問題,只要鼠標點擊一下就可以看到對應的日誌。

餓了麼監控體系:從架構的減法中演進而來 12

餓了麼監控體系:從架構的減法中演進而來 13

餓了麼監控體系:從架構的減法中演進而來 14

四、系統設計

餓了麼監控體系:從架構的減法中演進而來 15

  • 系統從原來的Pipeline慢慢演進成類似Lambda架構;
  • 支持多IDC,每個IDC都會部署紅色框裡面的組件;
  • 全量日誌,通過指標+採樣的方式;
  • 支持Java/Golang/Python/PHP/C++/Node.js;
  • 所有監控數據計算窗口為10S;
  • 自研+開源組件構建了整套系統。

針對於數據的處理計算,我們自研了一套計算平台Shaka也支持所有監控數據的清洗及計算。

餓了麼監控體系:從架構的減法中演進而來 16

餓了麼監控體系:從架構的減法中演進而來 17

  • 基於CEP(Esper) 實現類SQL的計算;
  • 非結構化的數據轉換成結構化數據;
  • UDF處理異常數據分析及採樣。

最後介紹一下,支撐起所有監控數據存儲的自研時序數據庫 – LinDB。

餓了麼監控體系:從架構的減法中演進而來 18

  • 採用Metric + Tags + Fields方式;
  • 基於Series Sharding,支持水平擴展;
  • 自動的Rollup,s->m->h->d;
  • 高可靠性,支持多副本,支持跨機房;
  • 自監控,數據治理;
  • 列式存儲,具有時序特性的LSM存儲結構;
  • 倒排索引。

目前的數據量如下:

  • 36台服務器,分不同集群;
  • 每天增量寫入140T;
  • 高峰TPS: 750W DPS/s;
  • 10S存30天,歷史可查2年以上;
  • 磁盤佔用50T (壓縮率在60倍左右);
  • 查詢P99:500ms ~ 1s。

這塊我們目前也在做開源版本,如果對這塊有興趣可以關注我們:

今天的分享就到這裡,最後為一直在監控領域奮戰的同學打一下氣,做監控真的很有意思,接觸的面也很多,面對大數據量衝擊的同時,還需要考慮產品層的沉澱。

作者介紹

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

原文鏈接

https://mp.weixin.qq.com/s/BSUkygEgCT8OJy62UXsefg