本文根據黃傑老師在〖2019 Gdevops全球敏捷運維峰會-廣州站 〗現場演講內容整理而成。
（點擊文末“閱讀原文”可獲取完整PPT）
講師介紹
黃傑，前餓了麼框架工具部監控平臺負責人。2015年加入餓了麼，負責整個監控平臺的構建及周邊工具鏈的建設。之前曾在攜程、eBao等多家公司工作，在監控、消息系統及大數據等領域積累了豐富經驗。
分享概要
1、背景
2、遇到的問題
3、場景化
4、系統設計
大家好！很榮幸有這樣的機會和大家交流，今天分享的主題為《餓了麼監控體系的演進》。
我差不多是2015年中加入餓了麼，主要是負責餓了麼整個監控平臺的搭建，從0開始搭建這套監控系統。
今天主要從以下四塊給大家講一下，整個過程我們遇到了哪些問題，怎麼來解決這些問題，以及用怎麼樣的設計來支撐起這個系統。
一、背景
其實整個餓了麼監控系統在演進過程中主要分為如下3個階段：
第一階段：主要由Statsd/Graphite/Grafana負責業務層的監控，ETrace負責全鏈路監控，Zabbix負責服務器層面的監控，ELog負責分佈式日誌搜索；
第二階段：整個餓了麼也從單IDC演進成異地多活架構，所以對監控也提出了更高的要求，基於這個我們也自研LinDB，以支持多活架構下的監控，Zabbix慢慢被ESM/InfluxDB/Grafana所替換，使用ELK替換原來的日誌方案；
第三階段：主要做一個減法，即把原來StatsD/Graphite/ETrace/ESM/InfluxDB統一到了EMonitor+LinDB這樣的平臺，以提供給用戶一套統一的監控平臺，日誌開始使用阿里雲的SLS；
二、遇到的問題
在這過程中我們主要遇到了哪些問題，然後我們怎麼去解決這些問題。
之前也介紹了原來有多套監控系統，當出現問題的時候，需要從多套監控系統裡面回來切換，其實這種上下文的切換是很影響定位問題的時間，一旦故障時間很長的話就意味著故障的影響範圍也會變大。
那我們怎麼來解決這個問題呢？
我們希望有這麼樣一套系統能針對於任何人員快速上手。圍繞著快速發現問題和快速定位問題這兩個點，來構建這套系統。
其實監控也可以像業務架構一下進行分層，如上圖，可以分為，業務監控，應用監控，PaaS層監控及IaaS層監控。
不同用戶在每一層的視角是不一樣的，但是如何把各層的數據串聯起來是一個關鍵點。
再結合Logging/Tracing/Metric三者的關係，我們是通過Tracing把上面各層的關係給串聯起來。
最終，我們提供了一套一站式的監控平臺，同時支持PC和Mobile 2個平臺。
三、場景化
首先，我們來看一下業務監控，很多公司的業務監控都是用Grafana來做可視化，餓了麼原來也一直用Grafana，現在已經全部使用EMonitor。
相比Grafana，EMonitor會更多的與別的監控集成，如一個業務監控有問題，點擊一下有問題的曲線就可以到相關的應用監控，也可以比較方便的也報警配置集成。同時所有的Dashboard都與具體的業務線有關。
同時系統也是自動的集成發佈及報警事件，如果與相關曲線有關的應用有報警或者變更，就會直接在圖上畫上紅線(報警)和綠線(變更)，這些使用都不需要額外的操作，都是系統自動完成的。
40%~50%的事故都是與變更有關係，這樣當有變更導致的問題可以直接在監控上看到，馬上回滾解決問題。
說完業務監控，我們再來看一下應用層監控，這塊主要依託於全鏈路監控，主要用於問題的定位。
大家可以看到，這塊基本上覆蓋了整個應用所有內部及依賴的監控，而且這些基本上都使用方是透明的，使用方只需要使用我們部門提供的基礎服務就可以了，會在這些基礎的SDK進行監控埋點。
同時，有時直接放一個當前的監控數據，很難反應問題，因為不知道相比之前是變好了，還是變差了，所以我們會對所有的監控曲線都做同比和環比，這樣就可以直觀的反應問題。
接下來我以幾個日常排障中使用比較多的功能介紹一下。
首先來看一下，錯誤異常。
基本上當出問題的時候，大家都會上來看一下有沒有報異常什麼的，針對於異常我們也增加了當某個異常出現的時候，到底影響了哪些接口的請求，以方便業務方做判斷。
再來看一下SOA相關的監控，SOA會反應當一個服務有問題的時候，是自身有問題還是依賴的服務有問題，可以看到一個服務的RT，成功率，及哪些調用方等。
那麼當應用所依賴的基礎設施有問題的時候，怎麼辦呢？
其實這部分可以分兩部分來看，一部分是Client是不是有問題，還有一部分是Server端有沒有問題，因為有了Client的訪問數據，所以就可以很方便的知道這個應用使用了哪些基礎設施，這些基礎設施有沒有問題。
這裡主要講一下數據庫，因為日常來說業務開發跟數據庫打交道是非常多的，所以我們在DAL這層做了很多監控，基本上做到了針對每條SQL都做了監控，可以看到每條SQL的RT，成功率等。主庫怎麼樣、從庫怎麼樣。
針對IaaS層的監控，我們自研了一套監控系統，來採集服務器CPU/Memory/Network等數據，同時也支持使用方根據自己的需求來寫自己的Plugin來採集數據，如怎麼來監控Redis/MySQL等。
說了這麼多，基本上都是監控圖表，那麼怎麼來查看日誌呢？
其實這個是整個系統的另外一個亮點，應該所有的這些圖表都是可以支持下鑽的，如發現有問題，只要鼠標點擊一下就可以看到對應的日誌。
四、系統設計
系統從原來的Pipeline慢慢演進成類似Lambda架構；
支持多IDC，每個IDC都會部署紅色框裡面的組件；
全量日誌，通過指標+採樣的方式；
支持Java/Golang/Python/PHP/C++/Node.js；
所有監控數據計算窗口為10S；
自研+開源組件構建了整套系統。
針對於數據的處理計算，我們自研了一套計算平臺Shaka也支持所有監控數據的清洗及計算。
基於CEP(Esper) 實現類SQL的計算；
非結構化的數據轉換成結構化數據；
UDF處理異常數據分析及採樣。
最後介紹一下，支撐起所有監控數據存儲的自研時序數據庫 - LinDB。
採用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。
這塊我們目前也在做開源版本，如果對這塊有興趣可以關注我們：
https://github.com/lindb/lindb
https://lindb.io/
今天的分享就到這裡，最後為一直在監控領域奮戰的同學打一下氣，做監控真的很有意思，接觸的面也很多，面對大數據量衝擊的同時，還需要考慮產品層的沉澱。
閱讀更多 dbaplus社群 的文章
