這麼多監控組件，總有一款適合你

時間 2019-11-06

標籤監控組件總有一款適合简体版

原文原文鏈接

更多精彩文章。前端

《微服務不是所有，只是特定領域的子集》java

《「分庫分表" ？選型和流程要慎重，不然會失控》node

這麼多監控組件，總有一款適合你ios

《使用Netty，咱們到底在開發些什麼？》nginx

《這多是最中肯的Redis規範了》git

《程序員畫像，十年沉浮》程序員

最有用系列：github

《Linux生產環境上，最經常使用的一套「vim「技巧》golang

《Linux生產環境上，最經常使用的一套「Sed「技巧》web

《Linux生產環境上，最經常使用的一套「AWK「技巧》

監控是分佈式系統的必備組件，可以起到提早預警、問題排查、評估決策等功效，乃行走江湖、居家必備之良品。

監控系統概要

功能劃分

一個宿主機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收集器便可。

哈！又繞回去了。

Tracing

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

Google 的論文「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」開啓了調用鏈的流行。後續能夠說是百家齊放，直到近幾年纔出現了OpenTracing這樣的標準。

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

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

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

值得一提的是，SpringCloud對它的支持仍是比較全面的（ github.com/opentracing…），但依賴關係和版本搞的很是混亂。建議參考後本身開發，大致使用"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...

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

數據收集組件

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

專一展現，顏值很高，集成了很是豐富的數據源。經過簡單的配置，便可獲得很是專業的監控圖。

存儲

有不少用的不多的，能夠看這裏： grafana.com/plugins?typ…

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框架，數據庫框架，緩存框架等）中獲得普遍應用，爲美團點評各業務線提供系統的性能指標、健康情況、基礎告警等。算是比較良心了，但侵入性很大，若是你的代碼量龐大就是噩夢。技術實現比較老，但控制力強。