Prometheus新版本 2.13.0 的發布，他包含了許多bug fix和改進。妳可以在這兒 查看變更 。這裏有壹個許多用戶或項目十分期待的功能： chunked, streamed version of remote read API .
在本文中，我將深入介紹我們在遠程協議中更改了哪些內容，更改的原因以及如何有效地使用它。
自從1.x版本，Prometheus有了與遠程存儲通過 remote API 交互的能力。
這個API允許第三方系統通過兩種方法與metrics 數據交互:
這是將Prometheus數據放於第三方系統存儲的最常見做法。在這種模式中，Prometheus周期性地向給定端點發送壹批樣本數據。
在3月份基於 WAL 的Remote write在可靠性和資源占用率上都得到了巨大的提升。值得壹提的是 這裏 所有的第三方存儲都支持該種方式。
read方法不太常見。它是在 March 2017
添加的(服務端內部包含)，自那以後沒有看到顯著的發展。
普羅米修斯2.13.0版本修復了Read API中已知的資源瓶頸。本文將重點討論這些改進。
remote read的關鍵點是不經過PromQL計算的前提下直接查詢Prometheus storage ( TSDB )。 他和 Querier 接口類似，用於從存儲層獲取數據。
這個特性允許對Prometheus采集到的時序數據進行訪問， remote read主要使用場景如下：
遠程讀API暴露了壹個簡單的HTTP endpoint ，它期望數據格式如下:
通過這個協議，客戶端可以通過 matchers 和 start 以及 end 的時間區間來獲取到特定的時序數據
返回數據格式如下：
Remote read返回匹配的時序數據，包含raw數據（包含vaule和時間戳）
對於remote read有如下2個關鍵問題。它雖然很容易使用和理解，但是我們定義的protobuf格式的單個HTTP請求中沒有streaming功能。其次，響應的是raw格式數據(float64值和int64時間戳)，而不是TSDB存儲的基於‘Chunk’的經過編碼和壓縮後的數據。
沒有streaming的遠程讀取的server端邏輯是:
下面是Prometheus和Thanos Sidecar(remote read 客戶端)在remote read請求期間內的內存使用情況:
值得註意的是，即便對於Prometheus原生Http接口的 query_range 方法而言， 查詢10,000個series 也並不是壹個好主意，因為妳的瀏覽器也不希望獲取，存儲然後渲染數百兆字節的數據。此外，對於儀表板和呈現目的來說，擁有這麽多數據也是不現實的，因為人不可能讀取這麽大量的數據。這就是為什麽我們通常我們不會發起大於20個時序的查詢請求。
雖然這樣做很好，但是另外壹種常規技術做法是通過聚合查詢去獲得聚合好的20個時間序列，但底層查詢引擎必須通過上千個序列去計算響應（例如使用 aggregators 。這就是為什麽像Thanos這樣的系統，在其他數據中，使用TSDB數據從遠程讀取，通常情況下，請求很重。
理解Prometheus在查詢時是如何叠代數據的對理解這個問題很有幫助。核心概念可以從 Querier 的 Select 方法返回的壹個叫 SeriesSet 的類型中看出來。接口如下：
上面這壹系列接口為進程提供了壹種基於“流”的能力。我們不再需要預先計算包含樣本的序列列表。使用這個接口，每個 SeriesSet.Next() 實現都可以根據需要獲取序列。我們還可以通過 SeriesIterator.Next 動態地分別獲取每個樣本。
通過這個協議，Prometheus可以盡可能小的分配內存，因為PromQL引擎可以更優的對樣本進行叠代，以計算出查詢結果。TSDB以同樣的方式實現SeriesSet，以壹種最佳的方式從存儲在文件系統中的塊中壹個接壹個地獲取序列，從而最小化分配。
這對 remote read API來說十分重要，因為我們可以以相同的調用形式來叠代式的向客戶端發送單個時序中的壹部分chunk形式的數據。因為protobuf原生沒有分割消息數據的機制，所以我們 擴展了 proto定義來允許發送 壹組小的protocol buffer消息 ，而不是單個巨大的消息體。我們把這種remote read模式稱作 STREAMED_XOR_CHUNKS 而老的模式叫 SAMPLES 。擴展了protocol意味著Prometheus再也不需要緩沖整個響應了，他可以在調用 SeriesSet.Next 或者 SeriesIterator.Next 叠代時發送壹個有序的獨立幀，以盡可能的與下壹個時序數據復用同壹個內存頁。
現在， STREAMED_XOR_CHUNKS 模式的響應是以下壹組Protobuf消息（幀）
妳可以發現消息幀不包含raw格式數據了。這是我們做的第二點提升：我們以chunk的形式發送消息樣本（觀看 這個視頻 來了解更多關於chunk的知識）它與我們存儲在TSDB中的chunk完全相同。
我們最終使用了以下服務端邏輯:
我們所有的設計都在 這裏
與舊的解決方案相比，這種新方法的性能如何?
我們來將Prometheus 2.12.0 和 2.13.0 remote read特型進行對比。就如本文開頭給出的初步結果，我用Prometheus做服務端，用Thanos的sidecar做遠程讀取的客戶端。我使用 grpcurl 對Thanos sidecar執行gRPC調用來測試remote read。整個測試在我的筆記本（(Lenovo X1 16GB, i7 8th）上docker中的k8s環境裏進行。（使用 kind )
數據是人工生成的，表示高度動態的10,000個序列(最壞的情況)。
測試的詳細結果請見 thanosbench repo
減少內存是我們解決方案的主要目標。在整個請求過程中，Prometheus的緩沖區大約為50MB，而Thanos只有少量的內存使用。多虧了流式Thanos gRPC StoreAPI, sidecar現在是壹個非常簡單的代理。
此外，我嘗試了不同的時間範圍和序列數量，但正如預期的那樣，我壹直看到Prometheus的分配最多為50MB，而Thanos的分配則沒有。這證明無論妳單個請求多少個樣本，我們的remote read始終使用恒定的內存大小。分配內存的多少受請求數據數量的影響大大減少，無論妳請求多少數據，他都始終分配相同的內存。
在並發性限制的幫助下，這使得針對用戶流量進行容量規劃變得更加容易。
在我的測試期間，CPU使用率也有所提高，使用的CPU時間減少了兩倍。
通過streaming和更少的編碼次數，我們同時還實現了減少remote read請求的響應延遲。
Remote read 8小時時間跨度包含10000個序列：
2h時間跨度：
在Prometheus和Thanos側處理和序列化的時間上，除了低2.5倍的響應延遲外， stream版本的響應是及時的，而非 stream版本客戶端延遲27s（ real minus user time）。
Remote read以向後和向前兼容的方式進行了擴展。這要歸功於protobuf和 accepted_response_types 被舊版本所忽略的字段，同時如果舊的客戶端（假設采用 SAMPLES 模式的remote read）不支持 accepted_response_types 他也能正常工作。
remote read協議前後版本兼容方式：
為了使用新的基於streamed remote read的Prometheus v2.13.0，第三方系統必須將 accepted_response_types = [STREAMED_XOR_CHUNKS] 添加到請求中。
Prometheus就會用 ChunkedReadResponse 來替代老版本消息體。每個 ChunkedReadResponse 消息都符合varint大小和固定大小bigendian uint32用於CRC32 Castagnoli校驗和。
對於go語音來說我們推薦使用 ChunkedReader 來直接讀取流
註意， storage.remote.read-sample-limit 設置將在 STREAMED_XOR_CHUNKS. storage.remote.read-concurrent-limit 條件下不再起作用。
也提供了壹個新的配置項 storage.remote.read-max-bytes-in-frame 來控制每個消息體的最大大小。建議默認為1MB，因為谷歌建議protobuf消息 不大於1MB .。
正如前面提到的， Thanos 因為這個特性收益頗豐。Streamed remote read 在 v0.7.0 被增加，因此，配合Prometheus 2.13.0 或更高版本，都將自動采用 streamed remote read 的形式。
Release 2.13.0引入了擴展的 remote read和Prometheus服務器端實現，然而，為了充分利用擴展的遠程讀協議的優勢，目前還需要做壹些事情:
綜上所述，分塊、流遠程讀取的主要好處是:
如果您有任何問題或反饋，壹如既往，請隨時在GitHub上提交問題或在郵件列表上提問。