1. 需求說(shuō)明：

在微服務(wù)越來(lái)越流行的趨勢(shì)下，系統(tǒng)之間的調(diào)用日趨復(fù)雜。一次請(qǐng)求可能會(huì)調(diào)用多個(gè)服務(wù)。如果一次請(qǐng)求掛了，或者響應(yīng)很慢，往往難以發(fā)現(xiàn)問(wèn)題出在哪個(gè)服務(wù)上，也難以查看請(qǐng)求的耗時(shí)。鏈路監(jiān)控的目的就是將一次請(qǐng)求的服務(wù)調(diào)用情況記錄下來(lái)，這次請(qǐng)求調(diào)用了哪些服務(wù)（服務(wù)依賴），耗時(shí)多少。在此基礎(chǔ)上，如果發(fā)現(xiàn)請(qǐng)求失敗，會(huì)郵件通知管理員（預(yù)警功能）。所以，鏈路監(jiān)控包含監(jiān)控功能，預(yù)警功能。

2. 項(xiàng)目框架

基于推特開(kāi)源的open zipkin（https://github.com/openzipkin：發(fā)現(xiàn)要遷移到apache了）。因?yàn)橐傻絻蓚€(gè)系統(tǒng)，本想在各個(gè)系統(tǒng)創(chuàng)建單獨(dú)的maven module，單獨(dú)創(chuàng)建一個(gè)工程，開(kāi)發(fā)一個(gè)公共組件更符合代碼復(fù)用，開(kāi)閉原則。其他系統(tǒng)只需要引入這個(gè)公共組件，添加一些額外配置，比如采樣率，kafka的server地址等，也要稍微改一下代碼，就有了鏈路監(jiān)控的功能了。

該項(xiàng)目采用zipkin提供的brave工具庫(kù)采集監(jiān)控?cái)?shù)據(jù)，并發(fā)送到kafka。有兩個(gè)消費(fèi)者消費(fèi)kafka。一個(gè)是Zipkin UI（用于展示鏈路信息的Web管理界面），它從kafka拿到數(shù)據(jù)后，存儲(chǔ)到Elastic Search；另一個(gè)是Storm實(shí)時(shí)流處理平臺(tái)，它解析監(jiān)控?cái)?shù)據(jù)，如果發(fā)現(xiàn)調(diào)用異常會(huì)發(fā)送郵件給用戶（重復(fù)預(yù)警郵件會(huì)通過(guò)mongodb和guava本地緩存過(guò)濾掉）。

3. 項(xiàng)目遇到的難點(diǎn)

3.1 鏈路監(jiān)控

監(jiān)控信息增加響應(yīng)頭的信息：response.size;

公共組件用低版本的jdk打包；

監(jiān)控信息增加post請(qǐng)求的body（修改源碼的方式);

支持收集httpclient，restTemplate，MySQL的監(jiān)控信息；

通過(guò)重寫(xiě)TracingStatementInterceptor的方式過(guò)濾掉一些沒(méi)有必要的SQL，比如'SET autocommit=0'。zipkin提供的brave-instrumentation-mysql收集了太多冗余的sql。

3.2 storm實(shí)時(shí)流處理

一條鏈路上如果有一個(gè)調(diào)用出現(xiàn)問(wèn)題，可能會(huì)發(fā)送多封郵件。解決方法：將同一條鏈路上的監(jiān)控信息都發(fā)送到同一個(gè)bolt，用本地緩存保存已發(fā)送郵件的trace id；

增加MySQL慢查詢的監(jiān)控；

配置文件的初始化未生效的問(wèn)題。因?yàn)榉植际降脑颍渲梦募某跏蓟趖opology里，其他bolt是取不到的；