DevOps Taiwan Meetup#65 RECAP：可觀測性 Observability

這週五，我參加了人生中的第一次 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)就是為了解決這些問題而生的概念，它強調透過各種資訊來清楚了解系統狀態。

可觀測性的三大支柱

可觀測性主要包含但是不限於這三種最核心的資料種類：

1. 指標(Metrics)：
2. • 不同時間採樣的系統量化指標
2. 日誌(Logs)：
3. • 記錄系統中發生的具體事件
3. 分散式追蹤(Distributed Tracing)：
4. • 記錄請求在不同服務中的完整歷程

來自簡報截圖

建置 Observability 資料流程的四個階段

可觀測性的實作可以分為四個主要階段：

1. 生成：由各種來源產生觀測資料
2. 收集：將資料從各處收集起來
3. 儲存：將收集到的資料妥善保存
4. 使用：透過各種工具分析和呈現資料

來自簡報截圖

建置 Observability 的一些考量

• 資料流向的規劃 (pull/push)
• 收集哪些資料 / 儲存在哪裡 / 儲存多長的資料 / 是否要使用 collector 去篩選資料
• • 影響成本
• 工具的選擇 (通用 / 不被 vendor lock)
• 儲存空間的如何管理
• 何時該導入?
• • 一開始，且各環境都可以有，但規模和收集資料頻率的不同(成本考量)
• 是否影響到環境的效能，本末倒置。
• • 有提到了 OpenAI 2023/11/11 的事件，其中大量的 Telemetry Service API 請求反而導致 K8s Control plane 過載

我的 TAKEAWAY

• 針對效率損失很有共鳴，原本很專心做一件事情，被各種環境問題或是雜事中斷真的很有感，處理完了，時間也差不多下班了、腦力也差不多歸零了
• 在一線大廠和二線的 MTTR 差了 2.4 倍，而解問題其實大部分的時間都是用在找出根本原因(通靈)的部分，可以看到好的可觀測性帶來多少時間的效益

自自簡報截圖

• 工具很多，選擇最適合自己的最重要
• 導入越早越好，如有成本可量，可篩選要收集哪一些資料
• 用商業軟體真的很好用哈哈哈，像是 datadog / dynatrace 等等，工具選擇、工具的維護升級、儲存的煩惱都幫你做好了，甚至商業軟體的 agent 安裝好後，服務重啟 trace 的監控碼也都插入好了，前端後端的關聯性也整合好了!!(這邊有人 QA，講師回答可以做但是很多功夫要做)

講師的簡報資源

Blueswen - 快速入門可觀測性

DevOps Taiwan Meetup #65 - 快速入門可觀測性 面對眾多的可觀測性工具與技術，常令人不知如何開始。本次分享將以資料流的角度，分析工具間的關係，快速構建完整框架概念，為後續的可觀測性技術選型與導入奠定基礎。

https://speakerdeck.com/

DevOps Taiwan Meetup 資訊

DevOps Taiwan Community | DevOps 台灣社群

DevOps Taiwan Community - KKTIX

DevOps Taiwan | Facebook

補充資料

By Jay Livens - - Observability vs. monitoring: What's the difference?

Organizations are depending more on distributed architectures to provide application services. This trend is prompting advances in both observability and monitoring. But exactly what are the differences between observability vs. monitoring? Understanding when something goes wrong along the application delivery chain is essential so you can identify the root cause and correct it before it...

https://www.dynatrace.com

By Dynatrace Editorial Team - - What is observability? Not just logs, metrics and traces

As organizations embrace cloud-native technologies, system architectures have dramatically increased in complexity and scale. Customer experiences are more important than ever, and as a result, IT teams face mounting pressure to track and respond to issues much faster. To address these challenges, teams are turning to observability solutions so they can proactively identify and resolve...

https://www.dynatrace.com

可觀測性與監控 - 以資料為基礎的程序間的差異 - AWS

可觀測性與監控有何差異？ 如何搭配 AWS 使用可觀測性與監控。

https://aws.amazon.com