跳至主要内容

Observability

這個系列會簡單介紹在現代軟體應用中可觀測性的發展以及利用 Grafana 的 LGTM Stack 搭配 Node.js 搭建一個簡單的可觀測架構。

資訊

題外話，Grafana 的很多產品都是以北歐神話中的神祇或者傳說人物命名的，例如 Loki、Mimir，這也是 Grafana 的一個特色。 相信有玩過神魔之塔的人應該對這些名字不陌生吧 (?)，如果不了解的可以參考 【情報】北歐、希臘神話

Grafana Observability

Observability​

隨著現代軟體系統的發展，從傳統的單體應用到微服務架構，再到各種雲原生工具和服務，軟體系統的規模和複雜度都正在不斷增加。 在這樣的情況下，許多傳統的監控方式已經無法滿足我們對系統狀態和性能的需求，因此，可觀測性 (Observability) 這個概念應運而生，成為了現代軟體開發中一個關鍵詞。

Observability 這個詞起源於控制論 (Cybernetics) 領域，作為衡量系統內部狀態能否通過外部輸出被推導出來的能力。 在軟體工程中，這個詞被重新定義並用於監控以及診斷複雜系統的能力。

軟體的可觀測性通常指的是透過輸出的資料以及遙測 (Telemetry) 來了解系統的內部狀態，並且能夠快速地找到問題的根源。 所謂的遙測指的是跨越系統邊界的資料收集，包括指標 (Metrics)、日誌 (Logs)、追蹤 (Traces) 等。

  • 日誌 (Logs) : 用於記錄系統運行時的事件和錯誤訊息，通常包含時間戳、事件描述、錯誤訊息等，是一種非常容易理解和生成的資料
  • 指標 (Metrics) : 用於量化和度量系統的狀態和性能，通常包含 CPU 使用率、記憶體使用量、請求數量等，也可以很好的用來觸發警報
  • 追蹤 (Traces) : 用於追蹤系統中的請求和事件，通常包含請求的時間線、耗時、調用的服務等，可以幫助我們理解複雜系統中的請求流程
  • 效能剖析 (Profiling) : 用於分析程式碼的效能，通常包含函數的耗時、記憶體使用量等，可以幫助我們找到程式碼中的性能瓶頸

Observability Strategy​

前面所說的日誌、指標、追蹤和效能剖析是可觀測性的基本元素，有了這些元素之後，開發人員可以更準確的了解系統的狀態和性能，並且可以更快地找到問題的根源。 但是，當系統不斷擴增、複雜度不斷增加的時候，反而有可能因此過多的資訊而導致了我們分散注意力，使可觀測性淪為單純蒐集資料的工具。 因此，我們需要一個明確的可觀測性策略，來幫助我們更好地利用可觀測性工具來監控和診斷系統。

USE Method​

USE 指標是由 Brendan Gregg 在提出的，用於衡量系統的性能和效能。

  • Utilization : 使用率，用於衡量系統的負載，如 CPU 使用率、記憶體使用量等
  • Saturation : 飽和度，用於衡量資源是否接近最大負載，可以幫助我們找到系統的瓶頸
  • Errors : 錯誤率，用於衡量系統的穩定性

RED Method​

RED 指標是由 Grafana 的 CTO Tom Wilkie 在 2015 年在 Kausal 公司提出的，與 USE 指標相比，RED 指標更加關注使用者終端的體驗。

  • Rate : 每秒處理的請求量，用於衡量系統的負載跟處理能力
  • Errors : 錯誤率，用於衡量系統的穩定性
  • Duration : 請求耗時，用於衡量系統的性能

Four Golden Signals​

Four Golden Signals 是由 Google 在 SRE 一書中提出的，用來監控分佈式系統和微服務架構的整體健康狀況。

  • Latency : 請求的耗時，反映響應速度
  • Traffic : 請求的量，用於衡量服務的負載
  • Errors : 錯誤率，用於衡量服務的穩定性
  • Saturation : 飽和度，用於衡量服務的資源使用情況

Reference​