Day1曾經提到Observability(可觀察性), 接著就是簡單介紹一下這微服務的設計原則.

MicroServices這幾年正夯, 它提供了一個強大的體系結構.

但也帶來其挑戰, 特別是在Debug和觀察監測上.

在跨網路的分佈式處理上, 也很難追蹤, 甚至各服務用的語言還不同, 無法共用公司客製的套件.
進行微服務架構開發時, 通常會根據業務功能劃分成若干個不同的微服務業務模組.
各模組之間透過REST/RPC等做溝通調用.
一個用戶發出請求, 可能需要很多微服務的模組協同處理才能完成.
如果業務調用鏈路上任何一個服務出現問題或是網路超時, 導致功能失效;或者是鏈路上某服務突然回應時間暴增.
隨著業務越來越複雜, 架構橫向縱向擴展之後, 服務之間的調用鏈路的分析將是個難題.

全鏈路追蹤設計具有三個設計目標:

1. 很低的效能開銷
2. 對應用透明可以跨任意平台
3. 可擴展性

Observability(可觀察性)

所以全鏈路追蹤提供了一種解決方案. 提供系統行為跟性能的問題推導的協定.
全鏈路追蹤是整個系統中跟蹤一個用戶請求的過程, 包含數據傳輸、數據儲存、數據撈取等等的, 透過追蹤協定, 可以看到整個調用鏈的交互關係.
Observability是一個概念, 要求的是開發出來的服務可以觀察. 將可觀察性也納入需求之中.
因此SRE團隊誕生了.

因此CNCF將此原則納入Landscape的分類之中.

裡面又細分成Monitoring、Logging、Tracing、Chaos Engineering.

以往都只有監控機器跟網路居多, Application幾乎只有Health Check的回應檢查.
但Health Check Return 200 OK, 真的表示沒問題嘛?
也許某一個環節隨著時間, 回應的越來越慢了呢?
也許某一節點發生故障, 導致整條調用鍊失敗, 在Kibana上輸入Error查找, 也很難找到問題, 因為運維兄弟們不知道服務之間怎調用運作的.

這裡有一篇提到關於監控核可視化的文章Monitoring and Observability

Metrics、Tracing、Logging

OpenTelemetry實現了Metrics、Tracing、Logging.

• Metrics : 提供系統內/外的各種維度的量化指標, 本身具有原子性, 資料可以累加的. 可以是一段時間內的度量(計數器或者是直方圖); 大部分都用Prometheus, 來對時序資料以時間維度來進行分析展示.

• Logging : 紀錄, 描述一些離散(不連續的)事件或者是數據; 大部分都用ELK、Graylog,來進行log的收集跟展示.

• Tracing : 提供了一個請求從接收到處理完成的整個生命週期的路徑, OpenTracing、OpenTelemetry提供了一套規範來進行鏈路追蹤.

看得出來三個維度彼此有著重疊的部份.

依照儲存容量的大小又能這樣區分

因為Logging往往紀錄很多請求資訊,參數,執行時間等等的, 內容跟數量暴多.
但是Metrics通常在意的只有過去幾小時內的資料, 更久之前的不是被壓縮就是被刪除了.

Logging & Metrics

Aggregatable events可聚合的事件, 就像是分析某對象所產生的log; 統計某時段之內的GET、POST、DELETE等操作的匯總資料.

Metrics & Tracing

Request-scoped metrics單個請求中可以計算的數據; 像是該請求之中, 執行SQL的總時長, 調用gRPC的總次數.

Tracing & Logging

Request-scoped events單個請求階段的特定label事件資料; 像是針對執行過程中的錯誤原因.

Metrics & Tracing & Logging

如果能把三者結合 變成 Request-scoped(請求級別), 又能Aggregatable(聚合級別), 那這樣在分析、易懂、展示上就有了全局的觀測體系了.

接著會分享OpenTelemetry和Jaeger