Grafana 系列文章（十五）：Exemplars

東風微鳴發表於2023-02-12

Exemplars 簡介

Exemplar 是用一個特定的 trace，代表在給定時間間隔內的度量。Metrics 擅長給你一個系統的綜合檢視，而 traces 給你一個單一請求的細粒度檢視；Exemplar 是連線這兩者的一種方式。

假設你的公司網站正經歷著流量的激增。雖然超過百分之八十的使用者能夠在兩秒內訪問網站，但有些使用者的響應時間超過了正常水平，導致使用者體驗不佳。

為了確定造成延遲的因素，你必須將快速響應的 trace 與緩慢響應的 trace 進行比較。鑑於典型生產環境中的大量資料，這將是非常費力和耗時的工作。

使用 Exemplar 來幫助隔離你的資料分佈中的問題，方法是在一個時間間隔內找出表現出高延遲的查詢痕跡。一旦你把延遲問題定位到幾個示範跟蹤，你就可以把它與其他基於系統的資訊或位置屬性結合起來，更快地進行根本原因分析，從而快速解決效能問題。

對 Exemplar 的支援僅適用於 Prometheus資料來源。一旦你啟用該功能，Exemplar 資料預設是可用的。

Grafana 在 "Explore" 檢視和儀表盤中與指標一起顯示 Exemplar 。每個 Exemplar 顯示為高亮的星星。你可以將游標懸停在 Exemplar 上，檢視唯一的 traceID，它是一個鍵值對的組合。要進一步分析，請點選 "traceID "屬性旁邊的藍色按鈕。示例如下：

截圖顯示了一個 exemplar 的詳細視窗

背景

Exemplars 是最近可觀察性領域的一個熱門話題，這是有原因的。

與 Prometheus 如何在 2012 年開始破而後立了大規模儲存指標的成本結構，並在 2015 年真正實現，以及 Grafana Loki 如何在 2018 年破而後立了大規模儲存日誌的成本結構類似，Exemplar 也在對 trace 做同樣的事情。為了瞭解原因，讓我們看看雲原生生態系統中可觀察性的歷史，以及 Exemplar 能夠實現哪些最佳化。

核心是，Exemplar 是一種透過 ID 從有意義的指標和日誌跳到追蹤的方式。Grafana Tempo，Grafana Labs 的開源、大規模分散式跟蹤後端，就是圍繞這個想法建立的，因為 Exemplar 使分散式跟蹤的成本和效能特徵變得好了。理想情況下，你永遠不需要對你的追蹤進行取樣，而 Tempo 讓這成為現實。

Prometheus

暫時忽略 Prometheus 出色的可擴充套件性、壓縮性和效能，讓我們把注意力放在標籤集上。它們是關於你的時間序列的後設資料。是什麼叢集、什麼服務、哪個客戶、什麼部署級別等等都可以用非層次的鍵值對來編碼。如果你正在讀這篇文章，我很可能不需要說服你這個行業的變化有多大的顛覆性、影響力和永續性；我只是想提醒你，因為它與文字的其餘部分有關。

這在幾年前是革命性的：

acme_http_router_request_seconds_sum{path="/api/v1",method="GET"} 9036.32
acme_http_router_request_seconds_count{path="/api/v1",method="GET"} 807283.0
acme_http_router_request_seconds_sum{path="/api/v2",method="POST"} 479.3
acme_http_router_request_seconds_count{path="/api/v2",method="POST"} 34.0

OpenMetrics

早在 2015-2016 年，相關開發者就計劃同樣的標籤集也應用於日誌和追蹤。這就是為什麼 OpenMetrics 自 2017 年以來一直處在一個叫做 OpenObservability 的 GitHub 組織中，而不是 "僅僅 "一個叫做 OpenMetrics 的組織。

Grafana Loki

有了 Loki，這個夢想在 2018 年實現了。在你的指標和日誌之間無縫移動，沒有問題。這就是 "Like Prometheus but for logs"的標語的由來。

這讓我們不得不將標籤集應用於 trace，對嗎？

OpenMetrics & OpenCensus

2017 年，OpenMetrics 和 OpenCensus 開會，試圖看看這兩個專案是否可以合併。雖然由於設計目標、運營模式和資料模型的不相容而沒有成功，但這次會議還是改變了 OpenMetrics 和 Prometheus 的命運，也是引出了 Grafana Tempo 的核心設計。

Exemplars 設計思路

本質上，Exemplar 就是以下三個想法：

將 trace 與其他可觀察性資料緊密結合。
只透過 ID 跳入 trace。
只有當你知道對哪個 trace 感興趣，以及為什麼感興趣的時候，才跳入該 trace。避免 "頻繁跳入跳出"。

緊密結合

透過 exemplars 將 trace ID 附加到指標上是非常簡單的。在你的度量值（可能還有時間戳）後面加一個 "#"，表示有一個 exemplars 存在，然後新增你的資料。

借用 OpenMetrics 規範中的例子：

# TYPE foo histogram
foo_bucket{le="0.01"} 0
foo_bucket{le="0.1"} 8 # {} 0.054
foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67
foo_bucket{le="10"} 17 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607.789
foo_bucket{le="+Inf"} 17
foo_count 17
foo_sum 324789.3
foo_created  1520430000.123

如果trace_id標籤的名稱和值讓你想起 W3C 分散式跟蹤工作組提出的規範，那就不是巧合了。我們特意採納了 W3C 的規範，同時沒有強制要求它。這使我們能夠在現有的規範工作的基礎上，同時在分散式跟蹤領域穩定下來之前不把 OpenMetrics 捆綁起來。

讓我們看看裡面的實際範例：

顯示延遲小於 1 秒的直方圖桶有一個執行時間為 0.67 秒、ID 為KOO5S4vxi0o的 trace。

顯示 10 秒以下延遲的直方圖桶有一個執行時間為 9.8 秒的 trace，時間為1520879607.789，ID 為oHg5SJYRHA0。

就是這樣！

僅限 ID

索引是昂貴的。把完整的上下文和後設資料放在 trace 上意味著你需要透過它們來搜尋 trace，這就意味著對它們進行索引。但是你想在你的指標、日誌和 trace（以及 conprof、crashdumps 等）上有相同的標籤。但是，由於你在其他資料上已經有了這些後設資料，重用相同的索引以節省成本和時間如何？

透過在一個特定的時間點上將 trace 附在一個特定的時間序列或日誌上，你就可以做到這一點。對於 trace 本身，你只需對 ID 進行索引，就可以了。

僅限感興趣的 traces

自動跟蹤分析是一個廣泛的領域；大量精湛的工程力量被用於使這個乾草堆可被搜尋。

如果有一個更便宜、更有效的方法呢？

日誌已經可以告訴你一個錯誤狀態或類似的情況。你不需要分析 trace 來找到那個錯誤。

指標中的計數器、直方圖等已經是一種高度濃縮和最佳化的資料形式，被提煉成在這種情況下重要的東西。你不需要分析所有的 trace 來找到那個顯示高延遲的 trace。

你的日誌和你的指標已經告訴你為什麼一個 trace 是需要深入調查的。你的標籤給了你如何和在哪裡產生 trace 的背景。在跳入 trace 的時候，你已經知道你在尋找什麼和為什麼。這就大大加快了發現的速度。

Prometheus 啟用 Exemplar storage Feature

?️ Reference:
Exemplars storage | Prometheus Doc

--enable-feature=exemplar-storage

OpenMetrics 介紹了刮削目標為某些度量標準新增 Exemplars 的能力。典型應用場景是對 MetricSet 之外的資料的引用。一個常見的用例是 trace ID。

Exemplar 儲存是作為一個固定大小的圓形緩衝區實現的，它將所有系列的 exemplar 儲存在記憶體中。啟用此功能將使 Prometheus 刮削來的 exemplar 的儲存成為可能。配置檔案塊 storage/exemplars 可以用來控制迴圈緩衝區的大小。一個只有traceID=<jaeger-trace-id>的 exemplar 透過記憶體中的 exemplar 儲存大約使用 100 位元組的記憶體。如果 exemplar 儲存被啟用，我們也會將 exemplar 追加到 WAL 中進行本地持久化（在 WAL 持續時間內）。

在 Prometheus 資料來源中配置 Exemplar

?️ Reference:

有關 Exemplar 配置和如何啟用 Exemplar 的更多資訊，請參閱在 Prometheus 資料來源中配置 Exemplar

? Notes:

該功能在 Prometheus 2.26+ 和 Grafana 7.4+ 上可用。

Grafana 7.4 及以後的版本能夠在 Explore 和儀表盤中顯示與指標相關的 Exemplar 資料。Exemplar 資料是一種將特定事件中的高權重後設資料與傳統時間序列資料聯絡起來的方式。

透過新增外部或內部連結，在資料來源設定中配置 Exemplars。

Exemplars 配置截圖

檢視 Exemplar 資料

?️ Reference:

請參考檢視 exemplar 資料, 瞭解如何從指標和日誌中鑽取和檢視 Exemplar trace 細節。

當 prometheus 資料來源啟用對 exemplar 支援時，你可以在 Explore 檢視或從 Loki 日誌細節中檢視 exemplar 資料。

Explore

Explore 將 exemplar 的跟蹤資料視覺化為高亮的星星和指標資料。關於 Explore 如何將跟蹤資料視覺化的更多資訊，請參考 Explore 中的跟蹤。

要檢查 exemplar 跟蹤的細節。

將你的游標放在一個 exemplar （突出顯示的星星）上。根據你的後端 trace 資料來源，你會看到一個藍色的按鈕，標籤是 Query with <DataSource Name>。在下面的例子中，Trace 的資料來源是 Tempo。
點選 traceID 屬性旁邊的 Query with Tempo 選項。Trace 的細節，包括 trace 中的 span 都列在右邊的獨立皮膚中。

Logs

你也可以在 Explore 中檢視 Loki 日誌中的 exemplar 跟蹤細節。在 Loki 的 Derived fields 連結中使用 regex 來提取 traceID 資訊。現在當你展開 Loki 日誌時，你可以在檢測欄位部分看到 traceID 屬性。要了解更多關於如何將日誌資訊的一部分提取到內部或外部連結中，請參考在 Loki 中使用衍生欄位。

要檢視 exemplar 跟蹤的細節：

展開一個日誌行，向下滾動到 "檢測到的欄位 "部分。根據你的後端跟蹤資料來源，你會看到一個藍色的按鈕，標籤是<資料來源名稱>。
點選traceID屬性旁邊的藍色按鈕。通常情況下，它將有後端資料來源的名稱。在下面的例子中，追蹤的資料來源是 Tempo。追蹤的細節，包括追蹤中的 span 都列在右邊的獨立皮膚中。

帶有顯示跟蹤細節皮膚的 Explore 檢視