開發與維運

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

【轉載請註明出處】:https://developer.aliyun.com/article/766698

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

特性:

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

Skywalking 技術架構
image.png

整個系統分為三部分:

  • 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,則是如下:

openTracing基本結構

其中:

  • SpanContext:一個類似於MDC(Slfj)或者ThreadLocal的組件,負責整個調用鏈數據採集過程中的上下文保持和傳遞
  • Trace:一次調用的完整記錄

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

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

以一個Trace為例:

span間的關係

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

上圖是通過Span之間的依賴關係來表現一個Trace,而在時間線上,則可以有如下的表達:

span的調用順序

當然,如果是同步調用的話,父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}

image.png

【轉載請註明出處】:https://developer.aliyun.com/article/766698

Leave a Reply

Your email address will not be published. Required fields are marked *