摘要:是推出的一款開源分布式追蹤系統(tǒng),兼容。借助阿里云日志服務(wù)的海量數(shù)據(jù)處理能力,讓您享受在分布式追蹤領(lǐng)域給您帶來便捷的同時(shí)無需過多關(guān)注后端存儲(chǔ)系統(tǒng)的問題。部分僅提供查詢展示的功能,對分析問題排查問題支持不足。
摘要: 分布式系統(tǒng)的運(yùn)維挑戰(zhàn) 容器、Serverless 編程方式的誕生極大提升了軟件交付與部署的效率。在架構(gòu)的演化過程中,可以看到兩個(gè)變化: 應(yīng)用架構(gòu)開始從單體系統(tǒng)逐步轉(zhuǎn)變?yōu)槲⒎?wù),其中的業(yè)務(wù)邏輯隨之而來就會(huì)變成微服務(wù)之間的調(diào)用與請求。
點(diǎn)此查看原文:http://click.aliyun.com/m/43347/
分布式系統(tǒng)的運(yùn)維挑戰(zhàn)
容器、Serverless 編程方式的誕生極大提升了軟件交付與部署的效率。在架構(gòu)的演化過程中,可以看到兩個(gè)變化:
1.應(yīng)用架構(gòu)開始從單體系統(tǒng)逐步轉(zhuǎn)變?yōu)槲⒎?wù),其中的業(yè)務(wù)邏輯隨之而來就會(huì)變成微服務(wù)之間的調(diào)用與請求。
2.資源角度來看,傳統(tǒng)服務(wù)器這個(gè)物理單位也逐漸淡化,變成了看不見摸不到的虛擬資源模式。
從以上兩個(gè)變化可以看到這種彈性、標(biāo)準(zhǔn)化的架構(gòu)背后,原先運(yùn)維與診斷的需求也變得越來越復(fù)雜。為了應(yīng)對這種變化趨勢,誕生一系列面向 DevOps 的診斷與分析系統(tǒng),包括集中式日志系統(tǒng)(Logging),集中式度量系統(tǒng)(Metrics)和分布式追蹤系統(tǒng)(Tracing)。
Logging,Metrics 和 Tracing
Logging,Metrics 和 Tracing 有各自專注的部分。
1.Logging - 用于記錄離散的事件。例如,應(yīng)用程序的調(diào)試信息或錯(cuò)誤信息。它是我們診斷問題的依據(jù)。
2.Metrics - 用于記錄可聚合的數(shù)據(jù)。例如,隊(duì)列的當(dāng)前深度可被定義為一個(gè)度量值,在元素入隊(duì)或出隊(duì)時(shí)被更新;HTTP 請求個(gè)數(shù)可被定義為一個(gè)計(jì)數(shù)器,新請求到來時(shí)進(jìn)行累加。
3.Tracing - 用于記錄請求范圍內(nèi)的信息。例如,一次遠(yuǎn)程方法調(diào)用的執(zhí)行過程和耗時(shí)。它是我們排查系統(tǒng)性能問題的利器。
這三者也有相互重疊的部分,如下圖所示。
通過上述信息,我們可以對已有系統(tǒng)進(jìn)行分類。例如,Zipkin 專注于 tracing 領(lǐng)域;Prometheus 開始專注于 metrics,隨著時(shí)間推移可能會(huì)集成更多的 tracing 功能,但不太可能深入 logging 領(lǐng)域; ELK,阿里云日志服務(wù)這樣的系統(tǒng)開始專注于 logging 領(lǐng)域,但同時(shí)也不斷地集成其他領(lǐng)域的特性到系統(tǒng)中來,正向上圖中的圓心靠近。
關(guān)于三者關(guān)系的更詳細(xì)信息可參考 Metrics, tracing, and logging。下面我們重點(diǎn)介紹下 tracing。
Tracing 的誕生
Tracing 是在90年代就已出現(xiàn)的技術(shù)。但真正讓該領(lǐng)域流行起來的還是源于 Google 的一篇論文"Dapper, a Large-Scale Distributed Systems Tracing Infrastructure",而另一篇論文"Uncertainty in Aggregate Estimates from Sampled Distributed Traces"中則包含關(guān)于采樣的更詳細(xì)分析。論文發(fā)表后一批優(yōu)秀的 Tracing 軟件孕育而生,比較流行的有:
Dapper(Google) : 各 tracer 的基礎(chǔ)
StackDriver Trace (Google)
Zipkin(twitter)
Appdash(golang)
鷹眼(taobao)
諦聽(盤古,阿里云云產(chǎn)品使用的Trace系統(tǒng))
云圖(螞蟻Trace系統(tǒng))
sTrace(神馬)
X-ray(aws)
分布式追蹤系統(tǒng)發(fā)展很快,種類繁多,但核心步驟一般有三個(gè):代碼埋點(diǎn),數(shù)據(jù)存儲(chǔ)、查詢展示。
下圖是一個(gè)分布式調(diào)用的例子,客戶端發(fā)起請求,請求首先到達(dá)負(fù)載均衡器,接著經(jīng)過認(rèn)證服務(wù),計(jì)費(fèi)服務(wù),然后請求資源,最后返回結(jié)果。
數(shù)據(jù)被采集存儲(chǔ)后,分布式追蹤系統(tǒng)一般會(huì)選擇使用包含時(shí)間軸的時(shí)序圖來呈現(xiàn)這個(gè) Trace。
但在數(shù)據(jù)采集過程中,由于需要侵入用戶代碼,并且不同系統(tǒng)的 API 并不兼容,這就導(dǎo)致了如果您希望切換追蹤系統(tǒng),往往會(huì)帶來較大改動(dòng)。
OpenTracing
為了解決不同的分布式追蹤系統(tǒng) API 不兼容的問題,誕生了 OpenTracing 規(guī)范。
OpenTracing 是一個(gè)輕量級的標(biāo)準(zhǔn)化層,它位于應(yīng)用程序/類庫和追蹤或日志分析程序之間。
OpenTracing 的優(yōu)勢
OpenTracing 已進(jìn)入 CNCF,正在為全球的分布式追蹤,提供統(tǒng)一的概念和數(shù)據(jù)標(biāo)準(zhǔn)。
OpenTracing 通過提供平臺(tái)無關(guān)、廠商無關(guān)的 API,使得開發(fā)人員能夠方便的添加(或更換)追蹤系統(tǒng)的實(shí)現(xiàn)。
OpenTracing 數(shù)據(jù)模型
OpenTracing 中的 Trace(調(diào)用鏈)通過歸屬于此調(diào)用鏈的 Span 來隱性的定義。
特別說明,一條 Trace(調(diào)用鏈)可以被認(rèn)為是一個(gè)由多個(gè) Span 組成的有向無環(huán)圖(DAG圖),Span 與 Span 的關(guān)系被命名為 References。
例如:下面的示例 Trace 就是由8個(gè) Span 組成:
有些時(shí)候,使用下面這種,基于時(shí)間軸的時(shí)序圖可以更好的展現(xiàn) Trace(調(diào)用鏈):
每個(gè) Span 包含以下的狀態(tài):(譯者注:由于這些狀態(tài)會(huì)反映在 OpenTracing API 中,所以會(huì)保留部分英文說明)
An operation name,操作名稱
A start timestamp,起始時(shí)間
A finish timestamp,結(jié)束時(shí)間
Span Tag,一組鍵值對構(gòu)成的 Span 標(biāo)簽集合。鍵值對中,鍵必須為 string,值可以是字符串,布爾,或者數(shù)字類型。
Span Log,一組 span 的日志集合。
每次 log 操作包含一個(gè)鍵值對,以及一個(gè)時(shí)間戳。
鍵值對中,鍵必須為 string,值可以是任意類型。
但是需要注意,不是所有的支持 OpenTracing 的 Tracer,都需要支持所有的值類型。
SpanContext,Span 上下文對象 (下面會(huì)詳細(xì)說明)
References(Span間關(guān)系),相關(guān)的零個(gè)或者多個(gè) Span(Span 間通過 SpanContext 建立這種關(guān)系)
每一個(gè) SpanContext 包含以下狀態(tài):
任何一個(gè) OpenTracing 的實(shí)現(xiàn),都需要將當(dāng)前調(diào)用鏈的狀態(tài)(例如:trace 和 span 的 id),依賴一個(gè)獨(dú)特的 Span 去跨進(jìn)程邊界傳輸
Baggage Items,Trace 的隨行數(shù)據(jù),是一個(gè)鍵值對集合,它存在于 trace 中,也需要跨進(jìn)程邊界傳輸
更多關(guān)于 OpenTracing 數(shù)據(jù)模型的知識(shí),請參考 OpenTracing語義標(biāo)準(zhǔn)。
OpenTracing 實(shí)現(xiàn)
這篇文檔列出了所有 OpenTracing 實(shí)現(xiàn)。在這些實(shí)現(xiàn)中,比較流行的為 Jaeger 和 Zipkin。
Jaeger
Jaeger 是 Uber 推出的一款開源分布式追蹤系統(tǒng),兼容 OpenTracing API。
Jaeger 架構(gòu)
如上圖所示,Jaeger 主要由以下幾部分組成。
1.Jaeger Client - 為不同語言實(shí)現(xiàn)了符合 OpenTracing 標(biāo)準(zhǔn)的 SDK。應(yīng)用程序通過 API 寫入數(shù)據(jù),client library 把 trace 信息按照應(yīng)用程序指定的采樣策略傳遞給 jaeger-agent。
2.Agent - 它是一個(gè)監(jiān)聽在 UDP 端口上接收 span 數(shù)據(jù)的網(wǎng)絡(luò)守護(hù)進(jìn)程,它會(huì)將數(shù)據(jù)批量發(fā)送給 collector。它被設(shè)計(jì)成一個(gè)基礎(chǔ)組件,部署到所有的宿主機(jī)上。Agent 將 client library 和 collector 解耦,為 client library 屏蔽了路由和發(fā)現(xiàn) collector 的細(xì)節(jié)。
3.Collector - 接收 jaeger-agent 發(fā)送來的數(shù)據(jù),然后將數(shù)據(jù)寫入后端存儲(chǔ)。Collector 被設(shè)計(jì)成無狀態(tài)的組件,因此您可以同時(shí)運(yùn)行任意數(shù)量的 jaeger-collector。
4.Data Store - 后端存儲(chǔ)被設(shè)計(jì)成一個(gè)可插拔的組件,支持將數(shù)據(jù)寫入 cassandra、elastic search。
5.Query - 接收查詢請求,然后從后端存儲(chǔ)系統(tǒng)中檢索 trace 并通過 UI 進(jìn)行展示。Query 是無狀態(tài)的,您可以啟動(dòng)多個(gè)實(shí)例,把它們部署在 nginx 這樣的負(fù)載均衡器后面。
Jaeger 存在的問題
需要架設(shè)并維護(hù)存儲(chǔ)。
UI比較薄弱,有一些個(gè)性化的分析需求無法快速滿足(例如對比,統(tǒng)計(jì)延遲分布等)。
Jaeger on Aliyun Log Service
Jaeger on Aliyun Log Service 是基于 Jeager 開發(fā)的分布式追蹤系統(tǒng),支持將采集到的追蹤數(shù)據(jù)持久化到日志服務(wù)中,并通過 Jaeger 的原生接口進(jìn)行查詢和展示。
優(yōu)勢
原生 Jaeger 僅支持將數(shù)據(jù)持久化到 cassandra 和 elasticsearch 中,用戶需要自行維護(hù)后端存儲(chǔ)系統(tǒng)的穩(wěn)定性,調(diào)節(jié)存儲(chǔ)容量。Jaeger on Aliyun Log Service 借助阿里云日志服務(wù)的海量數(shù)據(jù)處理能力,讓您享受 Jaeger 在分布式追蹤領(lǐng)域給您帶來便捷的同時(shí)無需過多關(guān)注后端存儲(chǔ)系統(tǒng)的問題。
Jaeger UI 部分僅提供查詢、展示 trace 的功能,對分析問題、排查問題支持不足。使用 Jaeger on Aliyun Log Service,您可以借助日志服務(wù)強(qiáng)大的查詢分析能力,助您更快分析出系統(tǒng)中存在的問題。
相對于 Jaeger 使用 elasticsearch 作為后端存儲(chǔ),使用日志服務(wù)的好處是支持按量付費(fèi),成本僅為 elasticsearch 的13%。
配置步驟
參閱:https://github.com/aliyun/jae...
使用實(shí)例
HotROD 是由多個(gè)微服務(wù)組成的應(yīng)用程序,它使用了 OpenTracing API 記錄 trace 信息。
參考資料
Jaeger on Aliyun Log Service - https://github.com/aliyun/jaeger
OpenTracing 中文文檔 - https://wu-sheng.gitbooks.io/...
Jaeger - http://jaeger.readthedocs.io/...
OpenTracing tutorial - https://github.com/yurishkuro...
http://peter.bourgon.org/blog...
特別感謝
Jaeger on Aliyun Log Service 是基于阿里云MVP @WPH95 在業(yè)余時(shí)間工作整理而成,感謝 MVP
的杰出貢獻(xiàn)!
識(shí)別以下二維碼,閱讀更多干貨
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://www.ezyhdfw.cn/yun/11829.html
摘要:簡單理解一個(gè)完整的調(diào)用鏈包含無限極分類追蹤對象,一個(gè)代表了一個(gè)服務(wù)或者流程在系統(tǒng)中的執(zhí)行過程,如,,等執(zhí)行過程。無限極分類服務(wù)與服務(wù)之間使用無限極分類的方式,通過頭部或者請求地址傳輸?shù)阶畹蛯?,從而把整個(gè)調(diào)用鏈串起來。 showImg(https://segmentfault.com/img/remote/1460000011636962?w=2239&h=1202); 原文:Uber分...
摘要:典型實(shí)現(xiàn)不同的監(jiān)控模塊,側(cè)重于不同領(lǐng)域,有著不同的職責(zé)。指標(biāo)收集方面,支持多樣化的組件將被優(yōu)先下使用。以上談了這么多,僅僅是聊了一下收集方面而已。 更多文章,請移步微信公眾號《小姐姐味道》 mp原文 https://mp.weixin.qq.com/s?__...監(jiān)控是分布式系統(tǒng)的必備組件,能夠起到提前預(yù)警、問題排查、評估決策等功效,乃行走江湖、居家必備之良品。 監(jiān)控系統(tǒng)概要 功能劃分...
摘要:典型實(shí)現(xiàn)不同的監(jiān)控模塊,側(cè)重于不同領(lǐng)域,有著不同的職責(zé)。指標(biāo)收集方面,支持多樣化的組件將被優(yōu)先下使用。以上談了這么多,僅僅是聊了一下收集方面而已。 更多文章,請移步微信公眾號《小姐姐味道》 mp原文 https://mp.weixin.qq.com/s?__...監(jiān)控是分布式系統(tǒng)的必備組件,能夠起到提前預(yù)警、問題排查、評估決策等功效,乃行走江湖、居家必備之良品。 監(jiān)控系統(tǒng)概要 功能劃分...
摘要:分布式鏈路追蹤現(xiàn)狀分布式鏈路追蹤的技術(shù)有很多,有開源的也有閉源的。個(gè)推的實(shí)踐個(gè)推的微服務(wù)是基于和進(jìn)行部署的,每個(gè)微服務(wù)對應(yīng)于中的一組。整體的架構(gòu)如下圖所示個(gè)推基于的分布式鏈路追蹤系統(tǒng)的整體架構(gòu)其中,也容器化部署在集群中,簡化了的搭建和部署。 showImg(https://segmentfault.com/img/remote/1460000019343537);作者:個(gè)推應(yīng)用平臺(tái)基礎(chǔ)...
閱讀 3052·2021-11-23 09:51
閱讀 3066·2021-11-02 14:46
閱讀 922·2021-11-02 14:45
閱讀 2877·2021-09-23 11:57
閱讀 2554·2021-09-23 11:22
閱讀 1999·2019-08-29 16:29
閱讀 803·2019-08-29 16:16
閱讀 1007·2019-08-26 13:44