背景
因為公司的RPC框架不支持HTTP的服務(wù)端,所以無法在服務(wù)管理平臺實現(xiàn)基于HTTP的RPC調(diào)用的服務(wù)可視化治理,所以樓主基于現(xiàn)有的框架實現(xiàn)了一套自己的服務(wù)集群監(jiān)控,因為本身框架不一定適應(yīng)業(yè)務(wù),所以樓主重寫了框架里的個別類,具體后面會講.
技術(shù)引進:
Metrics(vertx的開源子項目的一個分支,是天然的監(jiān)控框架,本文核心也圍繞這個展開)
Flume(日志采集工具,將日志落服務(wù)器,然后通過flume采集)
Kafka(現(xiàn)主流的消息中間件,這里不作復(fù)述,這里用到消費flume里面的日志)
ElasticSearch(基于Lucene的搜索服務(wù)器,因為樓主不是主要做索引,只是入門級別,基于es做了一個可視化的平臺)
整體架構(gòu)組成 :Metrics+Flume+kafka+ElasticSearch
Metrics
引用官網(wǎng)的介紹:作為一款監(jiān)控指標(biāo)的度量類庫魁瞪，它提供了很多模塊可以為第三方庫或者應(yīng)用提供輔助統(tǒng)計信息讽挟， Metrics提供了Gauge、Counter、Meter我纪、Histogram、Timer等度量工具類以及Health Check功能。(樓主本次因為業(yè)務(wù)的適應(yīng),本次用Meter和Timer)
Metrics提供了多種類型的
Meter:
用來計算事件的速率。 例如 request per second第焰。 還可以提供1分鐘，5分鐘妨马，15分鐘不斷更新的平均速率(具體打什么時間,可以重寫,樓主自己就重寫了),因為這里meter已經(jīng)提供了統(tǒng)計次數(shù)的,所以如果統(tǒng)計一額接口的統(tǒng)計成功數(shù),可以直接用這個,而不需要用counter那個度量類.
下圖是官方的Demo:
通俗的講:
舉個的例子,我想統(tǒng)計請求的次數(shù),我只需要在調(diào)用方法后,調(diào)用meter的mark方法即可埋點.這個時候,就會在這次調(diào)用,使用后計數(shù)器加一,有些人說,我自己每次調(diào)用打一行日志也可以啊,但是!因為你如果是同步實時的打日志,在qps上萬的情況下,你會發(fā)現(xiàn)你打日志的線程也占用了你資源,而且這樣每次請求打一次,你會發(fā)現(xiàn),你的磁盤也會出現(xiàn)瓶頸,當(dāng)然,你也會說,我可以用log4j2采用異步打日志,如果你用過異步日志的時候,你會發(fā)現(xiàn)日志是隔一段時間打一次,而且當(dāng)你清空日志的時候,還是會出現(xiàn)磁盤的阻塞.而Metics的打日志的時候,你可以完全自己設(shè)置打印時間,譬如30秒一次或者幾分鐘一次一樣可以記錄這時間段的服務(wù)情況.
現(xiàn)在是樓主自己的demo:
可以看出來,只要拋出一次,我在這調(diào)用這個mark方法,這個時候,metrics會自動統(tǒng)計你的失敗次數(shù),并在你設(shè)置的時間內(nèi)打出來,因為樓主重寫了他的log方式,方便es可視化,所以這里的日志是我的格式:
可以看出這個接口的名字,以及一天的總失敗數(shù),下圖是一個失敗次數(shù)的可視化展示,另外樓主還對一次RPC調(diào)用返回的結(jié)果集合也做了統(tǒng)計,這里就不截圖了.
最后將服務(wù)器上的日志,flume進行日志采集,通過kafka配置topic消費到ES中,可視化后的結(jié)果如下:
Timer 計時器
Timer是一個Meter和Histogram的組合挺举。這個度量單位可以比較方便地統(tǒng)計請求的速率和處理時間。對于接口中調(diào)用的延遲等信息的統(tǒng)計就比較方便了烘跺。如果發(fā)現(xiàn)一個方法的RPS（請求速率）很低湘纵，而且平均的處理時間很長，那么這個方法八成出問題了滤淳。
同樣梧喷，通這是里官方的一個Demo:
上圖中注釋的地方就是你自己寫的邏輯,譬如一次方法調(diào)用:
這里是樓主的自己業(yè)務(wù)的調(diào)用Demo:
可以看到我每一次http的調(diào)用后,通過Timer的context進行埋點統(tǒng)計,這個就會記錄,下圖的數(shù)據(jù),這里用網(wǎng)上的圖,因為我自己重寫了圖2;
可以看到這里統(tǒng)計了調(diào)用次數(shù),最大,最小的次數(shù),以及平均數(shù),中位數(shù),以及TP75-TP99的時間.因為需要基于elasticSearch消費日志,所以樓主重寫了那個report的類,如下:
下面是樓主重寫的的上報類,里面可以支持傳參數(shù),以及你自己想要格式:
在日志中的表示如下:
最后同樣把日志落FLume,通過kafka配置topic消費,如ES,可是化后的如下圖:
可以看到這里是可視化的監(jiān)控,可以看服務(wù)的tp98的實時情況,當(dāng)然可以根據(jù)自己的喜歡配置TP99,TP95的情況.
基于其他類型,樓主沒有做過多的研究,直接引用官方的Demo:
這個Gaugets最簡單的度量指標(biāo)，只有一個簡單的返回值.比如娇钱，我們類型為Gauge的計數(shù)器來記錄某個服務(wù)目前開通的城市個數(shù)
Metric.Gauge("Service Cities Count", () => Cities.Count, new Unit("個"));
Histogram?
Histogram直方圖是一種非常常見的統(tǒng)計圖表伤柄，Metrics通過這個Histogram這個度量類型提供了一些方便實時繪制直方圖.因為Timer已經(jīng)集成了Histogram,而且兩者的輸出結(jié)果基本一致,而且Timer能返回一定的時間段,所以這里不作復(fù)述,個人可以根據(jù)喜好使用,為了形象,這里引用一個網(wǎng)上一個被copy了無數(shù)次的列子(也不知道真正的作者是誰)
最后是初始化Meterics的Demo,這里的LmAsReport就是樓主自己重寫的那個上報的類
另外下面是官方的Demo:
另外該框架還支持了其他類型的上報,譬如控制臺,因為實際中我們大多數(shù)都是通過日志,所以這里不做其他類型的演示了.
附:對于框架的上報方法,可以自己進行重寫,可以加上自己想要傳遞的參數(shù),可以自行實現(xiàn),因為本來框架源碼就不多,所以可以進行自己修改重寫.(樓主自己重寫的類后續(xù)會傳到gitbub)
因為也是第一次接觸,所以后續(xù)會繼續(xù)改進,另外也會進行自己的重寫一些框架里的類目.相比這個框架也不陌生,如果上述有說錯的地方,歡迎指正,一起學(xué)習(xí).
