Skywalking微服務監控分析

EAWorld發表於2019-01-04
微服務

Skywalking微服務監控分析

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

引言：

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

目錄：

一、SkyWalking初探

二、業務呼叫鏈路監控

三、服務效能指標監控

四、服務告警

一、SkyWalking初探

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支援環境變數配置載入，在啟動的時候優先讀取環境變數中的相關配置。

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埠設定

Skywalking微服務監控分析

  • downsampling: 取樣彙總統計維度，會分別按照分鐘、【小時、天、月】（可選）來統計各項指標資料。

  • 通過設定TTL相關配置項可以對資料進行自動清理。

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

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

關於繫結IP和埠需要注意的一點是，通過繫結IP，agent和collector必須配置對應ip才可以正常通訊。

Collector儲存配置

在application.yml中配置的storage模組配置中選擇要使用的資料庫型別，並填寫相關的配置資訊。

Skywalking微服務監控分析

Collector Receiver

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

Skywalking微服務監控分析

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

關於取樣設定的一點注意事項

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

Skywalking微服務監控分析

假設Agent端將所有資料傳送到後端Collector處，A取樣率設定為30%，B取樣率為50%。

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

二、業務呼叫鏈路監控

Service Topology監控

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

通過給服務新增探針併產生實際的呼叫之後，我們可以通過Skywalking的前端UI檢視服務之間的呼叫關係。

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

Skywalking微服務監控分析

從圖中可以看到:

  • 有兩個服務節點：provider & consumer

  • 有一個資料庫節點：localhost【mysql】

  • 一個註冊中心節點

consumer消費了provider提供出來的介面。

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

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

Skywalking Trace監控

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

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

Skywalking微服務監控分析

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

Trace呼叫鏈路監控


Skywalking微服務監控分析

圖示展示的是一次正常的響應，這條響應總耗時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

Skywalking微服務監控分析

這是一次正常的請求呼叫Trace日誌，可能我們並不關心正常的時候，畢竟一切正常不就是我們期待的麼！

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

Skywalking微服務監控分析

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

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

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

三、服務效能指標監控 

Skywalking還可以檢視具體Service的效能指標，根據相關的效能指標可以分析系統的瓶頸所在並提出優化方案。

Skywalking 效能監控

在服務呼叫拓撲圖上點選相應的節點我們可以看到該服務的

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

  • CPM: 每分鐘呼叫次數

  • Avg Response Time: 平均響應時間

Skywalking微服務監控分析

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

  1. 服務可用性指標SLA

  2. 每分鐘平均響應數

  3. 平均響應時間

  4. 服務程式PID

  5. 服務所在物理機的IP、HostName、Operation System

Service JVM資訊監控

Skywalking微服務監控分析

還可以監控到Service執行時的CPU、堆記憶體、非堆記憶體使用率、以及GC情況。這些資訊來源於JVM。注意這裡的資料可不是機器本身的資料。

四、服務告警

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

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

Skywalking 服務告警

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

Skywalking微服務監控分析

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

  1. service_resp_time_rule：告警規則名稱 ***_rule （規則名稱可以自定義但是必須以’_rule’結尾

  2. indicator-name：指標資料名稱： 定義參見http://t.cn/EGhfbmd

  3. op: 操作符： > , < , = 【當然你可以自己擴充套件開發其他的操作符】

  4. threshold：目標值：指標資料的目標資料 如sample中的1000就是服務響應時間，配合上操作符就是大於1000ms的服務響應

  5. period: 告警檢查週期：多久檢查一次當前的指標資料是否符合告警規則

  6. counts: 達到告警閾值的次數

  7. silence-period：忽略相同告警資訊的週期

  8. message：告警資訊

  9. webhooks：服務告警通知服務地址

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

Skywalking微服務監控分析

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

我們將一個服務停掉，並將另外一個服務的某個對外暴露的介面讓他休眠一定的時間。然後呼叫一定的次數觀察服務的狀態資訊以及告警情況。

Skywalking微服務監控分析

總結：

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

精選提問：

問1：想問問選型的時候用pinpoint還是SK好？

答：選型問題

1.要結合具體的業務場景， 比如你的程式碼執行環境 是java、php、net還是什麼。2.pinpoint在安裝部署上要比skywalking略微複雜3.pinpoint和sw支援的元件列表是不同的。

https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md你可以參照這裡的支援列表對比下pinpoint的支援物件做一個簡單對比。

4.sw經過測試在併發量較高的情況下比pinpoint的吞吐量更好一些。

問2：有沒有指標統計，比如某個url 的top10 請求、響應最慢的10個請求？某個服務在整個鏈條中的耗時佔比？

答：1.sw自帶有響應最慢的請求top10統計針對所有的endpoint的統計。

2.針對每個url的top10統計，sw本身沒有做統計，資料都是現成的通過簡單的檢索就可以搜到你想要的結果。

3.沒有具體的耗時佔比，但是有具體總鏈路時間統計以及某個服務的耗時統計，至於佔比自己算吧，可以看ppt中的呼叫鏈路監控的span時間解釋。

問3：能不能具體說一下在你們系統中的應用？

答：EOS8LA版本中，我們整合sw對應用提供拓撲、呼叫鏈路、效能指標的監控、並在sw資料的基礎上增加系統的維度。

當服務數很龐大的時候，整體的拓撲其實就是一張密密麻麻的蜘蛛網。我們可以通過系統來選擇具體某個系統下的應用。

8LA中SW是5.0.0alpha版本，受限於sw功能，我們並沒有提供告警能力，這在之後會是我們的考慮目標。

問4：業務訪問日誌大概每天100G，kubernetes 環境中部署，使用穩定嗎？

答：監控資料沒有長時間的儲存必要，除非你有特定的需求。它有一定的時效性，你可以設定ttl自動清除過時資訊。100g，es叢集還是能輕鬆支撐的。

問5：和pinpoint相比有什麼優勢嗎？

答：1.部署方式、使用方式簡單

2.功能特性支援的更多

3.高併發效能會更好一些

問6：skywalking的侵入式追蹤功能方便進行單服務鏈的服務追蹤。但是跨多臺伺服器多專案的整體服務鏈追蹤是否有整體設計考慮？

答：sw本身特性就是對分散式系統的追蹤，他是無侵入式的。無關你的應用部署在多少臺伺服器上。

問7：應用在加上代理之後效能會下降。請問您有什麼解決方法嗎？

答：效能下降是在所難免的，但是據我瞭解，以及官方的測試，他的效能影響是很低的。這是sw的測試資料供你參考。

https://skywalkingtest.github.io/Agent-Benchmarks/README_zh.html。

問8：有異構系統需求的話可以用sw嗎？

答：只要skywalking的探針支援的應該都是可以的。

問9：sw對於商用的web中介軟體，如bes、tongweb、websphere、weblogic的支援如何？

答：商業元件支援的比較少，因為涉及到相關license的問題，sw專案組需要獲得他們的支援來進行資料上報，據我瞭解，支援不是很好。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2305574/，如需轉載，請註明出處，否則將追究法律責任。

相關文章