主要內容：

監控系統

隨著企業經營規模的擴大，以及對內快速診斷效率和對外服務品質的追求，對于業務系統的掌控度的要求越來越高，主要體現在：

?對于第三方依賴的監控，實時/準實時了解第三方的健康狀況/服務品質，降低第三方依賴對于自身系統的擾動(服務降級、故障轉移)。

?對于容器的監控，實時/準實時的了解應用部署環境(CPU、內存、進程、線程、網絡、帶寬)情況，以便快速擴容/縮容、流量控制、業務遷移。

?業務方對于自己的調用情況，方便作容量規劃，同時對于突發的請求也能進行異常告警和應急準備。

?自己業務的健康、性能監控，實時/準實時的了解自身的業務運行情況，排查業務瓶頸，快速診斷和定位異常，增加對自己業務的掌控力。

在這種情況下，一般都會引入APM(Application Performance Management & Monitoring)系統，通過各種探針采集數據，收集關鍵指標，同時搭配數據呈現和監控告警，能夠解決上述的大部分問題。

然而隨著RPC框架、微服務、云計算、大數據的發展，同時業務的規模和深度相比過往也都增加了很多，一次業務可能橫跨多個模塊/服務/容器，依賴的中間件也越來越多，其中任何一個節點出現異常，都可能導致業務出現波動或者異常，這就導致服務質量監控和異常診斷/定位變得異常復雜，于是催生了新的業務監控模式：調用鏈跟蹤。能夠分布式的抓取多個節點的業務記錄，并且通過統一的業務id(traceId，messageId，requestId等)將一次業務在各個節點的記錄串聯起來，方便排查業務的瓶頸或者異常點。

7.1監控目標

維度詳情

系統監控CPU,內存，磁盤，硬盤IO，系統負載等

服務監控apache,nginx,tomcat,redis,TCP連接數等

性能監控網站性能，服務器性能，數據庫性能等

日志監控訪問日志，錯誤日志等

安全監控用戶登錄數，本地文件改動，passwd文件變化等

網絡監控端口，SMTP,網絡使用率，網絡入流量，網絡出流量等

搞清楚要監控對象之后，需要監控具體哪些指標呢？通常有以下幾個業務指標需要重點監控：

?請求量

請求量監控分為兩個維度，一個是實時請求量，一個是統計請求量。實時請求量用 QPS(Queries Per Second)即每秒查詢次數來衡量，它反映了服務調用的實時變化情況。統計請求量一般用 PV(Page View)即一段時間內用戶的訪問量來衡量，比如一天的 PV 代表了服務一天的請求量，通常用來統計報表。

?響應時間

大多數情況下，可以用一段時間內所有調用的平均耗時來反映請求的響應時間。但它只代表了請求的平均快慢情況，有時候我們更關心慢請求的數量。為此需要把響應時間劃分為多個區間，比如 0～10ms、10ms～50ms、50ms～100ms、100ms～500ms、500ms 以上這五個區間，其中 500ms 以上這個區間內的請求數就代表了慢請求量，正常情況下，這個區間內的請求數應該接近于 0；在出現問題時，這個區間內的請求數會大幅增加，可能平均耗時并不能反映出這一變化。除此之外，還可以從 P90、P95、P99、P999 角度來監控請求的響應時間，比如 P99 = 500ms，意思是 99% 的請求響應時間在 500ms 以內，它代表了請求的服務質量，即 SLA。

?錯誤率

錯誤率的監控通常用一段時間內調用失敗的次數占調用總次數的比率來衡量，比如對于接口的錯誤率一般用接口返回錯誤碼為 503 的比率來表示。

7.2 APM選型

目前主要的一些APM工具有: Cat、Zipkin、Pinpoint、SkyWalking等。這里主要介紹SkyWalking，它是一款優秀的國產APM系統，被用于追蹤、監控和診斷分布式系統，特別是使用微服務架構、云原生或容積技術，可視化一體化解決方案。

它的主要特性為：

1)多種監控手段，語言探針和service mesh。

2)多語言自動探針，Java, .Net Core, PHP, NodeJS, Golang, LUA。

3)輕量高效，不需要大數據。

4)模塊化，UI、存儲、集群管理多種機制可選。

5)支持告警。

6)優秀的可視化方案。

7.3 SkyWalking

7.3.1 基礎介紹

7.3.1.1 模塊構成

SkyWalking進行了精準的領域模型劃分，共分為3個部分：

Agent：采集tracing(調用鏈數據)和metric(指標)信息并上報。

OAP：收集tracing和metric信息通過analysis core模塊將數據放入持久化容器中(ES，H2，mysql等)，并進行二次統計和監控告警。

WebApp：前后端分離，前端負責呈現，并將查詢請求封裝為graphQL提交給后端，后端通過ribbon做負載均衡轉發給OAP集群，再將查詢結果渲染展示。

7.3.1.2數據容器

由于SkyWalking并沒有自己定制的數據容器或者使用多種數據容器增加復雜度，而是主要使用ElasticSearch，所以數據容器的特性以及自己數據結構基本上就限制了業務的上限，以ES為例：

?ES查詢功能異常強大，在數據篩選方面碾壓其他所有容器，在數據篩選潛力巨大。

?支持sharding分片和replicas數據備份，在高可用/高性能/大數據支持都非常好。

?支持批量插入，高并發下的插入性能大大增強。

?數據密度低，源于ES會提前構建大量的索引來優化搜索查詢，這是查詢功能強大和性能好的代價，但是鏈路跟蹤往往有非常多的上下文需要記錄，所以SkyWalking把這些上下文二進制化然后通過Base64編碼放入data_binary字段并且將字段標記為not_analyzed來避免進行預處理建立查詢索引。

總體來說，SkyWalking盡量使用ES在大數據和查詢方面的優勢，同時盡量減少ES數據密度低的劣勢帶來的影響，從目前來看，ES在調用鏈跟蹤方面是不二的數據容器，而在數據指標方面，ES也能中規中矩的完成業務，雖然和時序數據庫相比要弱一些，但在PB級以下的數據支持也不會有太大問題。

7.3.1.3數據結構

如果說數據容器決定了上限，那么數據結構則決定了實際到達的高度。SkyWalking的數據結構主要為：

1)數據維度(ES索引為skywalking*inventory)

service：服務

instance：實例

endpoint：接口

network_adress：外部依賴

2)數據內容

原始數據

?調用鏈跟蹤數據(調用鏈的trace信息，ES索引為skywalking_segment，Skywalking主要的數據消耗都在這里)

?指標(主要是jvm或者envoy的運行時指標，例如ES索引skywalking_instance_jvm_cpu)

二次統計指標

?指標(按維度/時間二次統計出來的例如pxx、sla等指標，例如ES索引skywalking_database_access_p75_month)

?數據庫慢查詢記錄(數據庫索引：skywalking_top_n_database_statement)

關聯關系(維度/指標之間的關聯關系，ES索引為skywalking*relation_*)

總結

以上是生活随笔為你收集整理的skywalking使用方法_基于SkyWalking的监控系统安装与使用教程 PDF 下载的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。