DevOps Taiwan Meetup#65 RECAP：可觀測性 Observability
更新於 2024/12/21閱讀時間約 6 分鐘
這週五，我參加了人生中的第一次 DevOps Taiwan Meetup，沒想到初次體驗就撞上了最熱門的話題——可觀測性（Observability）。活動現場的熱烈程度超乎想像，甚至連走道都被坐滿了！只需要 50 元場地費，就能享受兩小時滿滿的知識密集的分享，真的讓人驚喜不已。周圍的參與者也都很厲害，以後會常常參加!希望未來也能夠有能力站上講台分享心得！
這次的主講人是 Blueswen 和 雷N，他們帶來了許多關於 Observability 的核心要點，並展示了如何通過 Live Demo 在開發部署階段「將問題左移」，提升問題解決效率。有過 Dynatrace 經驗的我，發現很多內容與過去的實務經歷相呼應，可以舉一反三。以下是我的筆記與重點整理。
為什麼需要可觀測性？和監控有什麼差別?
監控（Monitoring） 是一種針對特定指標進行數據收集、分析和使用的過程，主要用來追蹤系統運行狀況，幫助及時發現異常並輔助決策。然而，它的數據通常與更廣泛的系統背景脫節。
而 可觀測性（Observability） 是指通過分析系統生成的數據（如日誌、指標和分散式追踪），來深入理解系統內部狀態的能力。它不僅能快速檢測問題，還能幫助找出問題的根本原因，特別適用於現今微服務架構下的複雜系統。
其關鍵差異，舉例來說:
1. 問題處理方式
- 監控：「我知道可能會出問題，所以我要監控這些指標。」通過預先設置的指標進行異常檢測，例如 CPU 或記憶體使用率的警報通知。
- 可觀測性：「我不確定會出什麼問題，但我需要足夠的信息來理解問題。」通過全面的數據收集，幫助分析問題的性質與根源。
2. 數據深度
- 監控：關注表層數據和預定義指標。例如 CPU 使用率、記憶體使用率等監控指標。
- 可觀測性：深入系統內部，一個 request 進來後從 end to end 完整的上下文信息。包括日誌、分布式跟踪和多層的指標(最基本的就是 log, metric, trace)，反映系統內部運行(程式互相呼叫)的細節。
3. 問題診斷
- 監控：告訴你「出了什麼問題」。比如警報通知 CPU 達到臨界值，但無法告知問題的根本原因。
- 可觀測性：幫助你理解「為什麼出問題」以及「如何解決」。
Observability 誕生原因
當系統出現異常時，我們是否有足夠的資訊來了解發生了什麼事？這些資訊是否被妥善保存？是否有效地被利用？還是散落在各處形成了資料孤島(Data Silo)，是不是能夠有效的將不同來源的資料一起顯示並關聯再一起，讓你在查找問題時能夠看到問題和根本原因的關聯性？
可觀測性(Observability)就是為了解決這些問題而生的概念，它強調透過各種資訊來清楚了解系統狀態。
可觀測性的三大支柱
可觀測性主要包含但是不限於這三種最核心的資料種類：
- 指標(Metrics)：
- 不同時間採樣的系統量化指標
- 日誌(Logs)：
- 記錄系統中發生的具體事件
- 分散式追蹤(Distributed Tracing)：
- 記錄請求在不同服務中的完整歷程
建置 Observability 資料流程的四個階段
可觀測性的實作可以分為四個主要階段：
- 生成：由各種來源產生觀測資料
- 收集：將資料從各處收集起來
- 儲存：將收集到的資料妥善保存
- 使用：透過各種工具分析和呈現資料
建置 Observability 的一些考量
- 資料流向的規劃 (pull/push)
- 收集哪些資料 / 儲存在哪裡 / 儲存多長的資料 / 是否要使用 collector 去篩選資料
- 影響成本
- 工具的選擇 (通用 / 不被 vendor lock)
- 儲存空間的如何管理
- 何時該導入?
- 一開始，且各環境都可以有，但規模和收集資料頻率的不同(成本考量)
- 是否影響到環境的效能，本末倒置。
我的 TAKEAWAY
- 針對效率損失很有共鳴，原本很專心做一件事情，被各種環境問題或是雜事中斷真的很有感，處理完了，時間也差不多下班了、腦力也差不多歸零了
- 在一線大廠和二線的 MTTR 差了 2.4 倍，而解問題其實大部分的時間都是用在找出根本原因(通靈)的部分，可以看到好的可觀測性帶來多少時間的效益
- 工具很多，選擇最適合自己的最重要
- 導入越早越好，如有成本可量，可篩選要收集哪一些資料
- 用商業軟體真的很好用哈哈哈，像是 datadog / dynatrace 等等，工具選擇、工具的維護升級、儲存的煩惱都幫你做好了，甚至商業軟體的 agent 安裝好後，服務重啟 trace 的監控碼也都插入好了，前端後端的關聯性也整合好了!!(這邊有人 QA，講師回答可以做但是很多功夫要做)
講師的簡報資源
DevOps Taiwan Meetup 資訊
DevOps Taiwan Community | DevOps 台灣社群
DevOps Taiwan Community - KKTIX
補充資料
留言0
查看全部
你可能也想看
Google News 追蹤
*合作聲明與警語：
本文係由國泰世華銀行邀稿。
證券服務係由國泰世華銀行辦理共同行銷證券經紀開戶業務，定期定額(股)服務由國泰綜合證券提供。
剛出社會的時候，很常在各種 Podcast 或 YouTube 甚至是在朋友間聊天，都會聽到各種市場動態、理財話題，像是：聯準會降息或是近期哪些科
※ 觀察者模式
定義：
觀察者模式（Observer Pattern）是一種設計模式，涉及兩個主要角色：觀察者（Observers）和被觀察者（Subject）。在這種模式中，一群觀察者訂閱並觀察某個被觀察的對象。當被觀察者的狀態發生改變時，它會通知所有觀察者，讓他們知曉並作出相應的反應。這種模
這篇的DevOps發佈系統是以Spring Cloud微服務(微服務)為背景；由GitLab、Harbor與Kubernetes組成。
GitLab負責版本管理與CI/CD(CI/CD)。
Harbor負責Docker([Docker]介紹) Image的儲存與發佈。
Kubernetes([
可能包含敏感內容
先說一下我的背景，非本科系從 2022/3 開始接觸到前端領域，在摸索過程中遇到六角學院，買了 ＨTML 和 CSS 課程從基礎學起。
學習如何使用Python連接MongoDB進行憑證監控，包括建立MongoDB docker-compose、連接MongoDB、讀取yaml並寫入MongoDB、傳入env以及domain寫入MongoDB、讀取MongoDB、修改MongoDB、刪除MongoDB。
觀察者模式透過主題訂閱/訊息通知的機制，極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單，是非常實用的設計模式。
軟體系統的發展歷程大多相似，首重解決基本需求、提供操作介面，進而提升安全性、擴充功能、優化操作。
上次完成到基本的CRUD及權限控制，後面花了點時間把排序、分頁、圖表總覽的部分做完，其他細節是佈署上線，一般在公司內有專屬的部門處理，僅了解一下流程。
前年第一次藉公司機會，參加了DevOpsDay的活動。雖然devOps一詞各自表述，大多狀況還是偏向維運會遇到的技術為主，做為平時開發、跟使用者訪談需求的工作內容來說，參加聚會如果沒有一定的知識，對講者所提到的狀況比較難有共鳴...
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
前兩天，我們探討了「網站文章」的情境題；今明兩天，就讓我們探討另一個情境題「會員註冊」吧！
這邊我們同樣假設網站是採前後端分離的設計，因此我們就專注在測試 API 的部分，不過會多一個「註冊驗證信」的部分要實作與做測試驗證。
使用案例
使用者可填寫註冊資料後送出資料。
使用者可收到註冊驗證信
*合作聲明與警語：
本文係由國泰世華銀行邀稿。
證券服務係由國泰世華銀行辦理共同行銷證券經紀開戶業務，定期定額(股)服務由國泰綜合證券提供。
剛出社會的時候，很常在各種 Podcast 或 YouTube 甚至是在朋友間聊天，都會聽到各種市場動態、理財話題，像是：聯準會降息或是近期哪些科
※ 觀察者模式
定義：
觀察者模式（Observer Pattern）是一種設計模式，涉及兩個主要角色：觀察者（Observers）和被觀察者（Subject）。在這種模式中，一群觀察者訂閱並觀察某個被觀察的對象。當被觀察者的狀態發生改變時，它會通知所有觀察者，讓他們知曉並作出相應的反應。這種模
這篇的DevOps發佈系統是以Spring Cloud微服務(微服務)為背景；由GitLab、Harbor與Kubernetes組成。
GitLab負責版本管理與CI/CD(CI/CD)。
Harbor負責Docker([Docker]介紹) Image的儲存與發佈。
Kubernetes([
可能包含敏感內容
先說一下我的背景，非本科系從 2022/3 開始接觸到前端領域，在摸索過程中遇到六角學院，買了 ＨTML 和 CSS 課程從基礎學起。
學習如何使用Python連接MongoDB進行憑證監控，包括建立MongoDB docker-compose、連接MongoDB、讀取yaml並寫入MongoDB、傳入env以及domain寫入MongoDB、讀取MongoDB、修改MongoDB、刪除MongoDB。
觀察者模式透過主題訂閱/訊息通知的機制，極度增強系統的可擴展性、靈活性以及降低組件間的耦合度。概念直觀簡單，是非常實用的設計模式。
軟體系統的發展歷程大多相似，首重解決基本需求、提供操作介面，進而提升安全性、擴充功能、優化操作。
上次完成到基本的CRUD及權限控制，後面花了點時間把排序、分頁、圖表總覽的部分做完，其他細節是佈署上線，一般在公司內有專屬的部門處理，僅了解一下流程。
前年第一次藉公司機會，參加了DevOpsDay的活動。雖然devOps一詞各自表述，大多狀況還是偏向維運會遇到的技術為主，做為平時開發、跟使用者訪談需求的工作內容來說，參加聚會如果沒有一定的知識，對講者所提到的狀況比較難有共鳴...
確保沒有遺漏或錯誤
程式的完整資訊資料對於程式設計至關重要。這是因為只有透過完整的資訊，我們才能確保在程式設計中沒有任何遺漏或錯誤。最終，後台管理扮演著管理系統中所有動作和行為是否符合特定標準的重要角色。
採取不符合預期的行動
這種符合性的重要性在於，當我們設計程式時，希望使用者按照預期的方式
前兩天，我們探討了「網站文章」的情境題；今明兩天，就讓我們探討另一個情境題「會員註冊」吧！
這邊我們同樣假設網站是採前後端分離的設計，因此我們就專注在測試 API 的部分，不過會多一個「註冊驗證信」的部分要實作與做測試驗證。
使用案例
使用者可填寫註冊資料後送出資料。
使用者可收到註冊驗證信