最近在 suvery 監控相關議題時接觸到 OpenTelemetry 蒐集遙測數據的開源框架，覺得這議題挺有趣的因此整理變成系列文，這篇是研究 OpenTelemetry 的系列文第一篇， 這系列主要會分為四篇分別是 若對於上述內容有問題或是不清楚的地方，歡迎提出來一起討論
企業面臨的挑戰
隨著科技技術不斷的創新，軟體架構與基礎建設演變速度也是變化相當快，如下圖所示可能(但不限)於以下幾個階段
- 第一階段 :應用程式架構設計上較為簡單，在商業需求沒那麼複雜架構上不會針對其模組做太多的切割，程式會運行執行緒(Process)執行單一的請求，在進行測試與問題排除上較為簡單；在開發完畢之後會佈署在 VM 或是會 IDC 機房中提供給使用者來使用。
- 第二階段 :隨著雲端技術的推出，企業開始嘗試將應用程式佈署到雲端的 Iaas 服務上，或是結合公有雲與私有雲的優勢，將企業中機密資料在私有雲進行處理，其他資訊在公有雲服務上進行運算，開發人員在應用程式的開發與整合上有更多與 Cloud 服務整合的機會，選擇 Cloud 上適合的服務使用。
- 第三階段 :雲端技術逐漸成熟與穩定，更多的雲端基礎建設服務與新服務不斷的推出，在架構設計上越來越多人開始討論分散式系統架構的設計，也越來越多人考慮將資料庫從IDC機房遷移到 Cloud 雲端上，加上像是 RDS、DynamoDB、Redis 等雲端資料庫, 這些服務或組件讓大家在雲端開發與管理上更為方便。在架構上也更為彈性搭配著企業需求來使用；在基礎建設上也伴隨著容器化(dockerize)的技術成熟開始進入新的世代。
- 第四階段 : 過去幾年大家一直在討論軟體架構從單體到微服務 serverless、service meshes 等各種可能的組合，主要目的可能是在服務架構設計時如何降低服務之間的依賴關係；在越來越多企業使用虛擬容器技術 Docker 後發現管理 Docker 實務上是困難的，因此 Kubernetes(K8S) 開始盛行，幫助團隊在調度 Docker 上更為容易與靈活，
但與所有美好事物一樣都是有代價的；當服務越切越細時，分佈式系統帶來了眾多的挑戰。當開發的世界變得複雜，可能會帶來哪些影響呢 ? 可能會分為三個部分:
- 架構 : 從單體式架構 > SOA > 分散式架構 > 微服務 開發人員在開發上變得更繁瑣，要注意的事情變得更多。例如 : 服務彼此之間的溝通要如何進行 ? 在事件的紀錄上要如何處理 ? 當一個請求要經過多個服務的時候相對的延遲(Lateny)也會增加，服務的拆分與請求時間的部分該如何達到平衡 ?
- 測試 : 當系統架構變得複雜，測試人員或團隊在測試上勢必需要花更多時間來了解既有架構要如何進行測試。
- 監控 : 上線後的監控會是最大的挑戰，當你所在的產品服務是 7* 24 小時，系統架構切分很細或是很複雜時，當今天某個服務故障時要如何快速定位問題變的是重要的關鍵
案例: Facebook 當機事件
或許上面文章提到的部分有點抽象，我們來看一個真實的案例，2021/10/4 facebook、whatApp及 IG 大當機，整個案件根本原因是因為工程師在部署新功能時有錯，導致對外 DNS 服務異常，詳細可以看 facebook 官方技術部落格或 Cloudfare 的異常事故報告 說明。
這裡簡單整理事件造成的影響:
- 修復時間 : 從問題開始到最後修復完成近花費 6 小時
- 影響人數 : 八千萬人無法使用
- 損失金額 : 10 億台幣
- 影響股價 : 問題發生後，股票下跌 4.89 %
從上述問題來看，如何讓問題發生時能夠快速地被定位變得更加重要，在企業服務越切越細的世代，最快時間找到問題變得相當的關鍵。如果今天是發生在你的公司或是負責的系統發生異常時，你要如何快速的定位問題呢 ?
圖片來源 : https://trends.google.com.tw/trends/?geo=TW
根據 Google 關鍵字報告搜尋 監控(Monitor) 關鍵字，可以發現在過去 20 年的時間大家對於應用程式的監控越來越重視，背後的涵義可能是在這變化這麼快、不確定性這麼高、架構越來越複雜的時代，是否有更好的方法或方式來進行監控，或者也可以反問，或許在雲原生(Cloud Native)時代的監控，應該具備甚麼樣的特性?
可觀測性(Observability)
分散式系統意味者分散式故障，當出現故障時，可能很難快速恢復服務，甚至不知道從哪裡開始。您如何解析龐大的依賴關係，取決於你對系統的了解與問題定位有很大的關聯。可觀測性簡單來說可以幫助開發人員或是 SRE 夥伴了解，什麼是慢的 ? 什麼是壞的 ? 以及需要做什麼來提高性能。
- Metrice : 系統有狀況
- Logs : 問題是甚麼
- Traces : 哪裡出問題
橫軸 : Data available, 指的你是否有 log 的資料
縱軸 : 對於系統的理解程度
接者可以透過橫軸縱軸了解的程度切分為四個象限，可能光看文字會有點抽象，以下透過一些簡單的例子舉例說明
- known knowns : 這些事情是我們知道且可以理解的，舉例 : 在雲端伺服器建立新的 instance 時，核心數為 1 core，記憶體為 1G 可以提供應用程式使用。
- known Unknowns : 事情是我們知道但沒辦法理解的，舉例 : 應用程式接收到多大的請求量時，系統會 crash 造成服務中斷；電商遇到雙11節慶流量會很大，但我們不確定請求量會成長幾倍?
- Unknown Knowns : 事情是我們知道但自己是沒有意會到的
- Unknown Unknowns : 不了解會發生甚麼事以及其帶來的影響，舉例 : 不了解系統在高流量時會發生甚麼問題，也不清楚會有哪些服務會被影響到
右下角就是過去常常聽到的監控(Monitoring)，知道可能會異常的點會有那些因此加上偵測點進行判斷，如果超過其筏值或是水位值會發送告警通知。左下角是可觀測性(Observability)，希望可以透過已知的訊息更了解系統的狀況。
可觀測性(Observability) 的目的是什麼呢 ?
可觀測性不僅僅是收集數據的內容，希望透過可觀測性工具或平台可以回答下列問題:
- 請求通過了哪些服務
- 每個服務在處理請求時做了什麼
- 如果請求很慢，瓶頸在哪裡
- 如果請求失敗，錯誤發生在哪裡
- 請求的關鍵路徑上是什麼
- 執行與正常系統行為有何不同
- 為什麼花了這麼長時間
Distributed Tracing
過去大家常提到的監控(Monitor)是透過 Metrics 及 Log 來達到其目的，可觀測性(Observability) 更著重在追蹤(Trace)的部分，Trace 的目的是把系統中所有模組與組件之間的交互關係透過 TraceID 串聯起來，TraceID 是請求(Request)開始生成一個關聯ID，接著再將其記錄在該事務(Span)的每個請求中，可以讓你知道一個請求或是某個事件從頭到尾的信息內容，也就是透過上下文關係(Context)來取得請求中各服務之間的關聯。
舉例來說，以上圖內容為例，當使用者發送一個請求來的時候，從 A 點服務開始，接著分別經過 B、E 兩個服務，B 的服務資料來源是透過 C 與 D 的服務取得，以及這些服務各自所花費的時間為何。當我們蒐集到每個服務的資訊與所花費的時間，發現請求有緩慢或是服務異常的問題時，監控團隊可以透過遙測的數據定位可能異常的服務來進行問題排除與處理，加快可能異常服務的問題確認時間。
結論
可觀測性是這幾年新的術語，今天簡單介紹了可觀測性(Observability)的目的，關鍵核心是透過 Traces 提供系統行為及上下文關係，那麼在實務上要如何蒐集這些數據資料呢 ? 下一篇我們將分享如何使用 CNCF(Cloud Native Computing Foundation) 的 Open Source 框架 OpenTelemetry 來蒐集遠端遙測數據資料，讓你的系統更具備可觀測性(Observability)。
參考
Monitoring in the time of Cloud Native Microservice Observability, Part 1: Disambiguating Observability and Monitoring
我都是跟著 Cash 哥學習的 :D
回覆刪除