轉(zhuǎn)載本文需注明出處:微信公眾號EAWorld,違者必究。
引言:
微服務(wù)框架落地后,分布式部署架構(gòu)帶來的問題就會迅速凸顯出來。服務(wù)之間的相互調(diào)用過程中,如果業(yè)務(wù)出現(xiàn)錯誤或者異常,如何快速定位問題?如何跟蹤業(yè)務(wù)調(diào)用鏈路?如何分析解決業(yè)務(wù)瓶頸?...本文我們來看看如何解決以上問題。
目錄:
一、SkyWalking初探
二、業(yè)務(wù)調(diào)用鏈路監(jiān)控
三、服務(wù)性能指標(biāo)監(jiān)控
四、服務(wù)告警
一、SkyWalking初探
Skywalking 簡介
Skywalking是一款國內(nèi)開源的應(yīng)用性能監(jiān)控工具,支持對分布式系統(tǒng)的監(jiān)控、跟蹤和診斷。
它提供了如下的主要功能特性:

Skywalking 技術(shù)架構(gòu)

SW總體可以分為四部分:
1.Skywalking Agent:使用JAVAagent做字節(jié)碼植入,無侵入式的收集,并通過HTTP或者gRPC方式發(fā)送數(shù)據(jù)到Skywalking Collector。
2. Skywalking Collector :鏈路數(shù)據(jù)收集器,對agent傳過來的數(shù)據(jù)進行整合分析處理并落入相關(guān)的數(shù)據(jù)存儲中。
3. Storage:Skywalking的存儲,時間更迭,sw已經(jīng)開發(fā)迭代到了6.x版本,在6.x版本中支持以ElasticSearch、MySQL、TiDB、H2、作為存儲介質(zhì)進行數(shù)據(jù)存儲。
4. UI :Web可視化平臺,用來展示落地的數(shù)據(jù)。
Skywalking Agent配置
通過了解配置,可以對一個組件功能有一個大致的了解。讓我們一起看一下skywalking的相關(guān)配置。
解壓開skywalking的壓縮包,在agent/config文件夾中可以看到agent的配置文件。
從skywalking支持環(huán)境變量配置加載,在啟動的時候優(yōu)先讀取環(huán)境變量中的相關(guān)配置。

- agent.namespace: 跨進程鏈路中的header,不同的namespace會導(dǎo)致跨進程的鏈路中斷
- agent.service_name:一個服務(wù)(項目)的唯一標(biāo)識,這個字段決定了在sw的UI上的關(guān)于service的展示名稱
- agent.sample_n_per_3_secs: 客戶端采樣率,默認(rèn)是-1代表全采樣
- agent.authentication: 與collector進行通信的安全認(rèn)證,需要同collector中配置相同
- agent.ignore_suffix: 忽略特定請求后綴的trace
- collecttor.backend_service: agent需要同collector進行數(shù)據(jù)傳輸?shù)腎P和端口
- logging.level: agent記錄日志級別
skywalking agent使用javaagent無侵入式的配合collector實現(xiàn)對分布式系統(tǒng)的追蹤和相關(guān)數(shù)據(jù)的上下文傳遞。
Skywalking Collector關(guān)鍵配置
Collector支持集群部署,zookeeper、kubernetes(如果你的應(yīng)用是部署在容器中的)、consul(Go語言開發(fā)的服務(wù)發(fā)現(xiàn)工具)是sw可選的集群管理工具,結(jié)合大家具體的部署方式進行選擇。詳細(xì)配置大家可以去Skywalking官網(wǎng)下載介質(zhì)包進行了解。
Collector端口設(shè)置

downsampling: 采樣匯總統(tǒng)計維度,會分別按照分鐘、【小時、天、月】(可選)來統(tǒng)計各項指標(biāo)數(shù)據(jù)。
通過設(shè)置TTL相關(guān)配置項可以對數(shù)據(jù)進行自動清理。
Skywalking 在6.X中簡化了配置。collector提供了gRPC和HTTP兩種通信方式。
UI使用rest http通信,agent在大多數(shù)場景下使用grpc方式通信,在語言不支持的情況下會使用http通信。
關(guān)于綁定IP和端口需要注意的一點是,通過綁定IP,agent和collector必須配置對應(yīng)ip才可以正常通信。
Collector存儲配置
在Application.yml中配置的storage模塊配置中選擇要使用的數(shù)據(jù)庫類型,并填寫相關(guān)的配置信息。

Collector Receiver
Receiver是Skywalking在6.x提出的新的概念,負(fù)責(zé)從被監(jiān)控的系統(tǒng)中接受指標(biāo)數(shù)據(jù)。用戶完全可以參照OpenTracing規(guī)范來上傳自定義的監(jiān)控數(shù)據(jù)。Skywalking官方提供了service-mesh、istio、zipkin的相關(guān)能力。

現(xiàn)在Skywalking支持服務(wù)端采樣,配置項為sampleRate,比例采樣,如果配置為5000則采樣率就是50%。
關(guān)于采樣設(shè)置的一點注意事項
關(guān)于服務(wù)采樣配置的一點建議,如果Collector以集群方式部署,比如:Acollector和Bcollector,建議Acollector.sampleRate = Bcollector.sampleRate。如果采樣率設(shè)置不相同可能會出現(xiàn)數(shù)據(jù)丟失問題。

假設(shè)Agent端將所有數(shù)據(jù)發(fā)送到后端Collector處,A采樣率設(shè)置為30%,B采樣率為50%。
假設(shè)有30%的數(shù)據(jù),發(fā)送到A上,這些數(shù)據(jù)被全部正確接受并存儲,極端情況(與期望的采樣數(shù)據(jù)量相同)下,如果剩下20%待采樣的數(shù)據(jù)發(fā)送到了B,這個時候一切都是正常的,如果這20%中有一部分?jǐn)?shù)據(jù)被送到了A那么,這些數(shù)據(jù)將是被忽略的,由此就會造成數(shù)據(jù)丟失。
二、業(yè)務(wù)調(diào)用鏈路監(jiān)控
Service Topology監(jiān)控
調(diào)用鏈路監(jiān)控可以從兩個角度去看待。我們先從整體上來認(rèn)識一下我們所監(jiān)控的系統(tǒng)。
通過給服務(wù)添加探針并產(chǎn)生實際的調(diào)用之后,我們可以通過Skywalking的前端UI查看服務(wù)之間的調(diào)用關(guān)系。
我們簡單模擬一次服務(wù)之間的調(diào)用。新建兩個服務(wù),service-provider以及service-consumer,服務(wù)之間簡單的通過Feign Client 來模擬遠程調(diào)用。

從圖中可以看到:
有兩個服務(wù)節(jié)點:provider & consumer
有一個數(shù)據(jù)庫節(jié)點:localhost【mysql】
一個注冊中心節(jié)點
consumer消費了provider提供出來的接口。
一個系統(tǒng)的拓?fù)鋱D讓我們清晰的認(rèn)識到系統(tǒng)之間的應(yīng)用的依賴關(guān)系以及當(dāng)前狀態(tài)下的業(yè)務(wù)流轉(zhuǎn)流程。細(xì)心的可能發(fā)現(xiàn)圖示節(jié)點consumer上有一部分是紅色的,紅色是什么意思呢?
紅色代表當(dāng)前流經(jīng)consumer節(jié)點的請求有一斷時間內(nèi)是響應(yīng)異常的。當(dāng)節(jié)點全部變紅的時候證明服務(wù)現(xiàn)階段內(nèi)就徹底不可用了。運維人員可以通過Topology迅速發(fā)現(xiàn)某一個服務(wù)潛在的問題,并進行下一步的排查并做到預(yù)防。
Skywalking Trace監(jiān)控
Skywalking通過業(yè)務(wù)調(diào)用監(jiān)控進行依賴分析,提供給我們了服務(wù)之間的服務(wù)調(diào)用拓?fù)潢P(guān)系、以及針對每個endpoint的trace記錄。
我們在之前看到consumer節(jié)點服務(wù)中發(fā)生了錯誤,讓我們一起來定位下錯誤是發(fā)生在了什么地方又是什么原因呢?

在每一條trace的信息中都可以看到當(dāng)前請求的時間、GloableId、以及請求被調(diào)用的時間。我們分別看一看正確的調(diào)用和異常的調(diào)用。
Trace調(diào)用鏈路監(jiān)控

圖示展示的是一次正常的響應(yīng),這條響應(yīng)總耗時19ms,它有4個span:
- span1 /getStore = 19ms 響應(yīng)的總流轉(zhuǎn)時間
- span2 /demo2/stores = 14ms feign client 開始調(diào)用遠程服務(wù)后的響應(yīng)的總時間
- span3 /stores = 14ms 接口服務(wù)響應(yīng)總時間
- span4 Mysql = 1ms 服務(wù)提供端查詢數(shù)據(jù)庫的時間
這里span2和span3的時間表現(xiàn)相同,其實是不同的,因為這里時間取了整。
在每個Span中可以查看當(dāng)前Span的相關(guān)屬性。
- 組件類型: SpringMVC、Feign
- Span狀態(tài): false
- HttpMethod: GET
- Url: http://192.168.16.125:10002/demo2/stores

這是一次正常的請求調(diào)用Trace日志,可能我們并不關(guān)心正常的時候,畢竟一切正常不就是我們期待的么!
我們再來看下,異常狀態(tài)下我們的Trace以及Span又是什么樣的呢。

發(fā)生錯誤的調(diào)用鏈中Span中的is error標(biāo)識變?yōu)閠rue,并且在名為Logs的TAB中可以看到錯誤發(fā)生的具體原因。根據(jù)異常情況我們就可以輕松定位到影響業(yè)務(wù)的具體原因,從而快速定位問題,解決問題。
通過Log我們看到連接被拒,那么可能是我們的網(wǎng)絡(luò)出現(xiàn)了問題(可能性小,因為實際情況如果網(wǎng)絡(luò)出現(xiàn)問題我們連這個trace都看不到了),也有可能是服務(wù)端配置問題無法正確建立連接。通過異常日志,我們迅速就找到了問題的關(guān)鍵。
實際情況是,我把服務(wù)方停掉了,做了一次簡單的模擬。可見,通過拓?fù)鋱D示我們可以清晰的看到眾多服務(wù)中哪個服務(wù)是出現(xiàn)了問題的,通過trace日志我們可以很快就定位到問題所在,在最短的時間內(nèi)解決問題。
三、服務(wù)性能指標(biāo)監(jiān)控
Skywalking還可以查看具體Service的性能指標(biāo),根據(jù)相關(guān)的性能指標(biāo)可以分析系統(tǒng)的瓶頸所在并提出優(yōu)化方案。
Skywalking 性能監(jiān)控
在服務(wù)調(diào)用拓?fù)鋱D上點擊相應(yīng)的節(jié)點我們可以看到該服務(wù)的
SLA: 服務(wù)可用性(主要是通過請求成功與失敗次數(shù)來計算)
CPM: 每分鐘調(diào)用次數(shù)
Avg Response Time: 平均響應(yīng)時間

從應(yīng)用整體外部來看我們可以監(jiān)測到應(yīng)用在一定時間段內(nèi)的
- 服務(wù)可用性指標(biāo)SLA
- 每分鐘平均響應(yīng)數(shù)
- 平均響應(yīng)時間
- 服務(wù)進程PID
- 服務(wù)所在物理機的IP、HostName、Operation System
Service JVM信息監(jiān)控

還可以監(jiān)控到Service運行時的CPU、堆內(nèi)存、非堆內(nèi)存使用率、以及GC情況。這些信息來源于JVM。注意這里的數(shù)據(jù)可不是機器本身的數(shù)據(jù)。
四、服務(wù)告警
前文我們提到了通過查看拓?fù)鋱D以及調(diào)用鏈路可以定位問題,可是運維人員又不可能一直盯著這些數(shù)據(jù),那么我們就需要告警能力,在異常達到一定閾值的時候主動的提示我們?nèi)ゲ榭聪到y(tǒng)狀態(tài)。
在Sywalking 6.x版本中新增了對服務(wù)狀態(tài)的告警能力。它通過webhook的方式讓我們可以自定義我們告警信息的通知方式。諸如:郵件通知、微信通知、短信通知等。
Skywalking 服務(wù)告警
先來看一下告警的規(guī)則配置。在alarm-settings.xml中可以配置告警規(guī)則,告警規(guī)則支持自定義。

一份告警配置由以下幾部分組成:
- service_resp_time_rule:告警規(guī)則名稱 ***_rule (規(guī)則名稱可以自定義但是必須以’_rule’結(jié)尾
- indicator-name:指標(biāo)數(shù)據(jù)名稱: 定義參見http://t.cn/EGhfbmd
- op: 操作符: > , < , = 【當(dāng)然你可以自己擴展開發(fā)其他的操作符】
- threshold:目標(biāo)值:指標(biāo)數(shù)據(jù)的目標(biāo)數(shù)據(jù) 如sample中的1000就是服務(wù)響應(yīng)時間,配合上操作符就是大于1000ms的服務(wù)響應(yīng)
- period: 告警檢查周期:多久檢查一次當(dāng)前的指標(biāo)數(shù)據(jù)是否符合告警規(guī)則
- counts: 達到告警閾值的次數(shù)
- silence-period:忽略相同告警信息的周期
- message:告警信息
- webhooks:服務(wù)告警通知服務(wù)地址
Skywalking通過HttpClient的方式遠程調(diào)用在配置項webhooks中定義的告警通知服務(wù)地址。

了解了SW所傳送的數(shù)據(jù)格式我們就可以對告警信息進行接收處理,實現(xiàn)我們需要的告警通知服務(wù)啦!
我們將一個服務(wù)停掉,并將另外一個服務(wù)的某個對外暴露的接口讓他休眠一定的時間。然后調(diào)用一定的次數(shù)觀察服務(wù)的狀態(tài)信息以及告警情況。

總結(jié):
本文簡單的通過skwaylking的配置來對skywlaking的功能進行一次初步的了解,對skwaylking新提出的概念以及新功能進行簡單的詮釋,方便大家了解和使用。通過使用APM工具,可以讓我們方便的查看微服務(wù)架構(gòu)中系統(tǒng)瓶頸以及性能問題等。

關(guān)于作者:趙瑞棟,普元java工程師,從事Eclipse插件開發(fā),參與普元EOS8 Platform開發(fā),現(xiàn)主要參與EOS8微服務(wù)管理平臺開發(fā)工作。
關(guān)于EAWorld:微服務(wù),DevOps,數(shù)據(jù)治理,移動架構(gòu)原創(chuàng)技術(shù)分享。長按二維碼關(guān)注!