Skywalking分散式追蹤與監控:起始篇
Skywalking是由國內開源愛好者吳晟(原OneAPM工程師,目前在華為)開源並提交到Apache孵化器的產品,它同時吸收了Zipkin/Pinpoint/CAT的設計思路,支援非侵入式埋點。是一款基於分散式跟蹤的應用程式效能監控系統。另外社群還發展出了一個叫OpenTracing的組織,旨在推進呼叫鏈監控的一些規範和標準工作。
OpenTracing
近年各種呼叫鏈監控產品層出不窮,呈現百花齊放的態勢,為了避免碎片化,促進互操作性,社群誕生了一個叫做OpenTracing的標準化組織。
如上圖所示:OpenTracing旨在標準化Trace資料結構和格式,其目的是:
不同語言開發的Trace客戶端的互操作性,Java/.Net/PHP/Python/NodeJs等語言開發的客戶端,只要遵循OpenTracing標準,就都可以對接OpenTracing相容的監控後端。
Tracing監控後端的互操作性,只要遵循OpenTracing標準,企業可以根據需要替換具體的Tracing監控後端產品,比如從Zipkin替換成Jaeger/CAT/Skywalking等後端。
OpenTracing初衷和方向是好的,但是目前還不明朗,不少呼叫鏈監控產品並未明確支援OpenTracning標準。對其後續走勢我們可以持續關注。
在構建監控系統時,大家往往在Metrics,Tracing和Logging幾個名詞和方式之間糾結。 總體說來,我們是在一些通用的名詞間糾結。可以通過圖表來定義監控的作用域,使各名詞的作用範圍更明確。比如通過維恩圖(Venn diagram)來描述Metrics, tracing, logging三個概念的定義:
‘
Metric的特點是,它是可累加的:他們具有原子性,每個都是一個邏輯計量單元,或者一個時間段內的柱狀圖。 例如:佇列的當前深度可以被定義為一個計量單元,在寫入或讀取時被更新統計; 輸入HTTP請求的數量可以被定義為一個計數器,用於簡單累加; 請求的執行時間可以被定義為一個柱狀圖,在指定時間片上更新和統計彙總。
Logging的特點是,它描述一些離散的(不連續的)事件。 例如:應用通過一個滾動的檔案輸出debug或error資訊,並通過日誌收集系統,儲存到Elasticsearch中; 審批明細資訊通過Kafka,儲存到資料庫(BigTable)中; 又或者,特定請求的元資料資訊,從服務請求中剝離出來,傳送給一個異常收集服務,如NewRelic。
Tracing的最大特點就是,它在單次請求的範圍內,處理資訊。 任何的資料、元資料資訊都被繫結到系統中的單個事務上。 例如:一次呼叫遠端服務的RPC執行過程;一次實際的SQL查詢語句;一次HTTP請求的業務性ID。
在OpenTracing中,有幾個基本概念我們需要提前瞭解清楚:
1、Trace(追蹤):
在廣義上,一個trace代表了一個事務或者流程在(分散式)系統中的執行過程。在OpenTracing標準中,trace是多個span組成的一個有向無環圖(DAG),每一個span代表trace中被命名並計時的連續性的執行片段。
2、Span(跨度):一個span代表系統中具有開始時間和執行時長的邏輯執行單元。span之間通過巢狀或者順序排列建立邏輯因果關係。
3、Logs:每個span可以進行多次Logs操作,每一次Logs操作,都需要一個帶時間戳的時間名稱,以及可選的任意大小的儲存結構。
4、Tags:每個span可以有多個鍵值對(key:value)形式的Tags,Tags是沒有時間戳的,支援簡單的對span進行註解和補充。
其中單個Trace和各個Span之間的關係:
一個span可以和一個或者多個span間存在因果關係。OpenTracing定義了兩種關係:ChildOf 和 FollowsFrom。這兩種引用型別代表了子節點和父節點間的直接因果關係。
Skywalking可以理解為實現了OpenTracing規範,同時提供了更加現代化、酷炫的UI,供人們可以對應用更加的直觀的監控。
接下來,我們將結合Skywalking的介面來了解如何檢視單個Trace:
首先,在Skywalking中,官方針對Java應用封裝了一個Segment概念,實質上就是Span陣列的封裝,為的是更好的表示Java中跨執行緒間的呼叫(後續文章將會詳細講到),因此,在Skywalking裡面,一次完整的追蹤所包含的資料結構應該是:
- Trace = Segment1 + Segment2 + ...... + SegmentN
- 其中每個Segment所包含的資料:Segment = Span1 + Span2 + ...... + SpanN
通過一張官方的截圖來講解:
圖中藍色部分是一個程序呼叫,代表的是Kafka/test-trace-topic/Consumer這個服務為呼叫入口,緊隨著下面的白色長塊則代表跨程序或跨執行緒的呼叫塊,點選進去並通過瀏覽器檢視返回的資料:
我們可以看到右側有一組spans陣列,陣列中每一組資料中都帶有traceId,segmentId,parentSegmentId,refs陣列,spanId,parentSpanId,type等資料。Skywalking介面上那些層級關聯關係就是根據這些資料來進行展示的,比如:
在同一個Segment中,spanId最頂層數值為-1,預設從0開始自增,依次代表層級。即Span與Span時間通過parentSpanId表示關係。Segment與Segment之間通過refs陣列中的parentSegmentId表示關係
好了,其實最後一段才是我想表達的東西,順帶將整個東西理清楚記錄一下,使用過程中碰到的問題會陸續記錄到這裡。
更多精彩文章可關注公眾號【OSC DevOps】
文章轉自:http://zhuanlan.zhihu.com/p/41252484
如有侵權,將第一時間刪除文章內容。
- Skywalking分散式追蹤與監控:起始篇
- 如何使用 docker 搭建 hadoop 分散式叢集?
- 開源女神節——撕掉標籤,自由隨我
- 開源女神節——她說
- 大牛告訴你專案在Devops下如何測試!
- DataOps 不僅僅是資料的 DevOps!
- K8s——master擴容
- Skywalking分散式追蹤與監控:起始篇
- 這可能是最為詳細的Docker入門吐血總結
- 2023年 DevOps 七大趨勢
- k8s部署redis叢集
- DevOps20個常見問題
- Nexu私服安裝配置,IDEA打包上傳私服
- 鵝場分散式系統DevOps自動化測試實踐
- 【雲原生】持續整合和部署(Jenkins)
- k8s部署手冊-v04
- 保護 DevOps 的 5 個技巧
- CI/CD如何支撐運維自動化
- DevOps 如何幫助實現安全部署
- K8s系列-KubeSphere