? ? 微服務監(jiān)控領域吏夯，Tracing借助Metrics，可以在APM方面為開發(fā)運維人員提供更大幫助即横。本文采用Elastic APM和Grafana作為技術方案噪生，分享借助Metrics對Tracing數(shù)據(jù)進行統(tǒng)計、分析與可視化东囚，助力開發(fā)運維更高效跺嗽。
1.??微服務Tracing與Metrics
1.1.微服務監(jiān)控三個領域:Tracing、Logging和Metrics
在微服務領域，很早以來就形成了Tracing桨嫁、Logging和Metrics相輔相成植兰，合力支撐多維度、多形態(tài)的監(jiān)控體系璃吧。
三類監(jiān)控各有側重：
2?Tracing：楣导，它在單次請求的范圍內(nèi)，處理信息畜挨。?任何的數(shù)據(jù)筒繁、元數(shù)據(jù)信息都被綁定到系統(tǒng)中的單個事務上。例如：一次調(diào)用遠程服務的RPC執(zhí)行過程朦促；一次實際的SQL查詢語句膝晾；一次HTTP請求的業(yè)務性ID；
2?Logging：它描述一些離散的（不連續(xù)的）事件务冕。?例如：應用通過一個滾動的文件輸出debug或error信息血当，并通過日志收集系統(tǒng)，存儲到Elasticsearch中禀忆；?審批明細信息通過Kafka臊旭，存儲到數(shù)據(jù)庫（BigTable）中；又或者箩退，特定請求的元數(shù)據(jù)信息离熏，從服務請求中剝離出來，發(fā)送給一個異常收集服務戴涝，如NewRelic滋戳；
2?Metrics：特點是可累加的：他們具有原子性，每個都是一個邏輯計量單元啥刻，或者一個時間段內(nèi)的柱狀圖奸鸯。例如：隊列的當前深度可以被定義為一個計量單元，在寫入或讀取時被更新統(tǒng)計可帽；?輸入HTTP請求的數(shù)量可以被定義為一個計數(shù)器娄涩，用于簡單累加；?請求的執(zhí)行時間可以被定義為一個柱狀圖映跟，在指定時間片上更新和統(tǒng)計匯總蓄拣。
? 一直以來，三類監(jiān)控技術各自圍繞自己的關注點持續(xù)演進努隙，產(chǎn)生了多種多樣開源實現(xiàn)方案球恤。
2?Tracing:在Tracing方面，已經(jīng)從最開始的Google Dapper論文逐漸演進形成了OpenTracing規(guī)范剃法，并有著眾多的開源實現(xiàn)碎捺；
2?Metrics:CNCF主推的Prometheus以及配套的Grafana已經(jīng)逐漸蓋過了Zabbix的風頭路鹰，成為云原生時代炙手可熱的監(jiān)控利器；
2?Logging:大的方向上ELK依然牢牢占據(jù)著日志采集與展示的龍頭收厨。
1.2.Tracing技術速覽
?回到本文的主題晋柱，Tracing相關技術從Google發(fā)表Dapper論文，到分布式诵叁、云原生技術的不斷應用實踐雁竞，已經(jīng)逐步從單純的服務跟蹤發(fā)展到了業(yè)務監(jiān)控、應用代碼質(zhì)量等多元化應用階段拧额。
2.??Tracing的Metrics可視化方案
?在Peter Bourgon的《Metrics,tracing, and logging》博客中碑诉，給出了如下關系圖。
?通過上圖侥锦，我們可以的清晰的發(fā)現(xiàn)进栽，將Tracing信息通過Metrics進行聚合分析之后，可以實現(xiàn)服務請求級別的Metrics統(tǒng)計分析恭垦。
2.1.示例工程
為了更加方便理解后續(xù)內(nèi)容快毛，我制作了一個簡單的Sample，用于生成相關的tracing數(shù)據(jù)番挺，以便于進行可視化分析唠帝。
一個Spring Boot MVC工程，提供了以下三個功能玄柏，每個功能里針對數(shù)據(jù)庫有不同的訪問次數(shù)襟衰，如下表：
序號UI頁面后臺服務數(shù)據(jù)庫訪問次數(shù)
1首頁HelloController#index1
2登錄HelloController#login50
3登錄后歡迎頁HelloController#hello100
2.1.1.??首頁
????頁面如下：
Controller中代碼如下：
??? @RequestMapping("/")
?public?String index(){
????// 1?次數(shù)據(jù)庫訪問
??? ???userService.getAllUsers();
?return"index";
??? }
2.1.2.??登錄頁面
頁面如下：
Controller中代碼如下：
?? @RequestMapping(value =?"/login")
?public?String login(){
?// 50?次數(shù)據(jù)庫訪問
?for(inti=0;i<50;i++){
?userService.create("user"+i,?i);
??? }
?return"login";
??? }
2.1.3.??登錄后歡迎頁
???頁面如下：
Controller中代碼如下：
??? @RequestMapping(value =?"/hello")
?public?String hello(ModelMap?map){
?// 100?次數(shù)據(jù)庫訪問
?for(inti=0;i<100;i++){
?userService.getAllUsers();
??? }
?map.addAttribute("host",?"http://sample.hello.com");
?return"hello";
??? }
2.2.開源實現(xiàn)示例——Elastic APM
ElasticAPM?包含四個組件：
2?APM agent:APM agent?是使用與服務相同的語言編寫的開源庫，可以像安裝其他庫一樣將它們安裝到服務中粪摘，agent?將檢測服務的代碼并在運行時收集性能數(shù)據(jù)和錯誤瀑晒，這些數(shù)據(jù)緩沖一小段時間并發(fā)送到?APM server
2?APM server:APM Server?是用?Go?編寫的開源應用程序，通常運行在專用服務器上徘意，默認監(jiān)聽端口?8200?瑰妄，并通過?JSON HTTP API?從?agent?接收數(shù)據(jù)，然后根據(jù)該數(shù)據(jù)創(chuàng)建文檔并將其存儲在?Elasticsearch?中映砖。
2?Elasticsearch:Elasticsearch?是高可擴展的開源全文搜索和分析引擎，用于快速灾挨、近實時地存儲邑退、搜索和分析大量數(shù)據(jù)。此處用于存儲?APM?性能指標并利用其聚合
2?Kibana:Kibana?是開源的分析和可視化平臺劳澄，旨在與Elasticsearch?協(xié)同工作地技，可以通過?Kibana?搜索、查看?Elasticsearch?中存儲的數(shù)據(jù)秒拔，此處用于可視化Elasticsearch?中存儲的?APM?數(shù)據(jù)莫矗。
ElasticAPM的架構圖如下：
?使用之前示例工程，按照Elastic APM的要求，搭建ElasticSearch作谚、Kibana三娩、APM Server之后，在應用啟動時添加APM agent?的代理妹懒，即可輕松與ElasticAPM進行對接雀监，形成Tracing信息并進行分析。
2.2.1.??應用全部服務總體統(tǒng)計分析
?按照應用維度眨唬，統(tǒng)計所有服務的整體情況会前，不區(qū)分具體服務。
2.2.1.1.??????SPAN分類耗時統(tǒng)計
?收集到應用的所有span耗時分析：
2.2.1.2.??????服務耗時時序分布圖
?應用所有服務的按照時間分布耗時分析匾竿，有平均值瓦宜、95%和99%的耗時。
2.2.1.3.??????服務請求數(shù)時序分布圖
按照時間分布的應用所有服務請求數(shù)統(tǒng)計岭妖。
2.2.1.4.??????服務執(zhí)行時間排行
?在Elastic APM中临庇，每一個Trace定義為一個Transaction，可以輕松查看到每個服務總體的平均響應時間区转，95%的響應時間苔巨，每分鐘請求數(shù)等。
? ?點擊每一個Transaction废离，可以查看每個服務的明細信息侄泽。
2.2.2.??具體單個服務維度執(zhí)行明細統(tǒng)計
2.2.2.1.??????SPAN分類耗時統(tǒng)計
?按照不同SPAN類型進行的耗時統(tǒng)計，可以看到對于數(shù)據(jù)庫查詢（h2）的耗時占比28.8%蜻韭。
2.2.2.2.??????服務耗時時序分布圖
?按照時間分布的服務執(zhí)行耗時統(tǒng)計悼尾，有平均值、95%和99%的耗時肖方。
2.2.2.3.??????服務請求數(shù)時序分布圖
?按照時間分布的服務請求數(shù)統(tǒng)計闺魏。
2.2.2.4.??????服務耗時分布直方圖
?按照服務耗時統(tǒng)計生成的直方圖，可以快速查看耗時的分布情況俯画。
2.2.2.5.??????Trace信息抽樣
?可以查看具體服務的Tracing明細信息析桥，具體到每個SPAN。對于數(shù)據(jù)庫訪問可以清晰的看到所指向的SQL艰垂。
2.3.個性化定制實現(xiàn)方案——ElasticSearch+Grafana
Grafana作為在Metrics展示領域的后起之秀泡仗，已經(jīng)越來越多的被采用。Grafana天然支持Elasticsearch作為Metrics數(shù)據(jù)源猜憎，這也大大方便了我們對Tracing做可視化初始娩怎。
?我們直接使用Elastic APM生成在ElasticSearch中的tracing索引信息，即可在Grafana中靈活定制自己的統(tǒng)計圖表胰柑。
2.3.1.??Elastic? APM數(shù)據(jù)源
?在Kinbana中截亦，可以查看到ElasticAPM存儲在ElasticSearch中的index爬泥，如下圖所示。
對應的在Grafana中按照如下方式配置即可崩瓤，分別為Transaction和Span的數(shù)據(jù)源：
2.3.2.??個性化定制
?配置完數(shù)據(jù)源之后袍啡，即可按照實際需要定制化統(tǒng)計分析頁面，例如可以統(tǒng)計服務請求量谷遂、服務耗時排行等等葬馋。
?以下是筆者自己定制的一個統(tǒng)計面板：
3.??借力Metrics，提供更好的APM服務
?借助Metrics肾扰，可以輕松實現(xiàn)以下幾類APM功能畴嘶，并通過可視化工具進行展示：
2?服務性能分析：各個服務的響應時間統(tǒng)計；可視化展示最耗時服務排行榜集晚；單個服務的平均響應時間窗悯、90%響應時間等；
2?代碼質(zhì)量分析：通過統(tǒng)計每一個服務調(diào)用Trace信息中span的數(shù)量偷拔，可以輕松獲取到服務的復雜度排行蒋院。基于此可以分析是否有復雜的莲绰、不合理大量外部調(diào)用欺旧，尤其是在循環(huán)中訪問數(shù)據(jù)庫、外部服務等情況蛤签；
2?服務熱度分析：基于Tracing信息中各個服務的調(diào)用頻次辞友，形成服務調(diào)用熱力圖，基于此可以對相應的彈性部署震肮；
2?慢SQL分析：在Tracing中称龙，每一次SQL調(diào)用生成一個SPAN，基于此可以輕松的對SQL調(diào)用進行統(tǒng)計分析戳晌，從應用調(diào)用層面對形成慢SQL分析鲫尊。
3.1.服務性能分析
?以下是示例工程中所提供的服務的性能統(tǒng)計，通過該統(tǒng)計可以快速發(fā)現(xiàn)應用系統(tǒng)中的慢服務沦偎，從而有針對性的進行調(diào)優(yōu)疫向。
建議：在進行壓力測試處于穩(wěn)定階段時，進行服務性能的分析會相對精確豪嚎，否則偏差會比較大鸿捧。
3.2.代碼質(zhì)量分析
?以下是示例工程中所提供的服務的調(diào)用深度排行，從這個排行表中可以快速發(fā)現(xiàn)服務實現(xiàn)邏輯的復雜度疙渣，有助有我們分析服務代碼實現(xiàn)是否合理（例如：是否又在循環(huán)處理中大量調(diào)用數(shù)據(jù)庫訪問、其它中間件或外部服務）堆巧。
?下圖中妄荔，我們可以清晰的看到前兩個服務分別有102和52個Span泼菌，點擊查看可以發(fā)現(xiàn)分別調(diào)用了100次和50次數(shù)據(jù)庫查詢，查過了我們預設的深度閾值20啦租，顯示為紅色哗伯。
3.3.服務熱度分析
?以下是示例工程中所提供的服務的請求次數(shù)排行，可以在tracing抽樣統(tǒng)計上篷角，幫我們分析應用各服務的熱度焊刹。
3.4.慢SQL分析
?以下是示例工程中SQL執(zhí)行時間的排行統(tǒng)計，基于該統(tǒng)計可以從應用調(diào)用數(shù)據(jù)庫訪問層面看到各類SQL的執(zhí)行時間恳蹲。再配合從數(shù)據(jù)庫服務器監(jiān)控的慢SQL統(tǒng)計虐块，可以在很大程度上能夠?qū)玫臄?shù)據(jù)庫訪問合理性、數(shù)據(jù)庫表設計合理性進行分析嘉蕾，從而排出數(shù)據(jù)庫層面性能瓶頸贺奠。
4.??總結與展望
? ? 本文只是對Tracing使用Metrics進行可視化進行了初步的探討，Tracing還可以有更加廣泛错忱、復雜的應用場景儡率，例如通過分析Tracing信息中的業(yè)務信息，可以實現(xiàn)業(yè)務監(jiān)控以清。
? ? 在云原生和分布式使用越來越廣泛的前景下儿普，如何用好海量的日志、Tracing信息和Metrics信息掷倔，將會是一個非常具有挑戰(zhàn)性而又很有前景的方向眉孩。
????關注“分布式技術架構”微信公眾號，請用微信掃一掃今魔。
