用SkyWalking作分佈式追蹤和應用性能監控系統

【轉載請註明出處】：http://www.javashuo.com/article/p-kfelrwfm-nq.html

SkyWalking 是觀察性分析平臺和應用性能管理系統。提供分佈式追蹤、服務網格遙測分析、度量聚合和可視化一體化解決方案。

特性：

• 多種監控手段，語言探針和service mesh
• 多語言自動探針，Java，.NET Core和Node.JS
• 輕量高效，不須要大數據
• 模塊化，UI、存儲、集羣管理多種機制可選
• 支持告警
• 優秀的可視化方案

Skywalking 技術架構

整個系統分爲三部分：

• agent：採集tracing（調用鏈數據）和metric（指標）信息並上報
• OAP：收集tracing和metric信息經過analysis core模塊將數據放入持久化容器中（ES，H2（內存數據庫），mysql等等），並進行二次統計和監控告警
• webapp：先後端分離，前端負責呈現，並將查詢請求封裝爲graphQL提交給後端，後端經過ribbon作負載均衡轉發給OAP集羣，再將查詢結果渲染展現

Skywalking也提供了其餘的一些特性：

• 配置重載：支持經過jvm參數覆寫默認配置，支持動態配置管理
• 集羣管理：這個主要體如今OAP，經過集羣部署分擔數據上報的流量壓力和二次計算的計算壓力，同時集羣也能夠經過配置切換角色，分別面向數據採集（collector）和計算（aggregator，alarm），須要注意的是agent目前不支持多collector負載均衡，而是隨機從集羣中選擇一個實例進行數據上報
• 支持k8s和mesh
• 支持數據容器的擴展，例如官方主推是ES，經過擴展接口，也能夠實現插件去- - 支持其餘的數據容器
• 支持數據上報receiver的擴展，例如目前主要是支持gRPC接受agent的上報，可是也能夠實現插件支持其餘類型的數據上報（官方默認實現了對Zipkin，telemetry和envoy的支持）
• 支持客戶端採樣和服務端採樣，不過服務端採樣最有意義
• 官方制定了一個數據查詢腳本規範：OAL（Observability Analysis Language），語法相似Linq，以簡化數據查詢擴展的工做量
• 支持監控預警，經過OAL獲取數據指標和閾值進行對比來觸發告警，支持webhook擴展告警方式，支持統計週期的自定義，以及告警靜默防止重複告警

數據容器

因爲Skywalking並無本身定製的數據容器或者使用多種數據容器增長複雜度，而是主要使用ElasticSearch（固然開源的基本上都是這樣來保持簡潔，例如Pinpoint也只使用了HBase），因此數據容器的特性以及本身數據結構基本上就限制了業務的上限，以ES爲例：

• ES查詢功能異常強大，在數據篩選方面碾壓其餘全部容器，在數據篩選潛力巨大（Skywalking默認的查詢維度就比使用HBase的Pinpoint強不少）
• 支持sharding分片和replicas數據備份，在高可用/高性能/大數據支持都很是好
• 支持批量插入，高併發下的插入性能大大加強
• 數據密度低，源於ES會提早構建大量的索引來優化搜索查詢，這是查詢功能強大和性能好的代價，可是鏈路跟蹤每每有很是多的上下文須要記錄，因此Skywalking把這些上下文二進制化而後經過Base64編碼放入data_binary字段而且將字段標記爲not_analyzed來避免進行預處理創建查詢索引

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

數據結構

若是說數據容器決定了上限，那麼數據結構則決定了實際到達的高度。Skywalking的數據結構主要爲：

• 數據維度（ES索引爲skywalking_*_inventory)

  1. service：服務
  2. instance：實例
  3. endpoint：接口
  4. network_adress：外部依賴

• 數據內容

  1. 原始數據

     • 調用鏈跟蹤數據（調用鏈的trace信息，ES索引爲skywalking_segment，Skywalking主要的數據消耗都在這裏）
     • 指標（主要是jvm或者envoy的運行時指標，例如ES索引skywalking_instance_jvm_cpu）

  2. 二次統計指標

     • 指標（按維度/時間二次統計出來的例如pxx、sla等指標，例如ES索引skywalking_database_access_p75_month）
     • 數據庫慢查詢記錄（數據庫索引：skywalking_top_n_database_statement）
  3. 關聯關係（維度/指標之間的關聯關係，ES索引爲skywalking_relation)

  4. 特別記錄

     • 告警信息（ES索引爲skywalking_alarm_record）
     • 併發控制（ES索引爲skywalking_register_lock）

其中數量佔比最大的就是調用鏈跟蹤數據和各類指標，而這些數據都可以經過OAP設置過時時間，以下降歷史數據的對磁盤佔用和查詢效率的影響。

調用鏈跟蹤數據

做爲Skywalking的核心數據，調用鏈跟蹤數據（skywalking_segment）基本上奠基了整個系統的基礎，而若是要詳細的瞭解調用鏈跟蹤的話，就不得不提到openTracing。

openTracing基本上是目前開源調用鏈跟蹤系統的一個事實標準，它制定了調用鏈跟蹤的基本流程和基本的數據結構，同時也提供了各個語言的實現。若是用一張圖來表現openTracing，則是以下：

其中：

• SpanContext：一個相似於MDC（Slfj)或者ThreadLocal的組件，負責整個調用鏈數據採集過程當中的上下文保持和傳遞

• Trace：一次調用的完整記錄

  • Span：一次調用中的某個節點/步驟，相似於一層堆棧信息，Trace是由多個Span組成，Span和Span之間也有父子或者並列的關係來標誌這個節點/步驟在整個調用中的位置

    • Tag：節點/步驟中的關鍵信息
    • Log：節點/步驟中的詳細記錄，例如異常時的異常堆棧
  • Baggage：和SpanContext同樣並不屬於數據結構而是一種機制，主要用於跨Span或者跨實例的上下文傳遞，Baggage的數據更可能是用於運行時，而不會進行持久化

以一個Trace爲例：

首先是外部請求調用A，而後A依次同步調用了B和C，而B被調用時會去同步調用D，C被調用的時候會依次同步調用E和F，F被調用的時候會經過異步調用G，G則會異步調用H，最終完成一次調用。

上圖是經過Span之間的依賴關係來表現一個Trace，而在時間線上，則能夠有以下的表達：

固然，若是是同步調用的話，父Span的時間佔用是包括子Span的時間消耗的。

而落地到Skywalking中，咱們以一條skywalking_segment的記錄爲例：

{
    "trace_id": "52.70.15530767312125341",
    "endpoint_name": "Mysql/JDBI/Connection/commit",
    "latency": 0,
    "end_time": 1553076731212,
    "endpoint_id": 96142,
    "service_instance_id": 52,
    "version": 2,
    "start_time": 1553076731212,
    "data_binary": "CgwKCjRGnPvp5eikyxsSXhD///////////8BGMz62NSZLSDM+tjUmS0wju8FQChQAVgBYCF6DgoHZGIudHlwZRIDc3FsehcKC2RiLmluc3RhbmNlEghyaXNrZGF0YXoOCgxkYi5zdGF0ZW1lbnQYAiA0",
    "service_id": 2,
    "time_bucket": 20190320181211,
    "is_error": 0,
    "segment_id": "52.70.15530767312125340"
}

其中：

• trace_id：本次調用的惟一id，經過snowflake模式生成
• endpoint_name：被調用的接口
• latency：耗時
• end_time：結束時間戳
• endpoint_id：被調用的接口的惟一id
• service_instance_id：被調用的實例的惟一id
• version：本數據結構的版本號
• start_time：開始時間戳
• data_binary：裏面保存了本次調用的全部Span的數據，序列化並用Base64編碼，不會進行分析和用於查詢
• service_id：服務的惟一id
• time_bucket：調用所處的時段
• is_error：是否失敗
• segment_id：數據自己的惟一id，相似於主鍵，經過snowflake模式生成

這裏能夠看到，目前Skywalking雖然相較於Pinpoint來講查詢的維度要多一些，可是也頗有限，並且除了endPoint，並無和業務有關聯的字段，只能經過時間/服務/實例/接口/成功標誌/耗時來進行非業務相關的查詢，若是後續要加強業務相關的搜索查詢的話，應該還須要增長一些用於保存動態內容（如messageId，orderId等業務關鍵字）的字段用於快速定位

指標

指標數據相對於Tracing則要簡單得多了，通常來講就是指標標誌、時間戳、指標值，而Skywalking中的指標有兩種：一種是採集的原始指標值，例如jvm的各類運行時指標（例如cpu消耗、內存結構、GC信息等）；一種是各類二次統計指標（例如tp性能指標、SLA等，固然也有爲了便於查詢的更高時間維度的指標，例如基於分鐘、小時、天、周、月）

例如如下是索引skywalking_endpoint_cpm_hour中的一條記錄，用於標誌一個小時內某個接口的cpm指標：

{
    "total": 8900,
    "service_id": 5,
    "time_bucket": 2019031816,
    "service_instance_id": 5,
    "entity_id": "7",
    "value": 148
}

各個字段的釋義以下：

• total：一分鐘內的調用總量
• service_id：所屬服務的惟一id
• time_bucket：統計的時段
• service_instance_id：所屬實例的惟一id
• entity_id：接口（endpoint）的惟一id
• value：cpm的指標值（cpm=call per minute，即total/60）

agent

agent（apm-sniffer）是Skywalking的Java探針實現，主要負責：

• 採集應用實例的jvm指標
• 經過切向編程進行數據埋點，採集調用鏈數據
• 經過RPC將採集的數據上報

固然，agent還實現了客戶端採樣，不過在APM監控系統裏進行客戶端數據採樣都是沒有靈魂的，因此這裏就再也不贅述了。

首先，agent經過 org.apache.skywalking.apm.agent.core.boot.BootService 實現了總體的插件化，agent啓動會加載全部的BootService實現，並經過 ServiceManager 來管理這些插件的生命週期，採集jvm指標、gRPC鏈接管理、調用鏈數據維護、數據上報OAP這些服務均是經過這種方式擴展。

而後，agent還經過bytebuddy以javaagent的模式，經過字節碼加強的機制來構造AOP環境，再提供PluginDefine的規範方便探針的開發，最終實現非侵入性的數據埋點，採集調用鏈數據。

OAP

同agent相似，OAP做爲Skywalking最核心的模塊，也實現了本身的擴展機制，不過在這裏叫作Module，具體能夠參考library-module，在module的機制下，Skywalking實現了本身必須核心組件：

• core：整個OAP核心業務（remoting、cluster、storage、analysis、query、alarm）的規範和接口
• cluster：集羣管理的具體實現
• storage：數據容器的具體實現
• query：爲前端提供的查詢接口的具體實現
• receiver：接收探針上報數據的接收器的具體實現
• alarm：監控告警的具體實現

以及一個可選組件：

• telemetry：用於監控OAP自身的健康情況

而前面提到的OAP的高擴展性則體如今核心業務的規範均定義在了core中，若是有須要本身擴展的，只須要本身單獨作本身的實現，而不須要作侵入式的改動，最典型的示例則是官方支持的storage，不只支持單機demo的內存數據庫H2和經典的ES，連目前開源的Tidb均可以接入。

安裝

1. 下載最新的安裝包
2. 解壓，並進入bin目錄執行startup.sh啓動
3. 訪問http://localhost:8080/ 便可看到面板
4. 啓動服務
   添加以下VM 參數：

-javaagent:${agent_home}/agent/skywalking-agent.jar -Dskywalking.agent.service_name=${service_name}

【轉載請註明出處】：http://www.javashuo.com/article/p-kfelrwfm-nq.html