淺談Observability(中)

上篇連結

昨天講了一點點起源, 還有基數跟維度.

Observability與Monitoring

常見的Monitoring 服務有像是, Gatus, Prometheus, Zabbix, ELK等等的.
有一些這次會做些介紹.

Monitoring

Monitoring的必要性是很重要的, 沒有Monitoring, 就不可能實現Observability這概念.

運維團隊從儀表板上來看到性能指標和系統或主機健康狀況, 以及對故障或異常產生告警(Alert). 這些功能在Monitoring工具上是基本具備的.

但是!!!
這些指標是團隊自己建立的, 都是用來顯示團隊可以預測的性能問題和異常情況.
這就表示團隊必須要知道建立哪些指標, 反過來說沒被追蹤或導出出的數據可能會暴露出問題與脈絡.

過往團隊的監控工具多樣化

大部分團隊的成員, 幾乎都是根據自己想要的數據去搭建監控或Log服務, 然後根據自己所需要自然的去建立一組儀表板, 查看各項指標跟Log.
這樣雖然很不錯, 但當公司規模大了, 運維團隊手上有很多種工具, 觀察者需要從多個工具中進行問題的判斷與排查.
但當工具太多且太離散時, 幾乎無法去定位問題了, 只能依靠經驗居多.
這問題在於工具本身是垂直方向的, 沒有辦法橫向的去貫連所有數據, 以及統一資料模型來統一展示.
這樣子還是沒法稱系統為具備可觀測性的.

Observability

上一篇有提到, Observability是根據一個系統的外部輸出的資訊來推斷內部狀態的能力.
可以幫助IT團隊同時觀察或深入了解系統架構中不同應用程式與資源的運行狀況與內部狀態. 透過從每個系統的外部輸出的資料, 來主動察覺到異常, 分析問題並且解決問題.

跟Monitoring相比, Observability涵蓋的更廣的多.
最大的差異就是從系統中提取的資料是否是預先確定要的.

Monitoring是一種收集和分析從單個系統中提取預定資料的解決方案.
Observability則是一種聚合所有系統產出的所有數據的解決方案.
因此, Observability可以說是Monitoring的super set.

軟體的Observability通常指的是基於輸出的資料或者透過遙測來了解應用程式或者業務系統的能力.

上圖出處The Observability Pipeline

Monitoring tells you whether system works, observability lets you ask why it's not working

越往左邊的資料, 表示我們對它們的理解越深; 反之越往右邊越不了解.

在分散式系統中, 這種遙測資料分成三大類

• Logs
• Metrics
• Traces
  明天介紹這三本柱

Telemetry遙測

遙測講的是跨越不同系統來蒐集資料(包含了log,metric,trace)的能力.
像我去年介紹的Fluentbit系列, 就是個蒐集遙測資料的工具, Jaeger, prometheus都是.
之後會介紹的OpenTelemetry中也有定義元件Receiver專門蒐集資料.

有篇文章給更簡單的定義

Telemetry is the automated communication processes from multiple data sources.

參考自What is Telemetry?

參考資料

系統與服務雜談系列-Log Agent - Fluent Bit 簡介
服務開發雜談系列-分布式追蹤服務 Jaeger 簡介與安裝
OpenTelemetry-Receivers
What is Telemetry?