Opentelemetry 調(diào)研實(shí)踐一(可觀測(cè)性到底在說(shuō)什么)

可觀測(cè)性(Observability)并不是一個(gè)新詞，而在幾十年前被廣泛地用于控制理論，用它來(lái)描述和理解?我調(diào)節(jié)系統(tǒng)。隨著容器技術(shù)、微服務(wù)、?服務(wù)器迅速流行，使得系統(tǒng)間的訪問(wèn)越來(lái)越復(fù)雜，在云上、本地或兩者上可能會(huì)運(yùn)?數(shù)千個(gè)進(jìn)程， 使用傳統(tǒng)的監(jiān)控技術(shù)和?具很難跟蹤這些分布式架構(gòu)中的通信路徑和相互依賴關(guān)系。系統(tǒng)內(nèi)部的可見(jiàn)性就變得非常重要。

那可觀測(cè)性到底在說(shuō)什么呢?

思考

1. 你的應(yīng)用真的是可觀測(cè)的嗎？
2. 日志系統(tǒng)只是用于查詢?nèi)罩镜膯幔袥](méi)有可能日志系統(tǒng)與監(jiān)控系統(tǒng)是聯(lián)動(dòng)的？
3. 可以很容易統(tǒng)計(jì)一條請(qǐng)求的總耗時(shí)，但如何統(tǒng)計(jì)具體某個(gè)函數(shù)的執(zhí)行時(shí)間、該函數(shù)調(diào)用次數(shù)?

上述 3 個(gè)問(wèn)題如果你都能出”Yes”回答，那么作者建議直接滑走不用看下文。

如果你脫口而出，不就是日志平臺(tái)跟監(jiān)控系統(tǒng)能解決嗎？

對(duì)，其實(shí)也不對(duì)

好，首先來(lái)說(shuō)明一下可觀測(cè)性跟監(jiān)控系統(tǒng)的一些區(qū)別

問(wèn)題域

可觀測(cè)性跟監(jiān)控系統(tǒng)確實(shí)很像，可觀測(cè)性跟監(jiān)控系統(tǒng)本質(zhì)上是一樣的，都是在解決一個(gè)問(wèn)題，：度量你的基礎(chǔ)設(shè)施、平臺(tái)和應(yīng)用程序，以了解它是如何運(yùn)行。

但兩者的問(wèn)題域卻完全不同，監(jiān)控告訴我們系統(tǒng)的哪些部分是工作的,可觀測(cè)性告訴我們那里為什么不工作了.

度量,是個(gè)程度可深可淺的詞，比如回到問(wèn)題一: 你的應(yīng)用是可觀測(cè)的嗎,很多人會(huì)給出肯定的回答，在某些人的理解中，不就是監(jiān)控應(yīng)用的狀態(tài)嗎？對(duì)于 k8s 應(yīng)用來(lái)講，prometheus 就可以開(kāi)箱即用地監(jiān)控它，沒(méi)錯(cuò)，狀態(tài)是能夠被監(jiān)控的，通過(guò)監(jiān)控系統(tǒng)我們可以知道某個(gè)時(shí)刻it works

但是這個(gè)應(yīng)用是可觀測(cè)的嗎？當(dāng)然不是，因它在出現(xiàn)問(wèn)題的時(shí)候，通過(guò)監(jiān)控系統(tǒng)可能沒(méi)辦法判斷它在哪個(gè)函數(shù)中 crash 了

如果要知道它哪里出了問(wèn)題，那么就需要在應(yīng)用內(nèi)部實(shí)現(xiàn)可見(jiàn)性，通過(guò)埋點(diǎn)或者是字節(jié)碼注入的方式，讓?xiě)?yīng)用暴露它的業(yè)務(wù)、性能指標(biāo)，比如函數(shù)的時(shí)延、調(diào)用次數(shù)、調(diào)用錯(cuò)誤等，借助這些指標(biāo)再結(jié)合旁路分析系統(tǒng)就可以很清晰地展現(xiàn)應(yīng)用的全貌。

這就屬于可觀測(cè)性

三板斧

logging、trace、metrics 是實(shí)現(xiàn)可觀測(cè)性的三板斧,每一個(gè)都有很多的解決方案可選，

Logging 中使用較多的有 EFK、loki

Trace 中有 Jaeger、Tempo

Metrics 中有 Prometheus，Netdata

通過(guò)這些工具收集的數(shù)據(jù)統(tǒng)稱(chēng)為遙測(cè)數(shù)據(jù)

這些工具基本開(kāi)箱即用的特性，作者相信給很多企業(yè)帶來(lái)了便利性。

想用好這三個(gè)工具業(yè)界還是有一些指導(dǎo)思想的，對(duì)于 logging 跟 metrics 很多人會(huì)相對(duì)熟悉一些，作者在這里想簡(jiǎn)單說(shuō)一說(shuō) trace，trace 一般為全鏈路追蹤，表示請(qǐng)求通過(guò)分布式系統(tǒng)的端到端的過(guò)程， trace 有兩個(gè)很重要的屬性:

1. TraceID: 一次請(qǐng)求中的所有路徑都會(huì)共用一個(gè)唯一的 TraceID，這個(gè) TraceID 一般由初始節(jié)點(diǎn)產(chǎn)生，然后傳遞到所有節(jié)點(diǎn)
2. SpanID: TraceID 只能夠串起所有節(jié)點(diǎn)，但節(jié)點(diǎn)之間的調(diào)用順序需要由 SpanID 來(lái)產(chǎn)生

由于篇幅有限，trace 將做為后續(xù)文章介紹的重點(diǎn)，不在這里展開(kāi)

為什么

為什么要實(shí)現(xiàn)可觀測(cè)性呢?

可能有些人會(huì)提出: 我沒(méi)有做任何可觀測(cè)性方面的工作，系統(tǒng)也一直work fine呢

確實(shí)，在小公司或者系統(tǒng)不那么復(fù)雜的情況下，落地可觀測(cè)性是有成本的，畢竟需要花人力物力去搭建那么些系統(tǒng)同時(shí)需要有可運(yùn)維能力

但是如果業(yè)務(wù)鏈路足夠長(zhǎng)、邏輯足夠復(fù)雜，長(zhǎng)遠(yuǎn)來(lái)看，可觀測(cè)性的落地是非常有必要的，有以下幾點(diǎn)原因:

1. 現(xiàn)在到處吹捧云原生，從純技術(shù)角度上來(lái)說(shuō)，實(shí)現(xiàn)可觀測(cè)性是趨勢(shì)，也是技術(shù)追求
2. 整個(gè)架構(gòu)的可觀測(cè)性對(duì)開(kāi)發(fā)?員和運(yùn)維?程師更友好、定位問(wèn)題更快
3. 可以更好地提供業(yè)務(wù)屬性數(shù)據(jù)

痛苦

同時(shí)，也會(huì)發(fā)現(xiàn)一個(gè)很痛苦的問(wèn)題:這些開(kāi)源項(xiàng)目大多是孤立的，之間沒(méi)有多大的關(guān)聯(lián)性，大公司可能有能力研發(fā)自己的可觀測(cè)平臺(tái)實(shí)現(xiàn)大一統(tǒng)，對(duì)于小公司來(lái)說(shuō)，需要在多個(gè)平臺(tái)之前進(jìn)行切換，如果有架構(gòu)調(diào)整，那切換的成本相信是巨大的。

觀測(cè)性能否做到一統(tǒng)呢?

這也其實(shí)也是【思考】中第 2 個(gè)問(wèn)題，簡(jiǎn)單地說(shuō)，能不能通過(guò)日志系統(tǒng)中的關(guān)鍵字，跳轉(zhuǎn)到 trace 系統(tǒng)中看這條日志所處的請(qǐng)求的所有鏈路。

答案是肯定的，grafana 就做的非常不錯(cuò)，統(tǒng)一了 agent，從 logging、trace、metrics 三個(gè)緯度進(jìn)行采集，loki 實(shí)現(xiàn)了日志的存儲(chǔ)，新貴 tempo 實(shí)現(xiàn) trace 的追蹤，metrics 則原生支持 prometheus，grafana 則提供了統(tǒng)一的可視化界面，從 agent 到 view 集成度非常高。

但 grafana 不是作者要介紹的主角，client 端的實(shí)現(xiàn)才是作者要深入調(diào)研實(shí)踐的主角，這就是 CNCF 牽頭開(kāi)源的新項(xiàng)目: OpenTelemetry

總結(jié)一下，以上主要介紹了可觀性測(cè)是什么以及為什么需要可觀測(cè)性，但沒(méi)有回答一個(gè)很重要的問(wèn)題:如何實(shí)現(xiàn)可觀測(cè)性，這其實(shí)是接下來(lái)要分享的內(nèi)容，會(huì)詳細(xì)介紹借用 OpenTelemetry 如何實(shí)現(xiàn)可觀測(cè)性

參考文章

• https://cloud.tencent.com/developer/article/1801643^[1]
• https://opentelemetry.io^[2]
• https://grafana.com^[3]

引用鏈接

你可能還喜歡

點(diǎn)擊下方圖片即可閱讀

云原生是一種信仰???

關(guān)注公眾號(hào)

后臺(tái)回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！