系統監控-分佈式調用鏈Skywalking

1. 爲何要使用分佈式調用鏈技術？

隨着公司業務的高速發展，公司服務之間的調用關係越發複雜，如何理清並跟蹤它們之間的調用關係就顯的比較關鍵。線上每個請求會通過多個業務系統，併產生對各類緩存或者 DB 的訪問，可是這些分散的數據對於問題排查，或者流程優化提供的幫助有限。在這樣複雜的業務場景下，業務流會通過不少個微服務的處理和傳遞，咱們不免會遇到這些問題：

• 一次請求的流量從哪一個服務而來？ 最終落到了哪一個服務中去？
• 爲何這個請求這麼慢? 到底哪一個環節出了問題?
• 這個操做須要依賴哪些東西? 是數據庫仍是消息隊列?
• Redis掛了，哪些業務受影響?

2. 開源產品從多，能夠從以下幾個方面去選型。

咱們須要達到的目標：

• 低消耗性：跟蹤系統對業務系統的影響應該作到足夠小。在一些高度優化過的服務，即便一點點損耗也容易察覺到，並且有可能迫使在線負責的部署團隊不得不將跟蹤系統關停
• 低侵入性：做爲非業務組件，應當儘量少侵入或者無侵入業務系統，對於使用方透明，減小開發人員的負擔
• 時效性：從數據的收集產生，到數據計算處理，再到最終展示，都要求儘量快
• 決策支持：這些數據是否能在決策支持層面發揮做用，特別是從 DevOps 的角度
• 數據可視化：作到不用看日誌經過可視化進行篩選

實現的功能：

• 故障定位：調用鏈路跟蹤，一次請求的邏輯軌跡能夠完整清晰的展現出來。
• 性能分析：調用鏈的各個環節分別添加調用耗時，能夠分析出系統的性能瓶頸，並針對性的優化。
• 數據分析：調用鏈是一條完整的業務日誌，能夠獲得請求的行爲路徑，彙總分析應用在不少業務場景。

開源產品：

• Twitter 公司開源的分佈式追蹤系統 Zipkin 
• 韓國人開源的分佈式跟蹤組件 Pinpoint
• 國產的優秀APM組件 Skywalking，
• 其餘相似的組件還有美團點評的 CAT。

分佈式調用鏈和傳統的新能監控有什麼區別？

APM工具與傳統的性能監控工具的區別在於，不單單提供一些零散的資源監控點和指標，其主要關注在系統內部執行、系統間調用的性能瓶頸分析，這樣更有利於定位到問題的具體緣由。

社區活躍度：

類別	Zipkin	Pinpoint	SkyWalking	CAT
start小星星數	9.7k	7.5k	4.7k	6.7k

性能分析： 

3. 綜上多個方面最終選擇Skywalking，下面主要圍繞Skywalking進行展開。

搭建Skywalking須要安裝的組件（windows爲例）：

• elasticsearch-5.6.2（ES/data目錄爲ES數據存放目錄，能夠經過刪除該目錄清空數據，ES/config/elasticsearch.yml配置cluster name、node.name）
• ES和head插件（須要安裝Node.js），安裝參考博客：windows下ES和head插件的安裝（一個界面化的集羣操做和管理工具）
• 下載apache-skywalking-apm-incubating-5.0.0-GA，詳細介紹能夠參考博客：skywalking學習筆記
  • agent：探針，用來收集和發送數據到歸集器（在/apm/agent/config/agent.config主要配置collector地址和應用名稱，通常都是一個項目對應一個agent目錄）。
  • collector：鏈路數據歸集器，數據能夠落地ElasticSearch，單機也能夠落地H2，不推薦，H2僅做爲臨時演示用（在/apm/config/application.yml主要配置ES）。
  • web：web可視化平臺，用來展現落地的數據。
  • ui：單獨的開源ui項目，更美觀易用。

搭建過程當中須要注意的事：

• 須要在/apm/collector-libs下放入mysql-connector-java-5.1.47.jar包。
• 全部軟件的目錄儘可能不要放在帶有空格的目錄下（如：Program Files），ES除外。
• 多服務器搭建須要考慮時區不一致問題。

多組件啓動順序：

ES、ES head、/apm/bin/startup.bat、使用java命令指定-javaagent:skywalking-agent.jar去啓動應用（war、jar）去運行應用、訪問web查看agent註冊狀況。

相關軟件請移步到碼雲或網盤上下載（相關軟件都親測成功，請放心使用）：

https://gitee.com/qrmc/oschina_software_package

連接：https://pan.baidu.com/s/1nCa0Xipj-5tD3nc-3g-QdQ  提取碼：wdxu 

4. 總結：待應用實戰後總結優缺點...