淺談Observability(下)

14th鐵人賽 observability

雷N

團隊E04

2022-09-04 00:05:56

2657 瀏覽

分享至

淺談Observability(下)

上篇連結
 中篇連結

Observability的三本柱

抱歉不是這種三本柱

是這三本柱! Logs, Metrics, Traces

Logs

m...大家都很熟悉了吧?
程式寫一寫最常輸出debug information的方法之一.
用來紀錄某個時間點發生了某件事情. 本質上是時間+空間的組合.
Log是不可變且帶有時間戳的離散(不連續)事件紀錄, 不會有人會想對過往的紀錄做修改吧.
Log通常有三種形式: Plaintext, Structured, Binary

Plaintext log就任意格式的文字資料.

I, [2021-02-23T13:26:23.505892 #22473]  INFO -- : [6459ffe1-ea53-4044-aaa3-bf902868f730] Started GET "/" for ::1 at 2021-02-23 13:26:23 -0800

Structured log, 小弟去年有簡單介紹.

Binary log, 不是文字而是以Binary格式進行存儲. 最常見的就是MySQL的binlog, systemd journal log

systemd journal log
上圖為Journal log

Log是個非常容易生成的資料.
但Log的普遍缺點就是缺少上下文資訊或者高維度的資料, 像是誰從哪裡調用這功能的;
也不一定與任何用戶的請求或事務有相關連,
但過往開發與運維團隊都很依賴Log來幫助他們自己理解系統行為.

Metrics

Metric指標, 是一段時間內測量到的數值的聚合.
提供了跨越時間與空間(資料)的總覽.

Metric可以用數學建模或者是預測的方式, 獲得現在或者過去一段時間內的訊息.
Metric是連續且帶有時間戳的測量數值. 類型是固定的, 所以在存儲的效能, 計算處理, 壓縮和檢索查找都有很棒的優化效果.
也因為壓縮比率很高, 通常也就會保存更久之前的歷史數據, 便於構建出反應歷史趨勢的儀表板資訊.

Metric跟Log相比, 比較容易被數學公式, 機率統計等給計算轉換.
像是抽樣, 聚合, 匯總等,
這些特徵使得metric更適合用在展示系統的健康狀況, 硬體資源利用率, 服務的請求率之類的.
也很適合用來觸發警報, 因為數值就能很好定義出告警的門閥值.

Prometheus的metric格式

<metric name>{<label name>=<label value>, ...}

# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"}               721

metric name與labels用來識別用, 可以想成資料庫的index
timestamp和value則是用來當作實際存儲的資料. 資料本身就精度達millisecond等級的timestamp和float64的數值. 格式固定的, 竟能用好的演算法達到很高的壓縮比.
(參考自Distributed System Observability)

因為只有這些資訊, 所以metric能幫我們理解單個系統的性能表現與行為.
但沒辦法協助我們理解跨越多個系統的請求其生命週期與過程中的問題.

Traces

鏈路追蹤, 小弟以前也稍微介紹過
在連續的時間維度上, 把空間給排列展示出來, 透過Trace,Span做關聯.
就能直觀地看到request或任何操作在分散式系統中所有節點的全部過程.
這裡講的比較偏向Distributed tracing.

Tracing資料本質上是一種Log.
跟自定義的Log相比, Trace可以提請請求的調用鏈路中所有經過的路徑跟請求的結構, 提供這類的可視化. 這可以幫助我們找到系統性能瓶頸或故障節點.

如上圖, 假設這是我們的Request鏈路.
Trace之所以能幫助我們找到問題或性能瓶頸, 是因為當Reqeust開始時, 會為它分配一個全局唯一的ID(TraceID), 在每個工作(處理)單元也都記錄一個Span(跨度), 這些span都有夾帶TraceID.

Trace提供了Request或操作整個生命周期的跨度上下文資訊, 並且協助我們能理解架構的交互方向與整體系統形狀.

這TraceID很重要, 是滿足上篇講的高基數高維度的資料, 若能在Traces, Metrics, Logs中都有夾帶這TraceID的話, 就能用這TraceID, 來貫穿三個維度的遙測資料, 來做分析判讀.
SpanID用來紀錄自己的工作單元, 其實每次傳播出來的資訊裡也會有ParentSpanID.
有這些ID, 就能畫出類似樹狀結束的圖示來表達請求方向與架構形狀可視性.