Skip to main content

Command Palette

Search for a command to run...

OpenTelemetry 入門指南: 建立全面可觀測性架構

Updated
3 min read
OpenTelemetry 入門指南:
建立全面可觀測性架構

OpenTelemetry 入門指南:建立全面可觀測性架構(iThome鐵人賽系列書)


博碩連結

天瓏書局連結

作者鐵人賽系列

印刷書因圖片太大以及對比問題,能前往各章節圖片資料夾中觀看原圖。

圖片連結

或前往該文章底部


作者簡介

  • 雷N
    作者擁有十年後端系統的設計與開發經驗,目前以 Go 為主要程式語言進行開發。在工作經驗上,作者經歷過單體服務的演化至微服務架構,以及從地端環境轉移到雲端的容器託管環境。透過這段深入的實務應用過程,作者深刻體會到現代複雜且動態系統架構下,主動強化系統的可觀測性能力對整個開發團隊的重要性。因此,此著作主要從後端工程師的角度出發,旨在幫助讀者全面理解和深入掌握 OpenTelemetry 的技術和應用。

    \> Blog︰https://ganhua.wang/

本書特色

  • 本書內容改編自第14屆iThome鐵人賽DevOps組佳作系列文章
    《淺談DevOps與Observability》

    【本書特色】
    本書探討如何透過系統可觀測性應對日益複雜的系統架構,如微服務及雲端環境。隨著系統架構的演進,傳統的地端管理方式已不敷使用,作者提供一系列基於可觀測性工程的實踐方法來解決營運中遇到的問題,這些方法不僅適用於技術人員日常的維護工作,也便於團隊引入並落實。

    書中重點介紹了如何使用OpenTelemetry標準框架結合Grafana Labs提供的開源工具,如Grafana、Loki、Tempo及Prometheus來收集、組裝和呈現遙測數據。這些工具和框架的配合使用,能夠有效地增強系統的可觀測性,並以儀表板直觀展示系統行為數據,從而提供深入分析。

    此外,本書也介紹了k6這一系統負載測試工具,它能幫助團隊在開發週期中建立多種測試場景,即時顯示性能指標,進而在預備環境中驗證系統是否能達到預定的SLO。這不僅優化了開發流程,也為系統穩定性提供了保障。

    最後,作者結合自身在使用OpenTelemetry的實務經驗,並且作為「The Observability Engineering」一書的譯者,引導讀者理解OpenTelemetry的運用方式及其在系統監控中的獨特價值,展示了如何通過增強系統的可觀測性來滿足當前與未來的監控需求。

    【專業推薦】
    從基礎理論說明到實踐,甚至是一步一步完成 Demo 的工作坊,這本書都一應俱全。雖然書名是《OpenTelemetry 入門指南》,但其內容的完整程度,對於初學 OpenTelemetry,或是想導入 OpenTelemetry 到手上系統的團隊,都能滿足需求。相信這本書一定是學習 OpenTelemetry 的最佳選擇!
    OAuth 2.0 從入門到實戰作者
    Miles

    在本書中,雷N 從 OpenTelemetry 的歷史背景到具體架構及其核心元件,再到可觀測性重要支柱,進行了詳細的闡述。隨後,他通過 OpenTelemetry Collector 的功能,將理論與實踐結合,展示了如何在實際項目中應用 OpenTelemetry。不僅如此,他還進一步整合了在可觀測性領域中備受推崇的 Grafana Stack,大大提升了 OpenTelemetry 和可觀測性的實用性。
    Grafana 傳教士
    Mike Hsu


本書目錄

  • 第一部份 : 從傳統到轉型:探索現代 IT 架構
    CH 1 : 現代化系統架構的演化
    1.1 單體應用的 Client/Server 架構
    1.2 分層式元件化應用時代
    1.3 SOA 服務導向架構
    1.4 微服務架構

    CH 2 : DevOps 簡介
    2.1 DevOps 的起源與定義
    2.2 DevOps 的核心價值觀 CAMS
    2.3 DevOps 研究與評估組織 DORA

    CH 3 : 什麼是可觀測性 Observability
    3.1 可觀測性一詞的起源
    3.2 可觀測性的概念與重要性
    3.3 可觀測性與監控的區別
    3.4 可觀測性的基本遙測資料

    第二部份 : 可觀測性開源標準 OpenTelemetry
    CH 4:淺談 OpenTelemetry
    4.1 OpenTelemetry 的前世今生
    4.2 簡介 OpenTelemetry
    4.3 OpenTelemetry 客戶端核心元件
    4.4 OpenTelemetry 的功能狀態與版本管理
    4.5 OpenTelemetry 的願景

    CH 5:OpenTelemetry 信號
    5.1 Signal
    5.2 Logs
    5.3 Metrics
    5.4 Trace
    5.5 Baggage

    CH6: Trace SDK 與 Metric SDK介紹
    6.1 Span 取樣器
    6.2 Span 處理器
    6.3 Span 匯出器
    6.4 指標樣本

    CH7:OpenTelemetry Collector
    7.1 OpenTelemetry Collector
    7.2 Collector 流水線與組成
    7.3 遙測資料接收器
    7.4 遙測資料處理器
    7.5 遙測資料匯出器
    7.6 流水線連結器
    7.7 Collector 擴展功能
    7.8 綜合演示

    CH 8:動手玩OpenTelemetry Demo專案
    8.1 環境建置
    8.2 架構與設計
    8.3 看見問題
    8.4 Grafana Demo 儀表板說明

    第三部分:Grafana 開源工具應用
    CH 9:Grafana 基本概念與應用
    9.1 介紹 Grafana
    9.2 初次使用 Grafana
    9.3 整合 Grafana 資料來源
    9.4 Grafana 儀表板
    9.5 Grafana 主動配置

    CH 10:Grafana Loki
    10.1 介紹 Grafana Loki
    10.2 Loki LogQL
    10.3 Loki 與 Collector 和 Grafana 的整合

    CH11:Grafana Tempo
    11.1 介紹 Grafana Tempo
    11.2 TraceQL
    11.3 追蹤與日誌的整合
    11.4 追蹤與指標的關聯

    CH12:改造 OpenTelemetry Demo專案
    12.1 整合日誌與追蹤
    12.2 整合指標與追蹤

    第四部分:負載測試工具
    CH13:Grafana k6‧系統測試神器
    13.1 Grafana k6 簡介
    13.2 各種類型的系統測試
    13.3 k6 與 Postman 和 OpenAPI 的整合
    13.4 k6 與 Github Action 的整合
    13.5 OpenTelemetry Demo 專案改造計畫 - 2

    附錄 Collector 內建指標


錯字修訂

  1. 圖3-12 handnle -> handler

  2. 圖4-3 Watefall -> Waterfall

  3. 13-15 計量器(Gauge) -> 量規(Gauge)


書本原圖

圖3-4

圖3-5

圖3-6, hadnler 修訂成 handler

圖5-10

圖5-12

圖5-13

圖5-15

圖5-17

圖7-13

圖7-14

圖7-15

圖7-16

圖7-17

圖7-18

圖8-1

圖8-2

圖8-6

圖8-7

圖8-11

圖8-12

圖8-13

圖8-16

圖8-17

圖8-18

圖8-19

圖8-20

圖8-21

圖8-22

圖8-23

圖9-3

圖9-4

圖9-5

圖9-6

圖9-7

圖9-8

圖9-9

圖9-10

圖9-11

圖9-13

圖9-15

圖9-16

圖9-17

圖10-7

圖10-8

圖10-9

圖10-10

圖10-11

圖10-12

圖10-14

圖10-15

圖10-17

圖11-3

圖11-4

圖11-5

圖11-6

圖11-7

圖11-9

圖11-10

圖11-11

圖11-12

圖11-14

圖11-15

圖11-16

圖11-17

圖11-18

圖11-19

圖11-20

圖12-1

圖12-2

圖12-3

圖12-4

圖12-5

圖13-5

圖13-6

圖13-7

圖13-8

圖13-10

圖13-14

圖13-15

圖13-17

圖13-18

圖13-19

1.3K views

More from this blog

Claude Code 監控秘錄:OpenTelemetry(OTel/OTLP)實戰指南

稟告主公:此乃司馬懿進呈之兵書,詳解如何以 OpenTelemetry 陣法,令臥龍神算之一舉一動盡在掌握,知糧草消耗、察兵器效能、辨戰報異常,使主公運籌帷幄於大帳之中。 為何需要斥候情報? 司馬懿稟告主公: 臥龍神算(Claude Code)乃當世利器,然若無斥候回報,主公便如蒙眼行軍——兵器耗損幾何、糧草消費幾許、哪路斥候出了差錯,一概不知。臣以為,此乃兵家大忌。 無情報之弊,有四: 軍

Feb 19, 202610 min read162
Claude Code 監控秘錄:OpenTelemetry(OTel/OTLP)實戰指南

工程師的 Claude Code 實戰指南:從零開始到高效開發

工程師的 Claude Code 實戰指南:從零開始到高效開發 本文整合 Anthropic 官方 Best Practices 與社群實戰 Tips,帶你由淺入深掌握 Claude Code。 什麼是 Claude Code?為什麼值得學? 如果你還在用「複製程式碼貼到 ChatGPT,再複製答案貼回去」的工作流程,Claude Code 會讓你大開眼界。 Claude Code 是 Anthropic 推出的命令列工具,它直接活在你的 terminal 裡,能夠讀懂你的整個 codeb...

Feb 18, 20265 min read72
工程師的 Claude Code 實戰指南:從零開始到高效開發

System Design Interview Ch 12 Digital Wallet

確立問題與設計範疇 角色對話內容 面試者我們應該只關注兩個數位錢包之間的餘額轉帳操作嗎?我們是否需要擔心其他功能? 面試官讓我們只關注餘額轉帳操作。 面試者該系統需要支援多少 TPS(每秒交易次數)? 面試官讓我們假設是 1,000,000 TPS (每秒 100 萬次交易)。 面試者數位錢包對正確性有嚴格的要求。我們可以假設事務保證 就足夠了嗎? 面試官聽起來不錯。 面試者我們需要證明正確性嗎? 面試官這是一個很好的問題。正確性(Correctness)通常只有在交...

Feb 2, 202610 min read190
System Design Interview Ch 12 Digital Wallet

Claude Code 利用 Event-Driven Hooks 打造自動化開發大腦

在現代 AI 輔助開發中,我們不僅需要 AI 寫程式,更需要它懂規則、記性好,並且能自動處理那些繁瑣的雜事。透過 Claude Code Hooks 機制,我們可以介入 AI 的思考與執行迴圈,實現真正的「人機協作自動化」。 一、 動機與痛點:為什麼你需要介入 AI 的生命週期? 在預設狀態下,Claude Code 雖然強大,但它是「被動」且「無狀態」的,這導致了開發者常遇到以下痛點: 記憶重置 (Session Amnesia): 痛點:每次重啟終端機,AI 就像失憶一樣。 解法:你...

Jan 24, 20266 min read441
Claude Code 利用 Event-Driven Hooks 打造自動化開發大腦
M

MicroFIRE

71 posts