OTel 101:透過實踐Workshop建構可觀測性技能

原创 岱军 云云众生s

教授雲端原生開發者如何使用 OpenTelemetry 透過分散式追蹤探索他們的服務。

譯自OTel 101: Build Observability Skills with Hands-on Workshops,作者 Paige Cruz。

我們正處於向開放、可擴展和可觀測世界轉變的構造性變革之中。 隨著每個拉取請求,「一次檢測,隨處觀察」的夢想比以往任何時候都更加接近。 分散式追蹤尤其具有獨特優勢,可以幫助開發人員了解和理解他們正在建置和操作的雲端原生服務的複雜性:能夠跨分散式微服務環境追蹤事務具有難以置信的價值。

然而,自從分散式追蹤引入以來,許多追蹤計畫在十多年間都步履蹣跚,並且一直保持著作為超級工程師工具的聲譽。 在我看來,跟蹤本身並不是問題。 早期工具很複雜,因此追蹤的實用性集中在少數高級用戶上。

但是,由單一站點可靠性工程 (SRE) 團隊領導和執行的追蹤計劃將無法蓬勃發展。 為了讓團隊充分發揮追蹤數據的潛力,每個開發人員都必須能夠使用追蹤工具。 這意味著要學習從一開始如何發出資料到如何使用該資料的所有內容。

實踐研討會的價值
我嘗試了許多策略來幫助開發人員培養分析和利用追蹤以更好地理解系統行為和為決策提供基礎的技能。 最成功的計劃是實作研討會,例如我在芝加哥舉行的KubeCon North America 2023上關於OpenTelemetry(OTel) 和追蹤的研討會。 我的課程OpenTelemetry 101:讓我們插樁吧! 旨在讓開發人員踏出追蹤的第一步。

我渴望幫助盡可能多的開發人員踏上他們的追蹤之旅,因此本文分享了開發研討會的幕後花絮,包括:

我如何設計學習環境。

建立對可觀測性概念的共同理解的複雜性。

如何使用 OpenTelemetry 建立和傳送跨度。

練習解釋和分析追蹤數據的技能。

創建學習環境
該研討會專為追蹤新手設計,我希望參加者能夠掌握將追蹤應用到他們自己的專案所需的知識和技能。 實現這種獨立性意味著我只有幾個小時的時間來介紹基本的可觀測性概念;概述OpenTelemetry 及其各種子項目;為參與者提供大量機會來培養他們的檢測能力並思考在何處、 何時以及如何添加跨度;並在他們對跟踪中的詳細程度感到滿意之前幫助他們驗證結果數據。

一次引入所有這些內容,即使是最經驗豐富的開發人員也會不知所措,所以我將其分解為三個主要部分:

可觀測性概念

發送追蹤數據

使用追蹤數據

可觀測性概念:學習術語
許多人會在工作中非正式地學習可觀測性。 這可能導致誤解,例如將特定於供應商的產品名稱與可觀測性概念混淆。 這就是我每次可觀測性訓練課程都從術語和概念的快速水平設定開始的原因。 即使是一句定義也能澄清問題:

在定義了關鍵術語後,我開始概述OpenTelemetry (OTel),涵蓋組件、協議和社群的高級內容。 我忍不住想詳細介紹它的歷史、開發和每個組件,但我沒有這麼做。 相反,我轉向學習目標尋求指導。 開發人員真的有必要了解收集器才能自信地使用 OpenTelemetry 檢測追蹤嗎? 不。 因此,我在收集器上添加了一張幻燈片,簡要地解釋了它在生態系統中的作用。 隨著他們繼續學習之旅,這讓人們對收集器有了初步的了解。

在這一點上,參與者已經有了足夠的基礎來開啟吸引他們的實際主題:插樁追蹤。

發送追蹤數據
此研討會的設計考慮了會議受眾,因此我介紹了檢測的所有三種方法:自動、程式設計和手動。

在學習體驗的早期階段,為人們提供快速獲勝的機會以建立信心並保持他們的參與度非常重要,因此我從自動檢測開始。 為了保持簡單,我教授瞭如何為追蹤配置console_exporter並探索跨度的文字表示。 根據我的經驗,這種動手實作方法比展示帶有相同跨度的幻燈片並對它的每一部分進行講解更有效。 對於我想傳授的每項技能或知識點,找到一種動手實踐的方式讓參與者透過實作學習非常重要,而不是聽我講課。

轉向程式設計和手動方法提供了更多練習和加強學習者檢測技能的機會。 他們重複了相同的工作流程——規劃檢測位置、添加檢測程式碼、運行程式以產生跟踪,然後驗證追蹤資料是否重複——一遍又一遍。

追蹤的真正價值來自你使用它的所有方式。 它有助於更好地理解系統中發生的事情,並讓你為下一個主題做好準備。

使用追蹤數據
能夠檢測和發送追蹤是第一步,但研討會的巔峰是學習如何查詢、視覺化、解釋和分析追蹤數據。 這為最終的新組件Jaeger打開了大門。

Jaeger 與 OpenTelemetry 一樣,有著悠久而豐富的歷史,但這與實現學習目標沒有直接關係。 因此,我專注於如何與追蹤瀑布、拓撲圖互動以及解釋追蹤散點圖,而不是操作 Jaeger 和在生產中使用它的細節。

我希望我分享開發這個 OTel 101 研討會背後的思考過程能激勵你舉辦你自己的研討會。 我的研討會是為廣泛的開源開發者設計的(想想KubeCon),所以我必須在一定限制內工作。 為公司同事設計研討會將讓每個人都能從關於你的業務和技術堆疊的共享背景中受益。 以下是我概括的要點。

設定明確、有範圍、可衡量的學習目標。 這可以作為指南來評估你想要包含的細節是你受眾需要知道的,還是會造成資訊過載。

在現實世界的用例中奠定學習基礎。

主持一場“檢測馬拉松”,讓開發者帶上自己的服務來添加追蹤。

找出你的學習者不理解的內容。

查看團隊知識庫和工單系統中常見的可觀測性問題。

發送一份調查,詢問他們之前的可觀測性知識、他們想了解追蹤的哪些內容、他們遇到的障礙等。

帶領新手參加你的研討會,並注意摩擦和困惑的地方,然後納入他們的回饋。

不要重複發明輪子。 建立在開源專案現有的教程之上,如果適用,還可以建立在供應商提供的教程之上。 為了獲得最大的功效,調整這些資源,而不是按原樣使用它們。 這有助於將材料精簡到與你的受眾相關的平台中的功能或產品。

以多種方式傳遞訊息,尤其是在與分散式遠端團隊合作時。 例如,你可以提供現場指導課程和自學課程。

在雲端原生可觀測性方面,每個開發者都應該能夠使用分散式追蹤來探索他們的服務。 如果你正在著手一項引入追蹤或重啟停滯的追蹤工作的新舉措,請考慮精心設計的培訓如何提供幫助。