摘要：典型實現不同的監控模塊，側重于不同領域，有著不同的職責。指標收集方面，支持多樣化的組件將被優先下使用。以上談了這么多，僅僅是聊了一下收集方面而已。

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

一個宿主機cpu的報警叫做監控；一個業務日志的報錯叫做監控；一個APM條件的觸發，也叫做監控。分布式系統錯綜復雜，隨便做個統計指標的集合，也屬于監控的范疇。怎樣做到通用化，理清其中的關系，是需要花點功夫的，否則揉成一團，就不好拆了。

我習慣性從以下兩種類型對其進行劃分，真正實施起來，系統還是按照數據象限分比較合理：
數據象限 從數據類型劃分，大體可分為：日志（logs）、監控(metrics)、調用鏈(tracing)。
功能象限 從業務角度劃分，可分為：基礎監控、中間件監控、業務監控

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

其中，特征提取只有數據量達到一定程度才會開啟，因為它的開發和運維成本一般小公司是不會玩的。

不同的監控模塊，側重于不同領域，有著不同的職責。我個人是傾向于 獨立設計 的，但需要做一定程度的集成，主要還是使用方式上的集成和優化。

我將從幾個典型解決方案說起，來說一下為什么要分開設計，而不是揉成一團。

系統監控用來收集宿主機的監控狀況（網絡、內存、CPU、磁盤、內核等），包括大部分數據庫和中間件的敏感指標。這些metric的典型特點是結構固定、有限指標項，使用時序數據庫進行存儲是最合適的。

指標收集方面，支持多樣化的組件將被優先下使用。比如telegraf，支持所有的系統指標收集和大部分中間件和DB的指標收集。

在這里特別推薦一下其中的jolokia2組件，可以很容易的實現JVM監控等功能。

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

指標進入消息隊列后，一份拷貝將會通過logstash的過濾和整理入庫ES等NoSQL；另外一份拷貝，會經過流計算，統計一些指標（如QPS、平均相應時間、TP值等）。

可以有多種途徑計算觸發報警的聚合計算。回查、疊加統計都是常用的手段。在數據量特別大的情況下，先對指標數據進行預處理是必備的，否則，再牛的DB如influxdb也承受不住。

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

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

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

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

可以看到和系統監控的構造其實是差不多的，很多組件可以重用。區別就是數據量大，往往一不小心就把帶寬占滿了。日志的特點就是量大無規則（nginx算是良民了），SLA要求不會太高。

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

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

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

那么怎么過濾業務日志的錯誤情況呢，比如有多少XXX異常觸發報警。這種情況下可以寫腳本，也可以接一份數據進行處理，然后生成監控項，拋給metrics收集器即可。

哈！又繞回去了。

相比較普通監控和日志，調用鏈APM等就復雜的多了。除了有大量的數據產生源，也要有相應的業務組件來支持調用鏈聚合和展示。其功能展示雖然簡單，但卻是監控體系里最復雜的模塊。

Google 的論文
“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”
開啟了調用鏈的流行。后續可以說是百家齊放，直到近幾年才出現了OpenTracing這樣的標準。

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

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

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

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

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

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

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

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

是的，典型的無狀態系統，對等節點當機無影響。

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

一般，算一些QPS，RT等，也就是純粹的計數；或者斜率，也就是增長下降速度；復雜點的有TP值（有百分之多少的請求在XX秒內相應），還有調用鏈的服務拓撲圖、日志異常的統計，都可以在這里進行計算。

幸運的是，流計算的API都比較簡單，就是調試比較費勁。

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

那么分析后的統計數據用來干什么用呢？一部分就是預警；另一部分就是展示。

拿我設計的一個原型來看，對一個metric的操作大體有以下內容：

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

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

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

[系統監控]

[jvm監控一部分]

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

通過了解上面的內容，可以了解到我們習慣性的將監控系統所有的模塊進行了拆解，你可以很容易的對其中的組件進行替換。比如beat替換flume、cassandra替換ES...

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

用來收集監控項，influxdata家族的一員，是一個用Go編寫的代理程序,可收集系統和服務的統計數據,并寫入到多種數據庫。支持的類型可謂非常廣泛。

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

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

node開發，使用udp協議傳輸，專門用來收集數據，收集完數據就發送到其他服務器進行處理。與telegraf類似。

collectd是一個守護(daemon)進程，用來定期收集系統和應用程序的性能指標，同時提供了機制，以不同的方式來存儲這些指標值。

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

專注展示，顏值很高，集成了非常豐富的數據源。通過簡單的配置，即可得到非常專業的監控圖。

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

influx家族產品。Influxdb是一個開源的分布式時序、時間和指標數據庫，使用go語言編寫，無需外部依賴。支持的數據類型非常豐富，性能也很高。單節點使用時不收費的，但其集群要收費。

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

能夠存儲監控項，也能夠存儲log，trace的關系也能夠存儲。支持豐富的聚合函數，能夠實現非常復雜的功能。但時間跨度太大的話，設計的索引和分片過多，ES容易懵逼。

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

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

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

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

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

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

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

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

APM算是其中比較特殊的一個領域，也有很多實現。
附：支持OpenTracing的APM列表

其實美團的東西非常少，大部分拿點評的來充門面。CAT作為美團點評基礎監控組件，它已經在中間件框架（MVC框架，RPC框架，數據庫框架，緩存框架等）中得到廣泛應用，為美團點評各業務線提供系統的性能指標、健康狀況、基礎告警等。
算是比較良心了，但侵入性很大，如果你的代碼量龐大就是噩夢。技術實現比較老，但控制力強。

pinpoint是開源在github上的一款APM監控工具，它是用Java編寫的，用于大規模分布式系統監控。安裝agent是無侵入式的，也就是用了java的instrument技術，注定了是java系的。

帶有華為標簽，和pinpoint類似，使用探針收集數據，2015年作品，使用ES作為存儲。進入Apache了哦，支持Opentracing。

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

golang開發，Uber產品，小巧玲瓏，支持OpenTracing協議。它的Web端也非常漂亮，提供ES和Cassandra的后端存儲。

這里提一個唯一收費的解決方案。為什么呢？因為它做的很漂亮。顏值控，沒辦法。另外，還良心的寫了很多具體實現的代碼和文檔，質量很高。你要自己開發一套的話，不妨一讀。

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