Grafana Mimir:支持亂序的指標採集
譯自：New in Grafana Mimir: Introducing out-of-order sample ingestion
很早之前在使用thanos和多實例的Prometheus時經常會在thanos日誌中看到時序數據亂序的問題。當時唯一的辦法就是從對象存儲中手動刪除這部分數據，非常不方便。Grafana Mimir中對亂序數據的支持是一個很大的改進。
傳統的Prometheus TSDB僅支持接收1小時內的有序採樣，然後丟棄其他樣本。這種方式可以讓Prometheus高效地存儲樣本。但在實際中，Prometheus的拉取模式(以一定節奏從被觀察的目標中提取數據)也給用戶的使用帶來了很多限制。
在一些使用場景下可能會存在亂序數據，如：
- 異步啓動並寫入指標的IoT設備
- 使用消息總線(如使用隨機分片的Kafka)的複雜傳遞架構，可能存在擁塞延遲。
- 某些情況下受網絡連接而孤立的Prometheus實例會嘗試推送老的樣本。
支持亂序的設計方案
我們和Dieter Plaetinck編寫了一個設計文檔來解決亂序問題。
數據的攝取
Prometheus TSDB有一個內存區域，稱爲head block。我們通過共享該head block來避免產生重複的內存索引，同時可以減低內存消耗。對於head block中的每個時序，我們在內存中保存了過去30個未壓縮的亂序樣本，並將其與有序樣本完全隔離開來。當內存chunk中的亂序樣本達到30個之後，它將會被壓縮並刷新到磁盤，並從head block開始內存映射。
這一點類似head block處理有序樣本的方式：內存中的有序樣本會保存在一個壓縮的chunk中，最大可以保存120個樣本。由於需要保存到內存中，且亂序的chunk是未壓縮的，因此我們將樣本數限制爲30，防止消耗過多的內存。
我們還引入了一個新的方式，稱爲Write-Behind-Log (WBL)。WBL類似Prometheus TSDB中的Write-Ahead-Log (WAL)。在WBL中，當在TSDB中添加樣本之後纔會寫數據，而WAL是在TSDB數據變更前寫數據。我們使用WBL來記錄攝取的亂序樣本，因爲在攝取樣本前，我們並不知道樣本是有序的還是亂序的。
下圖展示了該過程。注意亂序chunk之前可能會重疊(下圖中：OOO = Out of Order)。
白色表示內存映射的亂序chunk，黃色表示活動狀態(表示新來的樣本，活動狀態的樣本可能會被合併)的亂序Head Chunk，而藍色表示有序的Head Chunk，可以看到上述過程如下：
- 一開始內存中沒有任何時序數據
- 此時來了兩個樣本，一個是時序爲600的樣本，另一個是時序爲750的樣本，它們作爲一個有序的chunk
- 來了30個時序爲1到150之間的亂序樣本
- 來了10個樣本，由於前面的chunk已經滿了，因此需要爲亂序數據創建一個新的chunk
- 隨着樣本的增加，需要創建更多的chunks。注意chunk1和chunk2有一個重疊的值，300
- 來了一個新的以時序0開始的樣本，它被插入了chunk3，此時chunk3與chunk0、1、2重疊
查詢
Prometheus TSDB有一個有用的抽象-查詢器，它將head block和磁盤的持久塊上的所有內容視爲“塊讀取器”。TSDB使用一個head block包裝器來讀取固定時間範圍內的有序數據。類似地，我們實現了另一個圍繞head block且僅讀取亂序chunk的包裝器。這樣，head block可以體現爲兩種塊讀取器：僅讀取有序數據的，和僅讀取亂序數據的。
現有的查詢邏輯可以無縫地處理塊讀取器和其他持久塊數據的合併結果。但查詢器要求塊讀取器按排序提供非重疊的塊。這樣，head block的亂序塊讀取器需要在查詢時合併重疊的chunks(如下圖)。當訪問樣本時，會發生合併，但不會重新創建塊。
壓縮
TSDB中的持久塊會與2小時Unix時間戳對齊。對於有序數據，每過2小時，我們會獲取head block中的2小時內的老數據，並將其轉變爲持久塊，這個稱爲head block的壓縮過程。在壓縮完有序數據後，也會對亂序數據進行壓縮。
由於亂序數據的特點，其可能包含跨2個小時塊的樣本。因此，根據需要，我們在單次亂序數據的壓縮過程中會生成多個持久塊，如下所示。該持久塊與其他持久塊類似。在壓縮之後，會根據需要清理WBL和其他內容。這些塊可能會與磁盤中已有的塊或head block中的有序數據重疊。
一旦產生了這些塊，就完成了亂序代碼的處理。TSDB能夠從重疊的塊中請求數據，並在需要時合併重疊的塊。
Grafana Mimir 和 Grafana Cloud中的亂序樣本攝取
我們引入了一個名爲out_of_order_time_window的配置參數來指定可以支持多老的亂序樣本。默認爲0，即不支持亂序樣本。如果設置爲1小時，則Grafana Mimir 會攝取過去1小時內的所有亂序樣本。
性能特徵
性能取決於：
- 攝取亂序樣本的模式
- 亂序樣本的數目
- 攝取的亂序樣本率
在很多情況下，所有上述條件都會導致攝取器的CPU使用率增加。在有限驗證的條件下，我們發現除處理亂序樣本的攝取器(攝取和查詢)上的CPU利用率爲50%外，其他組件沒有看到CPU變動。
在我們的環境中，內存的增加並不明顯。但當時間序列的很大比率爲亂序樣本時會導致內存變化，但總體增長應該仍然很小。