摘要：典型實(shí)現(xiàn)不同的監(jiān)控模塊，側(cè)重于不同領(lǐng)域，有著不同的職責(zé)。指標(biāo)收集方面，支持多樣化的組件將被優(yōu)先下使用。以上談了這么多，僅僅是聊了一下收集方面而已。

更多文章，請移步微信公眾號《小姐姐味道》 
mp原文 https://mp.weixin.qq.com/s?__...
監(jiān)控是分布式系統(tǒng)的必備組件，能夠起到提前預(yù)警、問題排查、評估決策等功效，乃行走江湖、居家必備之良品。

一個宿主機(jī)cpu的報(bào)警叫做監(jiān)控；一個業(yè)務(wù)日志的報(bào)錯叫做監(jiān)控；一個APM條件的觸發(fā)，也叫做監(jiān)控。分布式系統(tǒng)錯綜復(fù)雜，隨便做個統(tǒng)計(jì)指標(biāo)的集合，也屬于監(jiān)控的范疇。怎樣做到通用化，理清其中的關(guān)系，是需要花點(diǎn)功夫的，否則揉成一團(tuán)，就不好拆了。

我習(xí)慣性從以下兩種類型對其進(jìn)行劃分，真正實(shí)施起來，系統(tǒng)還是按照數(shù)據(jù)象限分比較合理：
數(shù)據(jù)象限 從數(shù)據(jù)類型劃分，大體可分為：日志（logs）、監(jiān)控(metrics)、調(diào)用鏈(tracing)。
功能象限 從業(yè)務(wù)角度劃分，可分為：基礎(chǔ)監(jiān)控、中間件監(jiān)控、業(yè)務(wù)監(jiān)控

不管什么樣的監(jiān)控系統(tǒng)，又涉及以下幾個模塊過程：
? 數(shù)據(jù)收集。如何在廣度和效率上進(jìn)行數(shù)據(jù)歸并。
? 數(shù)據(jù)加工。數(shù)據(jù)的整理、傳輸和存儲。
? 特稱提取。大數(shù)據(jù)計(jì)算，中間結(jié)果生成存儲。
? 數(shù)據(jù)展示。高顏值、多功能顯示。

其中，特征提取只有數(shù)據(jù)量達(dá)到一定程度才會開啟，因?yàn)樗拈_發(fā)和運(yùn)維成本一般小公司是不會玩的。

不同的監(jiān)控模塊，側(cè)重于不同領(lǐng)域，有著不同的職責(zé)。我個人是傾向于 獨(dú)立設(shè)計(jì) 的，但需要做一定程度的集成，主要還是使用方式上的集成和優(yōu)化。

我將從幾個典型解決方案說起，來說一下為什么要分開設(shè)計(jì)，而不是揉成一團(tuán)。

系統(tǒng)監(jiān)控用來收集宿主機(jī)的監(jiān)控狀況（網(wǎng)絡(luò)、內(nèi)存、CPU、磁盤、內(nèi)核等），包括大部分?jǐn)?shù)據(jù)庫和中間件的敏感指標(biāo)。這些metric的典型特點(diǎn)是結(jié)構(gòu)固定、有限指標(biāo)項(xiàng)，使用時序數(shù)據(jù)庫進(jìn)行存儲是最合適的。

指標(biāo)收集方面，支持多樣化的組件將被優(yōu)先下使用。比如telegraf，支持所有的系統(tǒng)指標(biāo)收集和大部分中間件和DB的指標(biāo)收集。

在這里特別推薦一下其中的jolokia2組件，可以很容易的實(shí)現(xiàn)JVM監(jiān)控等功能。

指標(biāo)收集以后，強(qiáng)烈建議使用kafka進(jìn)行一次緩沖。除了其逆天的堆積能力，也可以方便的進(jìn)行數(shù)據(jù)共享（比如將nginx日志推送給安全組）。
參考本公眾號：【360度測試：KAFKA會丟數(shù)據(jù)么？其高可用是否滿足需求？】

指標(biāo)進(jìn)入消息隊(duì)列后，一份拷貝將會通過logstash的過濾和整理入庫ES等NoSQL；另外一份拷貝，會經(jīng)過流計(jì)算，統(tǒng)計(jì)一些指標(biāo)（如QPS、平均相應(yīng)時間、TP值等）。

可以有多種途徑計(jì)算觸發(fā)報(bào)警的聚合計(jì)算。回查、疊加統(tǒng)計(jì)都是常用的手段。在數(shù)據(jù)量特別大的情況下，先對指標(biāo)數(shù)據(jù)進(jìn)行預(yù)處理是必備的，否則，再牛的DB如influxdb也承受不住。

展現(xiàn)方面，grafana因其極高的顏值，首選，并支持通過iframe嵌入到其他系統(tǒng)。其缺點(diǎn)也是顯著的：支持類型有限（同比、環(huán)比、斜率都木有）；報(bào)警功能不是很好用。

怎么？覺得這套技術(shù)棧過長？你其實(shí)是可以直接選擇zabbix這種現(xiàn)成的解決方案組件的，它的插件也夠多，小型公司用起來其實(shí)最爽不過了。但組件畢竟太集中了，你不方便將其打散，發(fā)現(xiàn)問題也不能任性的替換它的模塊，這在架構(gòu)上，是一個致命硬傷。最后突然發(fā)現(xiàn)，實(shí)現(xiàn)成本居然增加了。這也是為什么上點(diǎn)規(guī)模的公司，都不在用它。

自己開發(fā)一個也是可行的，但不簡單，要處理各種復(fù)雜的前端問題，也不是每個人都能夠做漂亮。

說到日志部分，大家首先想到的肯定是ELKB啊。但我覺得ELKB的鏈路不穩(wěn)定不完整，建議做以下改造：

可以看到和系統(tǒng)監(jiān)控的構(gòu)造其實(shí)是差不多的，很多組件可以重用。區(qū)別就是數(shù)據(jù)量大，往往一不小心就把帶寬占滿了。日志的特點(diǎn)就是量大無規(guī)則（nginx算是良民了），SLA要求不會太高。

這時候收集部分就要用一些經(jīng)的住考驗(yàn)的日志收集組件了。Logstash的資源控制不是太智能，為了避免爭搶業(yè)務(wù)資源，flume、beats是更好的選擇。

同樣，一個消息隊(duì)列的緩沖是必要的，否則大量Agent假死在業(yè)務(wù)端可不是鬧著玩的。

關(guān)于日志落盤。很多日志是沒必要入庫的，比如研發(fā)同學(xué)開開心心打出來的DEBUG日志，所以要有日志規(guī)范。logstash根據(jù)這些規(guī)范進(jìn)行過濾，落庫到ES。日志量一般很大，按天建索引比較好。更久之前的日志呢，可以歸集到日志堡壘機(jī)（就是非常非常大的磁盤），或者直接放HDFS里存檔了。

那么怎么過濾業(yè)務(wù)日志的錯誤情況呢，比如有多少XXX異常觸發(fā)報(bào)警。這種情況下可以寫腳本，也可以接一份數(shù)據(jù)進(jìn)行處理，然后生成監(jiān)控項(xiàng)，拋給metrics收集器即可。

哈！又繞回去了。

相比較普通監(jiān)控和日志，調(diào)用鏈APM等就復(fù)雜的多了。除了有大量的數(shù)據(jù)產(chǎn)生源，也要有相應(yīng)的業(yè)務(wù)組件來支持調(diào)用鏈聚合和展示。其功能展示雖然簡單，但卻是監(jiān)控體系里最復(fù)雜的模塊。

Google 的論文
“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”
開啟了調(diào)用鏈的流行。后續(xù)可以說是百家齊放，直到近幾年才出現(xiàn)了OpenTracing這樣的標(biāo)準(zhǔn)。

在數(shù)據(jù)處理和后續(xù)展示方面，它的技術(shù)點(diǎn)其實(shí)與監(jiān)控技術(shù)是雷同的，復(fù)雜性主要體現(xiàn)在調(diào)用鏈數(shù)據(jù)的收集上。目前的實(shí)現(xiàn)方式，有類似Pinpoint這種直接使用javaagent技術(shù)修改字節(jié)碼的；也有類似于cat這種直接進(jìn)行編碼的。其各有優(yōu)缺點(diǎn)，但都需要解決以下問題：
? 收集組件的異構(gòu)化。開發(fā)語言可能有java，也可能有golang
? 組件的多樣化。從前端埋點(diǎn)開始，nginx、中間件、db等鏈路都需要包含
? 技術(shù)難點(diǎn)的攻關(guān)。如異步、進(jìn)程間上下文傳遞等
? 采樣。尤其在海量調(diào)用時，既要保證準(zhǔn)確性，也要保證效率

關(guān)于Tracing的數(shù)據(jù)結(jié)構(gòu)，已經(jīng)爛大街，在此就不多說了。各種實(shí)現(xiàn)也各自為政，協(xié)議上相互不兼容，做了很多重復(fù)的工作。為了解決不同的分布式追蹤系統(tǒng) API 不兼容的問題，誕生了 OpenTracing（ http://opentracing.io/ ） 規(guī)范。說白了就是一套接口定義，主流的調(diào)用鏈服務(wù)端實(shí)現(xiàn)都兼容此規(guī)范，如zipkin、jaeger。也就是說你只要按照規(guī)范提供了數(shù)據(jù)，就能夠被zipkin收集和展示。

OpenTracing大有一統(tǒng)天下的架勢，它在其中融合Tracing、Log、Metrics的概念。我們還是上張圖吧，等真正去做的時候去了解也不晚（來源于網(wǎng)絡(luò)）。

值得一提的是，SpringCloud對它的支持還是比較全面的（https://github.com/opentracing-contrib），但依賴關(guān)系和版本搞的非常混亂。建議參考后自己開發(fā)，大體使用"spring boot starter"技術(shù)，可以很容易的寫上一版。

至于"Spring Cloud 2"，更近一步，集成了micrometer這種神器，對prometheus集成也是非常的有好。業(yè)務(wù)metrics監(jiān)控將省下不少力氣。

以上談了這么多，僅僅是聊了一下收集方面而已。標(biāo)準(zhǔn)這個思路是非常對的，否則每個公司都要寫一遍海量的收集組件，多枯燥。至于國內(nèi)大公司的產(chǎn)品，是否會主動向其靠攏，我們拭目以待。

服務(wù)端方面，我們以Uber的Jaeger為例，說明一下服務(wù)端需要的大體組件。

Jaeger Client - 就是上面我們所談的
Agent - 監(jiān)聽在 UDP 端口上接收 span 數(shù)據(jù)的網(wǎng)絡(luò)守護(hù)進(jìn)程，它會將數(shù)據(jù)批量發(fā)送給 collector
Collector - 接收 jaeger-agent 發(fā)送來的數(shù)據(jù)，然后將數(shù)據(jù)寫入后端存儲。
Data Store - 后端存儲被設(shè)計(jì)成一個可插拔的組件，支持將數(shù)據(jù)寫入 cassandra、ES
Query - 接收查詢請求，然后從后端存儲系統(tǒng)中檢索 trace 并通過 UI 進(jìn)行展示

是的，典型的無狀態(tài)系統(tǒng)，對等節(jié)點(diǎn)當(dāng)機(jī)無影響。

上面的狀態(tài)圖不止一次提到流計(jì)算，這也不用非要整個Spark Streaming，從kafka接收一份數(shù)據(jù)自己處理也叫流計(jì)算，選用最新的kafka stream也是不從的選擇。重要的是聚合聚合聚合，重要的事情說三遍。

一般，算一些QPS，RT等，也就是純粹的計(jì)數(shù)；或者斜率，也就是增長下降速度；復(fù)雜點(diǎn)的有TP值（有百分之多少的請求在XX秒內(nèi)相應(yīng)），還有調(diào)用鏈的服務(wù)拓?fù)鋱D、日志異常的統(tǒng)計(jì)，都可以在這里進(jìn)行計(jì)算。

幸運(yùn)的是，流計(jì)算的API都比較簡單，就是調(diào)試比較費(fèi)勁。

分析后的數(shù)據(jù)屬于加工數(shù)據(jù)，是要分開存儲的，當(dāng)然量小的話，也可以和原始數(shù)據(jù)混在一起。分析后的數(shù)據(jù)量是可評估的，比如5秒一條數(shù)據(jù)，一天就固定的17280條，預(yù)警模塊讀的是分析后的數(shù)據(jù)（原始數(shù)據(jù)太大了），也會涉及大量的計(jì)算。

那么分析后的統(tǒng)計(jì)數(shù)據(jù)用來干什么用呢？一部分就是預(yù)警；另一部分就是展示。

拿我設(shè)計(jì)的一個原型來看，對一個metric的操作大體有以下內(nèi)容：

? 在時間間隔內(nèi)，某監(jiān)控項(xiàng)觸發(fā)閾值XX次
? 觸發(fā)動作有：大于、小于、平均值大于、平均值小于、環(huán)比大于、環(huán)比小于、同比大于、同比小于、自定義表達(dá)式等
? 閾值為數(shù)字?jǐn)?shù)組，支持多監(jiān)控項(xiàng)相互作用
? 級別一般根據(jù)公司文化進(jìn)行劃分，6層足夠了
? 聚合配置用來表明是閾值觸發(fā)還是聚合觸發(fā)，比如在時間跨度5分鐘內(nèi)發(fā)生5次，才算是處罰
? 報(bào)警觸發(fā)后，會發(fā)郵件、打電話、發(fā)短信、發(fā)webhook等

僅做參考，這只是配置的冰山一角。要把各種出發(fā)動作做一遍，你是要浪費(fèi)很多腦細(xì)胞的。

有很多可視化js庫，但工作量一般都很大。但沒辦法，簡單的用grafana配置一下就可以了，復(fù)雜點(diǎn)的還需要親自操刀。我這里有兩張簡單的grafana圖，可以參考一下。

[系統(tǒng)監(jiān)控]

[jvm監(jiān)控一部分]

整體來說，整個體系就是收集、處理、應(yīng)用這大三類數(shù)據(jù)（logs、metrics、trace）。其中有些組件的經(jīng)驗(yàn)可以共用，但收集部分和應(yīng)用部分相差很大。我嘗試總結(jié)了一張圖，但從中只能看到有哪些組件參與，只看圖是臨摹兩可的。具體的數(shù)據(jù)流轉(zhuǎn)和處理，每種結(jié)構(gòu)都不盡相同，這也是為什么我一直強(qiáng)調(diào)分而治之的原因。但使用方式上，最好相差不要太大。無論后端的架構(gòu)如何復(fù)雜，一個整體的外觀將讓產(chǎn)品變得更加清晰，你目前的工作，是不是也集中在此處呢？

通過了解上面的內(nèi)容，可以了解到我們習(xí)慣性的將監(jiān)控系統(tǒng)所有的模塊進(jìn)行了拆解，你可以很容易的對其中的組件進(jìn)行替換。比如beat替換flume、cassandra替換ES...

下面我將列出一些常用的組件，如有遺漏，歡迎補(bǔ)充。

用來收集監(jiān)控項(xiàng)，influxdata家族的一員，是一個用Go編寫的代理程序,可收集系統(tǒng)和服務(wù)的統(tǒng)計(jì)數(shù)據(jù),并寫入到多種數(shù)據(jù)庫。支持的類型可謂非常廣泛。

主要用來收集日志類數(shù)據(jù)，apache家族。Flume-og和Flume-ng版本相差很大。是一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。

Logstash是一個開源的日志收集管理工具，elastic家族成員。功能和flume類似，但占用資源非常的貪婪，建議使用時獨(dú)立部署。功能豐富，支持ruby定義過濾條件。

node開發(fā)，使用udp協(xié)議傳輸，專門用來收集數(shù)據(jù)，收集完數(shù)據(jù)就發(fā)送到其他服務(wù)器進(jìn)行處理。與telegraf類似。

collectd是一個守護(hù)(daemon)進(jìn)程，用來定期收集系統(tǒng)和應(yīng)用程序的性能指標(biāo)，同時提供了機(jī)制，以不同的方式來存儲這些指標(biāo)值。

獨(dú)立的可視化組件比較少，不過解決方案里一般都帶一個web端，像grafana這么專注的，不太多。

專注展示，顏值很高，集成了非常豐富的數(shù)據(jù)源。通過簡單的配置，即可得到非常專業(yè)的監(jiān)控圖。

有很多用的很少的，可以看這里：
https://grafana.com/plugins?type=datasource

influx家族產(chǎn)品。Influxdb是一個開源的分布式時序、時間和指標(biāo)數(shù)據(jù)庫，使用go語言編寫，無需外部依賴。支持的數(shù)據(jù)類型非常豐富，性能也很高。單節(jié)點(diǎn)使用時不收費(fèi)的，但其集群要收費(fèi)。

OpenTSDB是一個時間序列數(shù)據(jù)庫。它其實(shí)并不是一個db，多帶帶一個OpenTSDB無法存儲任何數(shù)據(jù)，它只是一層數(shù)據(jù)讀寫的服務(wù)，更準(zhǔn)確的說它只是建立在Hbase上的一層數(shù)據(jù)讀寫服務(wù)。能夠承受海量的分布式數(shù)據(jù)。

能夠存儲監(jiān)控項(xiàng)，也能夠存儲log，trace的關(guān)系也能夠存儲。支持豐富的聚合函數(shù)，能夠?qū)崿F(xiàn)非常復(fù)雜的功能。但時間跨度太大的話，設(shè)計(jì)的索引和分片過多，ES容易懵逼。

小米出品，它其實(shí)包含了agent、處理、存儲等模塊，并有自己的dashboard，算是一個解決方案，贊一下。但目前用的較少，而且國內(nèi)開源的東西尿性你也知道：公司內(nèi)吹的高大上，社區(qū)用的卻是半成品。

Graphite并不收集度量數(shù)據(jù)本身，而是像一個數(shù)據(jù)庫，通過其后端接收度量數(shù)據(jù)，然后以實(shí)時方式查詢、轉(zhuǎn)換、組合這些度量數(shù)據(jù)。Graphite支持內(nèi)建的Web界面，它允許用戶瀏覽度量數(shù)據(jù)和圖。最近發(fā)展很不錯，經(jīng)常和Collectd進(jìn)行配對。grafana也默認(rèn)集成其為數(shù)據(jù)源。

golang開發(fā)，發(fā)展態(tài)勢良好。它啟發(fā)于 Google 的 borgmon 監(jiān)控系統(tǒng)，2015才正式發(fā)布，比較年輕。prometheus目標(biāo)宏大，從其名字就可以看出來--普羅米修斯。另外，SpringCloud對它的支持也很好。

圖形還停留在使用AWT或者GD渲染上。總感覺這些東東處在淘汰的邊緣呢。

使用占比特別大，大到我不需要做過多介紹。但隨著節(jié)點(diǎn)的增多和服務(wù)的增多，大概在1k左右，你就會遇到瓶頸（包括開發(fā)定制瓶頸）。整體來說，小公司用的很爽，大公司用的很雞肋。

也算是比較古老了，時間久客戶多。其安裝配置相對較為復(fù)雜。功能不全較專一，個人不是很喜歡。

Ganglia的核心包含gmond、gmetad以及一個Web前端。主要是用來監(jiān)控系統(tǒng)性能，如：cpu 、mem、硬盤利用率， I/O負(fù)載、網(wǎng)絡(luò)流量情況等，通過曲線很容易見到每個節(jié)點(diǎn)的工作狀態(tài)，對合理調(diào)整、分配系統(tǒng)資源，提高系統(tǒng)整體性能起到重要作用。

這可是老掉牙了，和nagios配合的天衣無縫。你還在用么？

APM算是其中比較特殊的一個領(lǐng)域，也有很多實(shí)現(xiàn)。
附：支持OpenTracing的APM列表

其實(shí)美團(tuán)的東西非常少，大部分拿點(diǎn)評的來充門面。CAT作為美團(tuán)點(diǎn)評基礎(chǔ)監(jiān)控組件，它已經(jīng)在中間件框架（MVC框架，RPC框架，數(shù)據(jù)庫框架，緩存框架等）中得到廣泛應(yīng)用，為美團(tuán)點(diǎn)評各業(yè)務(wù)線提供系統(tǒng)的性能指標(biāo)、健康狀況、基礎(chǔ)告警等。
算是比較良心了，但侵入性很大，如果你的代碼量龐大就是噩夢。技術(shù)實(shí)現(xiàn)比較老，但控制力強(qiáng)。

pinpoint是開源在github上的一款A(yù)PM監(jiān)控工具，它是用Java編寫的，用于大規(guī)模分布式系統(tǒng)監(jiān)控。安裝agent是無侵入式的，也就是用了java的instrument技術(shù)，注定了是java系的。

帶有華為標(biāo)簽，和pinpoint類似，使用探針收集數(shù)據(jù)，2015年作品，使用ES作為存儲。進(jìn)入Apache了哦，支持Opentracing。

哦，zipkin也是走的這條路，但zipkin支持opentracing協(xié)議，這樣，你用的不爽可以替換它，非常大度。

golang開發(fā)，Uber產(chǎn)品，小巧玲瓏，支持OpenTracing協(xié)議。它的Web端也非常漂亮，提供ES和Cassandra的后端存儲。

這里提一個唯一收費(fèi)的解決方案。為什么呢？因?yàn)樗龅暮芷痢ｎ佒悼兀瑳]辦法。另外，還良心的寫了很多具體實(shí)現(xiàn)的代碼和文檔，質(zhì)量很高。你要自己開發(fā)一套的話，不妨一讀。

監(jiān)控體系的復(fù)雜之處就在于雜，如何理清其中的關(guān)系，給用戶一個合理的思考模式，才是最重要的，此所謂產(chǎn)品體驗(yàn)優(yōu)先。從整個的發(fā)展歷程中可以看到，標(biāo)準(zhǔn)化是對技術(shù)最好的改進(jìn)，但也要經(jīng)歷一個群魔亂舞的年代。既得利益者會維護(hù)自己的壁壘，拒絕接納和開放，然后猛然間發(fā)現(xiàn)，自己的東西已經(jīng)落伍，跟不上時代的腳步了。