監控是分布式系統的必備元件，能夠起到提前預警、問題排查、評估決策等功效，乃行走江湖、居家必備之良品。
監控系統概要
功能劃分
一個主控端
cpu
的報警叫做監控；一個業務日志的報錯叫做監控；一個
APM
條件的觸發，也叫做監控。分布式系統錯綜複雜，随便做個統計名額的集合，也屬于監控的範疇。怎樣做到通用化，理清其中的關系，是需要花點功夫的，否則揉成一團，就不好拆了。
我習慣性從以下兩種類型對其進行劃分，真正實施起來，系統還是按照資料象限分比較合理：
資料象限 從資料類型劃分，大體可分為：日志（
logs
）、監控(
metrics
)、調用鍊(
tracing
)。
功能象限 從業務角度劃分，可分為：基礎監控、中間件監控、業務監控
不管什麼樣的監控系統，又涉及以下幾個子產品過程：
❏ 資料收集。如何在廣度和效率上進行資料歸并。
❏ 資料加工。資料的整理、傳輸和存儲。
❏ 特稱提取。大資料計算，中間結果生成存儲。
❏ 資料展示。高顔值、多功能顯示。
其中，特征提取隻有資料量達到一定程度才會開啟，因為它的開發和運維成本一般小公司是不會玩的。
典型實作
不同的監控子產品，側重于不同領域，有着不同的職責。我個人是傾向于 獨立設計 的，但需要做一定程度的內建，主要還是使用方式上的內建和優化。
我将從幾個典型解決方案說起，來說一下為什麼要分開設計，而不是揉成一團。
系統監控
系統監控用來收集主控端的監控狀況（網絡、記憶體、CPU、磁盤、核心等），包括大部分資料庫和中間件的敏感名額。這些
metric
的典型特點是結構固定、有限名額項，使用時序資料庫進行存儲是最合适的。
名額收集方面，支援多樣化的元件将被優先下使用。比如
telegraf
，支援所有的系統名額收集和大部分中間件和DB的名額收集。
在這裡特别推薦一下其中的 jolokia2
名額收集以後，強烈建議使用
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收集器
即可。
哈！又繞回去了。
Tracing
相比較普通監控和日志，調用鍊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）。其中有些元件的經驗可以共用，但收集部分和應用部分相差很大。我嘗試總結了一張圖，但從中隻能看到有哪些元件參與，隻看圖是臨摹兩可的。具體的資料流轉和處理，每種結構都不盡相同，這也是為什麼我一直強調分而治之的原因。但使用方式上，最好相差不要太大。無論後端的架構如何複雜，一個整體的外觀将讓産品變得更加清晰，你目前的工作，是不是也集中在此處呢？
一些元件
通過了解上面的内容，可以了解到我們習慣性的将監控系統所有的子產品進行了拆解，你可以很容易的對其中的元件進行替換。比如beats替換flume、cassandra替換ES…
下面我将列出一些常用的元件，如有遺漏，歡迎補充。
資料收集元件
telegraf
用來收集監控項，influxdata家族的一員，是一個用Go編寫的代理程式,可收集系統和服務的統計資料,并寫入到多種資料庫。支援的類型可謂非常廣泛。
flume
主要用來收集日志類資料，apache家族。Flume-og和Flume-ng版本相差很大。是一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸的系統，Flume支援在日志系統中定制各類資料發送方，用于收集資料；同時，Flume提供對資料進行簡單處理，并寫到各種資料接受方（可定制）的能力。
logstash
Logstash是一個開源的日志收集管理工具，elastic家族成員。功能和flume類似，但占用資源非常的貪婪，建議使用時獨立部署。功能豐富，支援ruby定義過濾條件。
StatsD
node開發，使用udp協定傳輸，專門用來收集資料，收集完資料就發送到其他伺服器進行處理。與telegraf類似。
CollectD
collectd是一個守護(daemon)程序，用來定期收集系統和應用程式的性能名額，同時提供了機制，以不同的方式來存儲這些名額值。
可視化
獨立的可視化元件比較少，不過解決方案裡一般都帶一個web端，像grafana這麼專注的，不太多。
grafana
專注展示，顔值很高，內建了非常豐富的資料源。通過簡單的配置，即可得到非常專業的監控圖。
存儲
有很多用的很少的，可以看這裡：
https://grafana.com/plugins?type=datasource
influxdb
influx家族産品。Influxdb是一個開源的分布式時序、時間和名額資料庫，使用go語言編寫，無需外部依賴。支援的資料類型非常豐富，性能也很高。單節點使用時不收費的，但其叢集要收費。
opentsdb
OpenTSDB是一個時間序列資料庫。它其實并不是一個db，單獨一個OpenTSDB無法存儲任何資料，它隻是一層資料讀寫的服務，更準确的說它隻是建立在Hbase上的一層資料讀寫服務。能夠承受海量的分布式資料。
elasticsearch
能夠存儲監控項，也能夠存儲log，trace的關系也能夠存儲。支援豐富的聚合函數，能夠實作非常複雜的功能。但時間跨度太大的話，涉及的索引和分片過多，ES容易懵逼。
解決方案
open-falcon
小米出品，它其實包含了agent、處理、存儲等子產品，并有自己的dashboard，算是一個解決方案，贊一下。但目前用的較少，而且國内開源的東西尿性你也知道：公司内吹的高大上，社群用的卻是半成品。
Graphite
Graphite并不收集度量資料本身，而是像一個資料庫，通過其後端接收度量資料，然後以實時方式查詢、轉換、組合這些度量資料。Graphite支援内建的Web界面，它允許使用者浏覽度量資料和圖。最近發展很不錯，經常和Collectd進行配對。grafana也預設內建其為資料源。
prometheus
golang開發，發展态勢良好。它啟發于 Google 的 borgmon 監控系統，2015才正式釋出，比較年輕。prometheus目标宏大，從其名字就可以看出來—普羅米修斯。另外，SpringCloud對它的支援也很好。
傳統監控
圖形還停留在使用AWT或者GD渲染上。總感覺這些東東處在淘汰的邊緣呢。
zabbix
使用占比特别大，大到我不需要做過多介紹。但随着節點的增多和服務的增多，大概在1k左右，你就會遇到瓶頸（包括開發定制瓶頸）。整體來說，小公司用的很爽，大公司用的很雞肋。
nagios
也算是比較古老了，時間久客戶多。其安裝配置相對較為複雜。功能不全較專一，個人不是很喜歡。
ganglia
Ganglia的核心包含gmond、gmetad以及一個Web前端。主要是用來監控系統性能，如：cpu 、mem、硬碟使用率， I/O負載、網絡流量情況等，通過曲線很容易見到每個節點的工作狀态，對合理調整、配置設定系統資源，提高系統整體性能起到重要作用。
Centreon
這可是老掉牙了，和nagios配合的天衣無縫。你還在用麼？
APM
APM算是其中比較特殊的一個領域，也有很多實作。
附：支援OpenTracing的APM清單
cat
CAT作為美團點評基礎監控元件，它已經在中間件架構（MVC架構，RPC架構，資料庫架構，緩存架構等）中得到廣泛應用，為美團點評各業務線提供系統的性能名額、健康狀況、基礎告警等。
算是比較良心了，但侵入性很大，如果你的代碼量龐大就是噩夢。技術實作比較老，但控制力強。
Pinpoint
pinpoint是開源在github上的一款APM監控工具，它是用Java編寫的，用于大規模分布式系統監控。安裝agent是無侵入式的，也就是用了java的instrument技術，注定了是java系的。
SkyWalking
帶有華為标簽，和pinpoint類似，使用探針收集資料，2015年作品，使用ES作為存儲。進入Apache了哦，支援Opentracing。
zipkin
哦，zipkin也是走的這條路，但zipkin支援opentracing協定，這樣，你用的不爽可以替換它，非常大度。
jaeger
golang開發，Uber産品，小巧玲珑，支援OpenTracing協定。它的Web端也非常漂亮，提供ES和Cassandra的後端存儲。
其他
Datadog
這裡提一個唯一收費的解決方案。為什麼呢？因為它做的很漂亮。顔值控，沒辦法。另外，還良心的寫了很多具體實作的代碼和文檔，品質很高。你要自己開發一套的話，不妨一讀。
監控體系的複雜之處就在于雜，如何理清其中的關系，給使用者一個合理的思考模式，才是最重要的，此所謂産品體驗優先。從整個的發展曆程中可以看到，标準化是對技術最好的改進，但也要經曆一個群魔亂舞的年代。既得利益者會維護自己的壁壘，拒絕接納和開放，然後猛然間發現，自己的東西已經落伍，跟不上時代的腳步了。
那為什麼還要到大會上吹噓呢？