現在查看 Grafana 的官網,幾乎四處都可以看見 Observability-可觀測性這個詞,並將自己定位為 Observability Platform。但 Observability 確切指的是什麼呢?
在負責推廣雲原生的 Cloud Native Computing Foundation(CNCF) 的 Glossary Project 中,Observability 的簡單定義是:
可觀測性是應用程式的一種特性,指的是從其外部輸出中能夠多麼清晰地理解系統的狀態或狀況。電腦系統的性能是通過觀察 CPU 時間、記憶體、磁碟空間、延遲、錯誤等因素來衡量的。系統的可觀測性越高,我們越容易通過查看其運行情況來理解它的表現。
這樣的定義似乎與傳統的 Monitoring 相似,好像都只是透過資訊了解系統狀態。然而,Observability 與 Monitoring 的最大差別在於涵蓋更多不同類型的資訊,並強調資訊間的關聯性,讓我們能夠掌握系統運行的脈絡。簡言之,Observability 可以這樣解釋:
透過各種資訊,清楚了解系統狀態。
這邊有兩個組關鍵字:
當我們擁有足夠的資訊並加以利用,提升系統開發與維運效率就是 Observability 的最終目標。
資訊的生成、收集、儲存等由不同工具處理,例如 Loki、Elastic Search、Prometheus、VMAgent、Jaeger、OpenTelemetry 等。而 Grafana 的強項是將這些數據清楚地呈現並建立彼此的關聯。在 2021 年,Grafana 發表了一篇 Blog,介紹如何針對 Metrics、Logs、Traces 建立關聯。這些年的實作讓 Grafana 能透過以下方式將三者關聯:
如果你想深入了解 Observability,可以參考「時光之鏡:透視過去、現在與未來的 Observability」系列文章。接下來將介紹如何在 Grafana 中設定,使 Metrics、Logs、Traces 能夠相互關聯。
範例 Lab 可以參考 https://github.com/blueswen/pycon-tw-2024-python-observability/tree/main
在 Explore 使用 Split 功能同時開啟 Metrics 與 Logs Panel,透過 Sync 功能可以同步左右兩個 Explore Panel 的時間範圍。
透過 OpenTelemetry 的 SDK,程式可以知道當前處理的內容的 Trace ID,因此可以將 Trace ID 放入 Logs 中,讓 Logs 與 Traces 透過 TraceID 建立關聯。
查詢 Log 時若能取得 Trace ID,則會顯示 Trace 的連結按鈕,點擊後可直接查看該 Trace 的詳細資訊。
在 Loki Data Source 中,使用正則表達式 (?:trace_id)=(\w+)
解析出 Log 中的 trace_id=
,並將其作為 Tempo Data Source 的查詢參數。可在下方的 Debug log message
中確認是否成功取得 Trace ID。
透過 Trace ID 查詢與該 Trace 相關的所有 Log 訊息
在 Tempo 與 Jaeger Data Source 中,可以設定與之關聯的 Loki Data Source。Loki 查詢時需至少一個 Label
,可使用 Trace 中的 service.name
作為 Loki 的 compose_service
Label,並使用 Trace ID 作為篩選條件。
在這筆 Trace 的 Span 中,可以看到有 service.name
這個資訊,值為 app-a
,點擊 Logs for this span
後右側展開的 Loki 查詢條件就會自動帶入 compose_service="app-a"
以及 Trace ID 篩選,這樣就可以查詢到該 Trace 在 app-a
的所有 Log 訊息。
Exemplar 是與 Prometheus 相容的 OpenMetrics 提出的一個新資料類型,在 Metrics 中以註記形式紀錄某筆資料的 Metrics 值與 Trace ID,從而實現 Metrics 與 Traces 的關聯。目前,Prometheus 和 Grafana 都已支援 Exemplar 功能。
在 Prometheus Data Source 中可設定 Exemplar 連結的目標 Trace Data Source,以及 Trace ID 的 Label 名稱
查詢 Metrics 時,Exemplar 的 TraceID
會用來查詢相關 Trace 資訊