十多年的大冶網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都全網(wǎng)營銷的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調(diào)整大冶建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“大冶網(wǎng)站設計”,“大冶網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
轉(zhuǎn)載本文需注明出處：微信公眾號EAWorld，違者必究。
引言：
微服務框架落地后，分布式部署架構帶來的問題就會迅速凸顯出來。服務之間的相互調(diào)用過程中，如果業(yè)務出現(xiàn)錯誤或者異常，如何快速定位問題？如何跟蹤業(yè)務調(diào)用鏈路？如何分析解決業(yè)務瓶頸？...本文我們來看看如何解決以上問題。
目錄：
一、SkyWalking初探
二、業(yè)務調(diào)用鏈路監(jiān)控
三、服務性能指標監(jiān)控
四、服務告警
Skywalking 簡介
Skywalking是一款國內(nèi)開源的應用性能監(jiān)控工具，支持對分布式系統(tǒng)的監(jiān)控、跟蹤和診斷。
它提供了如下的主要功能特性：
Skywalking 技術架構
SW總體可以分為四部分：
1.Skywalking Agent：使用Javaagent做字節(jié)碼植入，無侵入式的收集，并通過HTTP或者gRPC方式發(fā)送數(shù)據(jù)到Skywalking Collector。
2. Skywalking Collector ：鏈路數(shù)據(jù)收集器，對agent傳過來的數(shù)據(jù)進行整合分析處理并落入相關的數(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的相關配置。
解壓開skywalking的壓縮包，在agent/config文件夾中可以看到agent的配置文件。
從skywalking支持環(huán)境變量配置加載，在啟動的時候優(yōu)先讀取環(huán)境變量中的相關配置。
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進行數(shù)據(jù)傳輸?shù)腎P和端口
logging.level: agent記錄日志級別
skywalking agent使用javaagent無侵入式的配合collector實現(xiàn)對分布式系統(tǒng)的追蹤和相關數(shù)據(jù)的上下文傳遞。
Skywalking Collector關鍵配置
Collector支持集群部署，zookeeper、kubernetes（如果你的應用是部署在容器中的）、consul（GO語言開發(fā)的服務發(fā)現(xiàn)工具）是sw可選的集群管理工具，結合大家具體的部署方式進行選擇。詳細配置大家可以去Skywalking官網(wǎng)下載介質(zhì)包進行了解。
Collector端口設置
downsampling: 采樣匯總統(tǒng)計維度，會分別按照分鐘、【小時、天、月】（可選）來統(tǒng)計各項指標數(shù)據(jù)。
通過設置TTL相關配置項可以對數(shù)據(jù)進行自動清理。
Skywalking 在6.X中簡化了配置。collector提供了gRPC和HTTP兩種通信方式。
UI使用rest http通信，agent在大多數(shù)場景下使用grpc方式通信，在語言不支持的情況下會使用http通信。
關于綁定IP和端口需要注意的一點是，通過綁定IP，agent和collector必須配置對應ip才可以正常通信。
Collector存儲配置
在application.yml中配置的storage模塊配置中選擇要使用的數(shù)據(jù)庫類型，并填寫相關的配置信息。
Collector Receiver
Receiver是Skywalking在6.x提出的新的概念，負責從被監(jiān)控的系統(tǒng)中接受指標數(shù)據(jù)。用戶完全可以參照OpenTracing規(guī)范來上傳自定義的監(jiān)控數(shù)據(jù)。Skywalking官方提供了service-mesh、istio、zipkin的相關能力。
現(xiàn)在Skywalking支持服務端采樣，配置項為sampleRate，比例采樣，如果配置為5000則采樣率就是50%。
關于采樣設置的一點注意事項
關于服務采樣配置的一點建議，如果Collector以集群方式部署，比如：Acollector和Bcollector，建議Acollector.sampleRate = Bcollector.sampleRate。如果采樣率設置不相同可能會出現(xiàn)數(shù)據(jù)丟失問題。
假設Agent端將所有數(shù)據(jù)發(fā)送到后端Collector處，A采樣率設置為30%，B采樣率為50%。
假設有30%的數(shù)據(jù)，發(fā)送到A上，這些數(shù)據(jù)被全部正確接受并存儲，極端情況（與期望的采樣數(shù)據(jù)量相同）下，如果剩下20%待采樣的數(shù)據(jù)發(fā)送到了B，這個時候一切都是正常的，如果這20%中有一部分數(shù)據(jù)被送到了A那么，這些數(shù)據(jù)將是被忽略的，由此就會造成數(shù)據(jù)丟失。
Service Topology監(jiān)控
調(diào)用鏈路監(jiān)控可以從兩個角度去看待。我們先從整體上來認識一下我們所監(jiān)控的系統(tǒng)。
通過給服務添加探針并產(chǎn)生實際的調(diào)用之后，我們可以通過Skywalking的前端UI查看服務之間的調(diào)用關系。
我們簡單模擬一次服務之間的調(diào)用。新建兩個服務，service-provider以及service-consumer，服務之間簡單的通過Feign Client 來模擬遠程調(diào)用。
從圖中可以看到:
有兩個服務節(jié)點：provider & consumer
有一個數(shù)據(jù)庫節(jié)點：localhost【mysql】
一個注冊中心節(jié)點
consumer消費了provider提供出來的接口。
一個系統(tǒng)的拓撲圖讓我們清晰的認識到系統(tǒng)之間的應用的依賴關系以及當前狀態(tài)下的業(yè)務流轉(zhuǎn)流程。細心的可能發(fā)現(xiàn)圖示節(jié)點consumer上有一部分是紅色的，紅色是什么意思呢？
紅色代表當前流經(jīng)consumer節(jié)點的請求有一斷時間內(nèi)是響應異常的。當節(jié)點全部變紅的時候證明服務現(xiàn)階段內(nèi)就徹底不可用了。運維人員可以通過Topology迅速發(fā)現(xiàn)某一個服務潛在的問題，并進行下一步的排查并做到預防。
Skywalking Trace監(jiān)控
Skywalking通過業(yè)務調(diào)用監(jiān)控進行依賴分析，提供給我們了服務之間的服務調(diào)用拓撲關系、以及針對每個endpoint的trace記錄。
我們在之前看到consumer節(jié)點服務中發(fā)生了錯誤，讓我們一起來定位下錯誤是發(fā)生在了什么地方又是什么原因呢？
在每一條trace的信息中都可以看到當前請求的時間、GloableId、以及請求被調(diào)用的時間。我們分別看一看正確的調(diào)用和異常的調(diào)用。
Trace調(diào)用鏈路監(jiān)控
圖示展示的是一次正常的響應，這條響應總耗時19ms，它有4個span：
span1 /getStore = 19ms 響應的總流轉(zhuǎn)時間
span2 /demo2/stores = 14ms feign client 開始調(diào)用遠程服務后的響應的總時間
span3 /stores = 14ms 接口服務響應總時間
span4 Mysql = 1ms 服務提供端查詢數(shù)據(jù)庫的時間
這里span2和span3的時間表現(xiàn)相同，其實是不同的，因為這里時間取了整。
在每個Span中可以查看當前Span的相關屬性。
組件類型: SpringMVC、Feign
Span狀態(tài): false
HttpMethod: GET
Url:
http://192.168.16.125:10002/demo2/stores
這是一次正常的請求調(diào)用Trace日志，可能我們并不關心正常的時候，畢竟一切正常不就是我們期待的么！
我們再來看下，異常狀態(tài)下我們的Trace以及Span又是什么樣的呢。
發(fā)生錯誤的調(diào)用鏈中Span中的is error標識變?yōu)閠rue，并且在名為Logs的TAB中可以看到錯誤發(fā)生的具體原因。根據(jù)異常情況我們就可以輕松定位到影響業(yè)務的具體原因，從而快速定位問題，解決問題。
通過Log我們看到連接被拒，那么可能是我們的網(wǎng)絡出現(xiàn)了問題（可能性小，因為實際情況如果網(wǎng)絡出現(xiàn)問題我們連這個trace都看不到了），也有可能是服務端配置問題無法正確建立連接。通過異常日志，我們迅速就找到了問題的關鍵。
實際情況是，我把服務方停掉了，做了一次簡單的模擬?？梢?，通過拓撲圖示我們可以清晰的看到眾多服務中哪個服務是出現(xiàn)了問題的，通過trace日志我們可以很快就定位到問題所在，在最短的時間內(nèi)解決問題。
Skywalking還可以查看具體Service的性能指標，根據(jù)相關的性能指標可以分析系統(tǒng)的瓶頸所在并提出優(yōu)化方案。
Skywalking 性能監(jiān)控
在服務調(diào)用拓撲圖上點擊相應的節(jié)點我們可以看到該服務的
SLA: 服務可用性（主要是通過請求成功與失敗次數(shù)來計算）
CPM: 每分鐘調(diào)用次數(shù)
Avg Response Time: 平均響應時間
從應用整體外部來看我們可以監(jiān)測到應用在一定時間段內(nèi)的
服務可用性指標SLA
每分鐘平均響應數(shù)
平均響應時間
服務進程PID
服務所在物理機的IP、HostName、Operation System
Service JVM信息監(jiān)控
還可以監(jiān)控到Service運行時的CPU、堆內(nèi)存、非堆內(nèi)存使用率、以及GC情況。這些信息來源于JVM。注意這里的數(shù)據(jù)可不是機器本身的數(shù)據(jù)。
前文我們提到了通過查看拓撲圖以及調(diào)用鏈路可以定位問題，可是運維人員又不可能一直盯著這些數(shù)據(jù)，那么我們就需要告警能力，在異常達到一定閾值的時候主動的提示我們?nèi)ゲ榭聪到y(tǒng)狀態(tài)。
在Sywalking 6.x版本中新增了對服務狀態(tài)的告警能力。它通過webhook的方式讓我們可以自定義我們告警信息的通知方式。諸如:郵件通知、微信通知、短信通知等。
Skywalking 服務告警
先來看一下告警的規(guī)則配置。在alarm-settings.xml中可以配置告警規(guī)則，告警規(guī)則支持自定義。
一份告警配置由以下幾部分組成：
service_resp_time_rule：告警規(guī)則名稱 ***_rule （規(guī)則名稱可以自定義但是必須以’_rule’結尾
indicator-name：指標數(shù)據(jù)名稱： 定義參見http://t.cn/EGhfbmd
op: 操作符： > , < , = 【當然你可以自己擴展開發(fā)其他的操作符】
threshold：目標值：指標數(shù)據(jù)的目標數(shù)據(jù) 如sample中的1000就是服務響應時間，配合上操作符就是大于1000ms的服務響應
period: 告警檢查周期：多久檢查一次當前的指標數(shù)據(jù)是否符合告警規(guī)則
counts: 達到告警閾值的次數(shù)
silence-period：忽略相同告警信息的周期
message：告警信息
webhooks：服務告警通知服務地址
Skywalking通過HttpClient的方式遠程調(diào)用在配置項webhooks中定義的告警通知服務地址。
了解了SW所傳送的數(shù)據(jù)格式我們就可以對告警信息進行接收處理，實現(xiàn)我們需要的告警通知服務啦！
我們將一個服務停掉，并將另外一個服務的某個對外暴露的接口讓他休眠一定的時間。然后調(diào)用一定的次數(shù)觀察服務的狀態(tài)信息以及告警情況。
總結：
本文簡單的通過skwaylking的配置來對skywlaking的功能進行一次初步的了解，對skwaylking新提出的概念以及新功能進行簡單的詮釋，方便大家了解和使用。通過使用APM工具，可以讓我們方便的查看微服務架構中系統(tǒng)瓶頸以及性能問題等。
精選提問：
問1：想問問選型的時候用pinpoint還是SK好？
答：選型問題
1.要結合具體的業(yè)務場景， 比如你的代碼運行環(huán)境 是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經(jīng)過測試在并發(fā)量較高的情況下比pinpoint的吞吐量更好一些。
問2：有沒有指標統(tǒng)計，比如某個url 的top10 請求、響應最慢的10個請求？某個服務在整個鏈條中的耗時占比？
答：1.sw自帶有響應最慢的請求top10統(tǒng)計針對所有的endpoint的統(tǒng)計。
2.針對每個url的top10統(tǒng)計，sw本身沒有做統(tǒng)計，數(shù)據(jù)都是現(xiàn)成的通過簡單的檢索就可以搜到你想要的結果。
3.沒有具體的耗時占比，但是有具體總鏈路時間統(tǒng)計以及某個服務的耗時統(tǒng)計，至于占比自己算吧，可以看ppt中的調(diào)用鏈路監(jiān)控的span時間解釋。
問3：能不能具體說一下在你們系統(tǒng)中的應用？
答：EOS8LA版本中，我們整合sw對應用提供拓撲、調(diào)用鏈路、性能指標的監(jiān)控、并在sw數(shù)據(jù)的基礎上增加系統(tǒng)的維度。
當服務數(shù)很龐大的時候，整體的拓撲其實就是一張密密麻麻的蜘蛛網(wǎng)。我們可以通過系統(tǒng)來選擇具體某個系統(tǒng)下的應用。
8LA中SW是5.0.0alpha版本，受限于sw功能，我們并沒有提供告警能力，這在之后會是我們的考慮目標。
問4：業(yè)務訪問日志大概每天100G，kubernetes 環(huán)境中部署，使用穩(wěn)定嗎？
答：監(jiān)控數(shù)據(jù)沒有長時間的存儲必要，除非你有特定的需求。它有一定的時效性，你可以設置ttl自動清除過時信息。100g，es集群還是能輕松支撐的。
問5：和pinpoint相比有什么優(yōu)勢嗎？
答：1.部署方式、使用方式簡單
2.功能特性支持的更多
3.高并發(fā)性能會更好一些
問6：skywalking的侵入式追蹤功能方便進行單服務鏈的服務追蹤。但是跨多臺服務器多項目的整體服務鏈追蹤是否有整體設計考慮？
答：sw本身特性就是對分布式系統(tǒng)的追蹤，他是無侵入式的。無關你的應用部署在多少臺服務器上。
問7：應用在加上代理之后性能會下降。請問您有什么解決方法嗎？
答：性能下降是在所難免的，但是據(jù)我了解，以及官方的測試，他的性能影響是很低的。這是sw的測試數(shù)據(jù)供你參考。
https://skywalkingtest.github.io/Agent-Benchmarks/README_zh.html。
問8：有異構系統(tǒng)需求的話可以用sw嗎？
答：只要skywalking的探針支持的應該都是可以的。
問9：sw對于商用的web中間件，如bes、tongweb、websphere、weblogic的支持如何？
答：商業(yè)組件支持的比較少，因為涉及到相關license的問題，sw項目組需要獲得他們的支持來進行數(shù)據(jù)上報，據(jù)我了解，支持不是很好。
重慶分公司
重慶分公司
