轉載本文需注明出處：微信公眾號EAWorld，違者必究。

引言：

微服務框架落地后，分布式部署架構帶來的問題就會迅速凸顯出來。服務之間的相互調用過程中，如果業務出現錯誤或者異常，如何快速定位問題？如何跟蹤業務調用鏈路？如何分析解決業務瓶頸？...本文我們來看看如何解決以上問題。

目錄：

一、SkyWalking初探

二、業務調用鏈路監控

三、服務性能指標監控

四、服務告警

一、SkyWalking初探

Skywalking 簡介

Skywalking是一款國內開源的應用性能監控工具，支持對分布式系統的監控、跟蹤和診斷。

它提供了如下的主要功能特性：

Skywalking 技術架構

SW總體可以分為四部分：

1.Skywalking Agent：使用JAVAagent做字節碼植入，無侵入式的收集，并通過HTTP或者gRPC方式發送數據到Skywalking Collector。

2. Skywalking Collector ：鏈路數據收集器，對agent傳過來的數據進行整合分析處理并落入相關的數據存儲中。

3. Storage：Skywalking的存儲，時間更迭，sw已經開發迭代到了6.x版本，在6.x版本中支持以ElasticSearch、MySQL、TiDB、H2、作為存儲介質進行數據存儲。

4. UI ：Web可視化平臺，用來展示落地的數據。

Skywalking Agent配置

通過了解配置，可以對一個組件功能有一個大致的了解。讓我們一起看一下skywalking的相關配置。

解壓開skywalking的壓縮包，在agent/config文件夾中可以看到agent的配置文件。

從skywalking支持環境變量配置加載，在啟動的時候優先讀取環境變量中的相關配置。

• agent.namespace: 跨進程鏈路中的header，不同的namespace會導致跨進程的鏈路中斷
• agent.service_name:一個服務（項目）的唯一標識，這個字段決定了在sw的UI上的關于service的展示名稱
• agent.sample_n_per_3_secs: 客戶端采樣率，默認是-1代表全采樣
• agent.authentication: 與collector進行通信的安全認證，需要同collector中配置相同
• agent.ignore_suffix: 忽略特定請求后綴的trace
• collecttor.backend_service: agent需要同collector進行數據傳輸的IP和端口
• logging.level: agent記錄日志級別

skywalking agent使用javaagent無侵入式的配合collector實現對分布式系統的追蹤和相關數據的上下文傳遞。

Skywalking Collector關鍵配置

Collector支持集群部署，zookeeper、kubernetes（如果你的應用是部署在容器中的）、consul（Go語言開發的服務發現工具）是sw可選的集群管理工具，結合大家具體的部署方式進行選擇。詳細配置大家可以去Skywalking官網下載介質包進行了解。

Collector端口設置

downsampling: 采樣匯總統計維度，會分別按照分鐘、【小時、天、月】（可選）來統計各項指標數據。

通過設置TTL相關配置項可以對數據進行自動清理。

Skywalking 在6.X中簡化了配置。collector提供了gRPC和HTTP兩種通信方式。

UI使用rest http通信，agent在大多數場景下使用grpc方式通信，在語言不支持的情況下會使用http通信。

關于綁定IP和端口需要注意的一點是，通過綁定IP，agent和collector必須配置對應ip才可以正常通信。

Collector存儲配置

在Application.yml中配置的storage模塊配置中選擇要使用的數據庫類型，并填寫相關的配置信息。

Collector Receiver

Receiver是Skywalking在6.x提出的新的概念，負責從被監控的系統中接受指標數據。用戶完全可以參照OpenTracing規范來上傳自定義的監控數據。Skywalking官方提供了service-mesh、istio、zipkin的相關能力。

現在Skywalking支持服務端采樣，配置項為sampleRate，比例采樣，如果配置為5000則采樣率就是50%。

關于采樣設置的一點注意事項

關于服務采樣配置的一點建議，如果Collector以集群方式部署，比如：Acollector和Bcollector，建議Acollector.sampleRate = Bcollector.sampleRate。如果采樣率設置不相同可能會出現數據丟失問題。

假設Agent端將所有數據發送到后端Collector處，A采樣率設置為30%，B采樣率為50%。

假設有30%的數據，發送到A上，這些數據被全部正確接受并存儲，極端情況（與期望的采樣數據量相同）下，如果剩下20%待采樣的數據發送到了B，這個時候一切都是正常的，如果這20%中有一部分數據被送到了A那么，這些數據將是被忽略的，由此就會造成數據丟失。

二、業務調用鏈路監控

Service Topology監控

調用鏈路監控可以從兩個角度去看待。我們先從整體上來認識一下我們所監控的系統。

通過給服務添加探針并產生實際的調用之后，我們可以通過Skywalking的前端UI查看服務之間的調用關系。

我們簡單模擬一次服務之間的調用。新建兩個服務，service-provider以及service-consumer，服務之間簡單的通過Feign Client 來模擬遠程調用。

從圖中可以看到:

有兩個服務節點：provider & consumer

有一個數據庫節點：localhost【mysql】

一個注冊中心節點

consumer消費了provider提供出來的接口。

一個系統的拓撲圖讓我們清晰的認識到系統之間的應用的依賴關系以及當前狀態下的業務流轉流程。細心的可能發現圖示節點consumer上有一部分是紅色的，紅色是什么意思呢？

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

Skywalking Trace監控

Skywalking通過業務調用監控進行依賴分析，提供給我們了服務之間的服務調用拓撲關系、以及針對每個endpoint的trace記錄。

我們在之前看到consumer節點服務中發生了錯誤，讓我們一起來定位下錯誤是發生在了什么地方又是什么原因呢？

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

Trace調用鏈路監控

圖示展示的是一次正常的響應，這條響應總耗時19ms，它有4個span：

• span1 /getStore = 19ms 響應的總流轉時間
• span2 /demo2/stores = 14ms feign client 開始調用遠程服務后的響應的總時間
• span3 /stores = 14ms 接口服務響應總時間
• span4 Mysql = 1ms 服務提供端查詢數據庫的時間

這里span2和span3的時間表現相同，其實是不同的，因為這里時間取了整。

在每個Span中可以查看當前Span的相關屬性。

• 組件類型: SpringMVC、Feign
• Span狀態: false
• HttpMethod: GET
• Url: http://192.168.16.125:10002/demo2/stores

這是一次正常的請求調用Trace日志，可能我們并不關心正常的時候，畢竟一切正常不就是我們期待的么！

我們再來看下，異常狀態下我們的Trace以及Span又是什么樣的呢。

發生錯誤的調用鏈中Span中的is error標識變為true，并且在名為Logs的TAB中可以看到錯誤發生的具體原因。根據異常情況我們就可以輕松定位到影響業務的具體原因，從而快速定位問題，解決問題。

通過Log我們看到連接被拒，那么可能是我們的網絡出現了問題（可能性小，因為實際情況如果網絡出現問題我們連這個trace都看不到了），也有可能是服務端配置問題無法正確建立連接。通過異常日志，我們迅速就找到了問題的關鍵。

實際情況是，我把服務方停掉了，做了一次簡單的模擬。可見，通過拓撲圖示我們可以清晰的看到眾多服務中哪個服務是出現了問題的，通過trace日志我們可以很快就定位到問題所在，在最短的時間內解決問題。

三、服務性能指標監控

Skywalking還可以查看具體Service的性能指標，根據相關的性能指標可以分析系統的瓶頸所在并提出優化方案。

Skywalking 性能監控

在服務調用拓撲圖上點擊相應的節點我們可以看到該服務的

SLA: 服務可用性（主要是通過請求成功與失敗次數來計算）

CPM: 每分鐘調用次數

Avg Response Time: 平均響應時間

從應用整體外部來看我們可以監測到應用在一定時間段內的

• 服務可用性指標SLA
• 每分鐘平均響應數
• 平均響應時間
• 服務進程PID
• 服務所在物理機的IP、HostName、Operation System

Service JVM信息監控

還可以監控到Service運行時的CPU、堆內存、非堆內存使用率、以及GC情況。這些信息來源于JVM。注意這里的數據可不是機器本身的數據。

四、服務告警

前文我們提到了通過查看拓撲圖以及調用鏈路可以定位問題，可是運維人員又不可能一直盯著這些數據，那么我們就需要告警能力，在異常達到一定閾值的時候主動的提示我們去查看系統狀態。

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

Skywalking 服務告警

先來看一下告警的規則配置。在alarm-settings.xml中可以配置告警規則，告警規則支持自定義。

一份告警配置由以下幾部分組成：

• service_resp_time_rule：告警規則名稱 ***_rule （規則名稱可以自定義但是必須以’_rule’結尾
• indicator-name：指標數據名稱： 定義參見http://t.cn/EGhfbmd
• op: 操作符： > , < , = 【當然你可以自己擴展開發其他的操作符】
• threshold：目標值：指標數據的目標數據 如sample中的1000就是服務響應時間，配合上操作符就是大于1000ms的服務響應
• period: 告警檢查周期：多久檢查一次當前的指標數據是否符合告警規則
• counts: 達到告警閾值的次數
• silence-period：忽略相同告警信息的周期
• message：告警信息
• webhooks：服務告警通知服務地址

Skywalking通過HttpClient的方式遠程調用在配置項webhooks中定義的告警通知服務地址。

了解了SW所傳送的數據格式我們就可以對告警信息進行接收處理，實現我們需要的告警通知服務啦！

我們將一個服務停掉，并將另外一個服務的某個對外暴露的接口讓他休眠一定的時間。然后調用一定的次數觀察服務的狀態信息以及告警情況。

總結：

本文簡單的通過skwaylking的配置來對skywlaking的功能進行一次初步的了解，對skwaylking新提出的概念以及新功能進行簡單的詮釋，方便大家了解和使用。通過使用APM工具，可以讓我們方便的查看微服務架構中系統瓶頸以及性能問題等。

關于作者：趙瑞棟，普元java工程師，從事Eclipse插件開發，參與普元EOS8 Platform開發，現主要參與EOS8微服務管理平臺開發工作。

關于EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！