Thanos 進階使用指南

1. 使用 Query 聚合數據

如上圖，Thanos Query 可以對接的組件有：

利用 Thanos Query 之間的級聯，我們可以實現跨組件的關聯查詢，組建超大型的監控系統。這也意味着，每個對接的組件應該提供足夠快的 Prometheus API。整個接口的響應時間依賴於最慢組件的響應時間。

當然你也可以在不同層級，提供不同級別的查詢數據源。如下圖:

在全局、區域、實例級別都可以提供查詢接口。

2. 指標數據的拆分及生命週期管理

Thanos 採用的是存儲空間換計算時間和內存的方式，加速長週期指標的查詢。Thanos Compact 組件會將小的存儲塊，合併爲大的存儲塊。如下圖，Compact 組件還提供了對存儲塊的管理能力:

在右下角，我們可以標記刪除一個存儲塊，也可以選擇不對其進行降採樣。

當打開降採樣開關時，Compact 會對所有原始指標數據存儲時長大於 40 h 的進行 5 min 採樣，對所有 5 min 指標數據存儲時長大於 10 day 的進行 1 h 採樣。至於，原始數據、5 min 採樣指標數據、1 h 採樣指標數據保存多長時間，可以通過以下參數配置:

這意味着，我們只能看到全年 1 h 採樣的序列，而局部看不半年前，1 h 之內的任意細節數據；只能看到半年 5 min 採樣序列，而局部看不到三個月前，5 min 內的任何細節數據。

爲了避免衝突，一個 Bucket 也只允許運行一個 Compact。而 Compact 的參數，直接決定了一個存儲 Bucket 的生命週期。

當業務規模龐大時，不可能只用一個 Bucket 存儲全部監控數據，即使對象存儲的性能已經非常好。我們依然需要對數據存儲進行拆分，如下圖:

每一個 Store Gateway 都需要配置一個 Bucket 桶，而一個 Bucket 只允許一個 Compact。可以根據以下維度進行劃分 Bucket:

3. 將 Prometheus 的存儲週期設置爲 6 h

剛使用 Thanos 時，會碰到兩個迷惑的地方:

因爲沒有配置 Prometheus 的查詢源。

因爲 Prometheus 查詢源的存儲週期太長了。

答案在下面這張圖裏:

通常，將 Prometheus 的 --storage.tsdb.retention.time 參數設置爲 3 倍的 Sidecar 上傳存儲塊的週期，也就是 3 * 2 h = 6 h 即可。

4. 調優 Store Gateway 加速查詢

Thanos Store 組件基於對象存儲中的指標數據，對外提供給 Thanos Query 查詢接口。Store 組件提供了一些可以優化查詢的參數。

4.1 設置緩存

--index-cache-size=250MB 默認會使用內存緩存，加速查詢。其他可選的緩存包括，memcached、redis。

4.2 設置查詢範圍

--min-time 和 --max-time 參數可以指定當前 Store 能查詢的數據範圍。

可以直接根據 RFC3339 規範指定 -min-time=2018-01-01T00:00:00Z,--max-time=2019-01-01T23:59:59Z，也可以指定一個相對時間 --min-time=-6w,--max-time=-2w 只允許查詢 2 個星期前但是不超過 6 個 星期的數據。

這種方式不僅可以控制查詢範圍，還可以加快接口數據的返回，屏蔽不必要的查詢結果。

另外一個優化的方向是使用 Query Frontend 組件，同樣是藉助緩存加速查詢響應。

5 重新設計標籤系統

使用 Thanos Query 合併多個 Prometheus 數據源之後，遇到的首要問題就是，怎麼區分不同數據源的數據。如果沒有提前規劃好 external_labels 將會導致各種環境、區域下的指標數據混淆在一起，根本無法使用。

如下圖，在每一個 Prometheus 實例中都需要設置一些必要的 Labels 信息，以區分不同的 Prometheus 實例數據。

另一方面，在查詢和使用監控指標數據時，也需要帶上這些標籤。這部分的工作量會體現在修改 Grafana 的展示面板和查詢 API 的參數調整上。

6. 總結

本篇主要是在生產環境下使用 Thanos 的一些思考和總結。剛開始使用 Thanos 時的目標是，能夠部署起來；部署到線上之後的目標是，能夠用起來；最後的目標是能夠預見一些未來的問題，提前解決掉。

7 參考

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/JB7VNlRftaqlfNqNEMd5Pg

猜你喜歡