如何定位微服務異常之鏈路跟蹤APM工具？

前言

微服務框架落地後，分佈式部署架構帶來的問題就會迅速凸顯出來。尤爲線上出現問題，不知道如何排查，**問題出如今哪一個服務？如何快速定位問題？**如何跟蹤業務調用鏈路？**如何分析解決業務瓶頸？**今天老顧來跟小夥伴們看看如何解決以上問題。

什麼是鏈路追蹤

微服務架構是經過業務來劃分服務的，使用REST調用。對外暴露的一個接口，可能須要不少個服務協同才能完成這個接口功能，若是鏈路上任何一個服務出現問題或者網絡超時，都會造成致使接口調用失敗。隨着業務的不斷擴張，服務之間互相調用會愈來愈複雜。

上圖中，user調用A，A會調用C，C再調用E；這條調用鏈路，咱們還可以看清楚；可是一旦 微服務不少， 調用依賴複雜就看不清楚了，以下圖

上圖是否是看到後，有密集恐懼症，像個線團，一團亂麻；若是這個時候出現了調用異常，那咱們依據調用接口入口，一步步、一個服務一個服務的去跟蹤調試；這個流程會把人搞瘋的，也許1個小時後，也不知道什麼問題；就像咱們之前找線頭，而後一步步的去從新卷圈。

面對以上狀況，咱們就須要一些能夠幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，可以快速定位和解決問題，這就是所謂的 APM（應用性能管理）。

什麼是 SkyWalking

Skywalking是一款國內開源的應用性能監控工具，支持對分佈式系統的監控、跟蹤和診斷。目前主要的一些 APM 工具備: Cat、Zipkin、Pinpoint、SkyWalking。SkyWalking也是Apache的孵化項目之一，擁有頂級二級域名。 它提供了以下的主要功能特性：

功能特性： * 多種監控手段， 語言探針和服務網格(Service Mesh) * 多語言自動探針，Java，.NET Core 和 Node.JS * 輕量高效，不須要大數據 * 模塊化，UI、存儲、集羣管理多種機制可選 * 支持告警 * 優秀的 可視化方案

技術架構

上圖看了是否是比較亂， 其實Skywalking整體能夠分爲四部分： 一、Skywalking Agent：使用Javaagent作字節碼植入，無侵入式的收集，並 經過HTTP或者gRPC方式發送數據到 Skywalking Collector。 二、Skywalking Collector ：鏈路數據收集器，對 agent傳過來的數據進行整合 分析處理並落入相關的數據存儲中。 三、Storage：Skywalking的存儲，在6.x版本中支持以 ElasticSearch（推薦）、Mysql、TiDB、H二、做爲存儲介質進行數據存儲。 四、UI ：Web可視化平臺，用來展現落地的數據。

下載並啓動 SkyWalking

官方已經爲咱們準備好了編譯過的服務端版本，如今最新版本爲6.4.0

下載地址爲 skywalking.apache.org/downloads/

配置 SkyWalking

下載完成後解壓縮

# tar -xvf apache-skywalking-apm-6.4.0.tar
# mv apache-skywalking-apm-bin /usr/local/skywalking
# cd /usr/local/skywalking
複製代碼

修改配置

# cd config
複製代碼

vim application.yml@

配置存儲方式，默認H2，官方推薦elasticsearch 這裏須要作三件事：

1. 註釋 H2 存儲方案
2. 啓用 ElasticSearch 存儲方案
3. 修改 ElasticSearch 服務器地址

clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}

啓動 SkyWalking

修改完配置後，進入 skywalking\bin 目錄，運行startup.bat啓動服務端

經過瀏覽器訪問 http://localhost:8080 出現以下界面即表示啓動成功

默認的用戶名密碼爲：admin/admin，登陸成功後，效果以下圖

Java Agent 服務器探針

agent簡單的理解就是放一個插件，隨着應用程序啓動，監控數據、收集數據、發送數據的做用。 探針文件在skywalking/agent目錄下

啓動方式

在之前啓動應用程序時，加上一些參數

java -javaagent:/path/to/skywalking-agent/skywalking-agent.jar 
    -Dskywalking.agent.service_name=shop-goods-provider 
    -Dskywalking.collector.backend_service=localhost:11800 
    -jar yourApp.jar
複製代碼

參數含義：

• **-javaagent：**用於指定探針路徑
• **-Dskywalking.agent.service_name：**用於重寫 agent/config/agent.config 配置文件中的服務名
• **-Dskywalking.collector.backend_service：**用於重寫 agent/config/agent.config 配置文件中的服務地址

啓動後，訪問連接，就會發現 Service 與 Endpoint 已經成功檢測到了

表示 SkyWalking 鏈路追蹤配置成功。

Service Topology監控

調用鏈路監控能夠從兩個角度去看待。咱們先從總體上來認識一下咱們所監控的系統。

經過給服務添加探針併產生實際的調用以後，咱們能夠經過Skywalking的前端UI查看服務之間的調用關係。

從圖中能夠看到:

有兩個服務節點：provider & consumer 有一個數據庫節點：localhost【mysql】 consumer消費了provider提供出來的接口。

一個系統的拓撲圖讓咱們清晰的認識到系統之間的應用的依賴關係以及當前狀態下的業務流轉流程。

細心的小夥伴們可能發現圖示節點consumer上有一部分是紅色的，紅色是什麼意思呢？

紅色表明當前流經consumer節點的請求有一斷時間內是響應異常的。當節點所有變紅的時候證實服務現階段內就完全不可用了。運維人員能夠經過Topology迅速發現某一個服務潛在的問題，並進行下一步的排查並作到預防。

Skywalking Trace監控

Skywalking經過業務調用監控進行依賴分析，提供給咱們了服務之間的服務調用拓撲關系、以及針對每一個endpoint的trace記錄。 咱們在以前看到consumer節點服務中發生了錯誤，讓咱們一塊兒來定位下錯誤是發生在了什麼地方又是什麼緣由呢？

在每一條trace的信息中均可以看到當前請求的時間、GloableId、以及請求被調用的時間。咱們分別看一看正確的調用和異常的調用。

Trace調用鏈路監控

上圖展現的是一次正常的響應，這條響應總耗時19ms；能夠詳細點擊每一個span查看詳細信息

Service JVM信息監控

Skywalking還能夠監控到 Service運行時的CPU、堆內存、非堆內存使用率、以及GC狀況。這些信息 來源於JVM。

Skywalking 服務告警

上面咱們提到了經過查看拓撲圖以及調用鏈路能夠定位問題，但是運維人員又不可能一直盯着這些數據，那麼咱們就須要告警能力，在異常達到必定閾值的時候主動的提示咱們去查看系統狀態。

在Sywalking 6.x版本中新增了對服務狀態的告警能力。它經過webhook的方式讓咱們能夠自定義咱們告警信息的通知方式。諸如:郵件通知、微信通知、短信通知等。

告警的規則配置。在alarm-settings.xml中能夠配置告警規則，告警規則支持自定義。

一、service_resp_time_rule：告警規則名稱 ***_rule （規則名稱能夠自定義可是必須以’_rule’結尾

二、indicator-name：指標數據名稱： 定義參見t.cn/EGhfbmd

三、op: 操做符： > , < , = 【固然你能夠本身擴展開發其餘的操做符】

四、threshold：目標值：指標數據的目標數據 如sample中的1000就是服務響應時間，配合上操做符就是大於1000ms的服務響應

五、period: 告警檢查週期：多久檢查一次當前的指標數據是否符合告警規則

六、counts: 達到告警閾值的次數

七、silence-period：忽略相同告警信息的週期

八、message：告警信息

文件結尾有最後一個webhooks屬性：服務告警通知服務地址

webhooks:
# - http://127.0.0.1/notify/
# - http://127.0.0.1/go-wechat/
複製代碼

總結

本文簡單了介紹了Skywalking簡單的知識，能夠經過Skywalking，可讓咱們方便的查看微服務架構中系統瓶頸以及性能問題等。小夥伴們能夠去嘗試操做一下哦，謝謝！！！

你的贊和關注是我繼續創做的動力~