Prometheus實戰--儲存篇

前言

Prometheus之於kubernetes(監控領域)，如kubernetes之於容器編排。
隨著heapster不再開發和維護以及influxdb 叢集方案不再開源，heapster+influxdb的監控方案，只適合一些規模比較小的k8s叢集。而prometheus整個社區非常活躍,除了官方社區提供了一系列高品質的exporter，例如node_exporter等。Telegraf(集中採集metrics) + prometheus的方案，也是一種減少部署和管理各種exporter工作量的很好的方案。
今天主要講講我司在使用prometheus過程中，儲存方面的一些實戰經驗。

Prometheus 儲存瓶頸

通過prometheus的架構圖可以看出，prometheus提供了本機存放區，即tsdb時序資料庫。本機存放區的優勢就是營運簡單,缺點就是無法海量的metrics持久化和資料存在丟失的風險，我們在實際使用過程中，出現過幾次wal檔案損壞，無法再寫入的問題。
當然prometheus2.0以後壓縮資料能力得到了很大的提升。為瞭解決單節點儲存的限制，prometheus沒有自己實現叢集儲存，而是提供了遠程讀寫的介面，讓使用者自己選擇合適的時序資料庫來實現prometheus的擴充性。

prometheus通過下面兩種方式來實現與其他的遠端儲存系統對接

• Prometheus 按照標準的格式將metrics寫到遠端儲存
• prometheus 按照標準格式從遠端的url來讀取metrics

metrics的持久化的意義和價值

其實監控不僅僅是體現在可以即時掌握系統運行情況，及時警示這些。而且監控所採集的資料，在以下幾個方面是有價值的

• 資源的審計和計費。這個需要儲存一年甚至多年的資料的。
• 故障責任的追查
• 後續的分析和挖掘，甚至是利用AI，可以實現警示規則的設定的智能化，故障的根因分析以及預測某個應用的qps的趨勢，提前HPA等，當然這是現在流行的AIOPS範疇了。

Prometheus 資料持久化方案

方案選型

社區中支援prometheus遠程讀寫的方案

• AppOptics: write
• Chronix: write
• Cortex: read and write
• CrateDB: read and write
• Elasticsearch: write
• Gnocchi: write
• Graphite: write
• InfluxDB: read and write
• OpenTSDB: write
• PostgreSQL/TimescaleDB: read and write
• SignalFx: write
• clickhouse: read and write

選型方案需要具備以下幾點

• 滿足資料的安全性，需要支援容錯，備份
• 寫入效能要好，支援分區
• 技術方案不複雜
• 用於後期分析的時候，查詢文法友好
• grafana讀取支援，優先考慮
• 需要同時支援讀寫

基於以上的幾點，clickhouse滿足我們使用情境。
Clickhouse是一個高效能的列式資料庫，因為側重於分析，所以支援豐富的分析函數。

下面是Clickhouse官方推薦的幾種使用情境：

• Web and App analytics
• Advertising networks and RTB
• Telecommunications
• E-commerce and finance
• Information security
• Monitoring and telemetry
• Time series
• Business intelligence
• Online games
• Internet of Things

ck適合用於儲存Time series
此外社區已經有graphouse項目，把ck作為Graphite的儲存。

效能測試

寫入測試

本地mac，docker 啟動單台ck，承接了3個叢集的metrics，均值達到12910條/s。寫入毫無壓力。其實在網盟等公司，實際使用時，達到30萬/s。

查詢測試

fbe6a4edc3eb :) select count(*) from metrics.samples;SELECT count(*)FROM metrics.samples┌──count()─┐│ 22687301 │└──────────┘1 rows in set. Elapsed: 0.014 sec. Processed 22.69 million rows, 45.37 MB (1.65 billion rows/s., 3.30 GB/s.)

其中最有可能耗時的查詢：
1)查詢彙總sum

fbe6a4edc3eb :) select sum(val) from metrics.samples where arrayExists(x -> 1 == match(x, 'cid=9'),tags) = 1 and name = 'machine_cpu_cores' and ts > '2017-07-11 08:00:00'SELECT sum(val)FROM metrics.samplesWHERE (arrayExists(x -> (1 = match(x, 'cid=9')), tags) = 1) AND (name = 'machine_cpu_cores') AND (ts > '2017-07-11 08:00:00')┌─sum(val)─┐│     6324 │└──────────┘1 rows in set. Elapsed: 0.022 sec. Processed 57.34 thousand rows, 34.02 MB (2.66 million rows/s., 1.58 GB/s.)

2）group by 查詢

fbe6a4edc3eb :) select sum(val), time  from metrics.samples where arrayExists(x -> 1 == match(x, 'cid=9'),tags) = 1 and name = 'machine_cpu_cores' and ts > '2017-07-11 08:00:00' group by toDate(ts) as time;SELECT    sum(val),    timeFROM metrics.samplesWHERE (arrayExists(x -> (1 = match(x, 'cid=9')), tags) = 1) AND (name = 'machine_cpu_cores') AND (ts > '2017-07-11 08:00:00')GROUP BY toDate(ts) AS time┌─sum(val)─┬───────time─┐│     6460 │ 2018-07-11 ││      136 │ 2018-07-12 │└──────────┴────────────┘2 rows in set. Elapsed: 0.023 sec. Processed 64.11 thousand rows, 36.21 MB (2.73 million rows/s., 1.54 GB/s.)

3) Regex

fbe6a4edc3eb :) select sum(val) from metrics.samples where name = 'container_memory_rss' and arrayExists(x -> 1 == match(x, '^pod_name=ofo-eva-hub'),tags) = 1 ;SELECT sum(val)FROM metrics.samplesWHERE (name = 'container_memory_rss') AND (arrayExists(x -> (1 = match(x, '^pod_name=ofo-eva-hub')), tags) = 1)┌─────sum(val)─┐│ 870016516096 │└──────────────┘1 rows in set. Elapsed: 0.142 sec. Processed 442.37 thousand rows, 311.52 MB (3.11 million rows/s., 2.19 GB/s.)

總結：
利用好所建索引，即使在大資料量下，查詢效能非常好。

方案設計

關於此架構，有以下幾點：

• 每個k8s叢集部署一個Prometheus-clickhouse-adapter 。關於Prometheus-clickhouse-adapter該組件，下面我們會詳細解讀。
• clickhouse 叢集部署，需要zk叢集做一致性表資料複製。

而clickhouse 的叢集如下：

• ReplicatedGraphiteMergeTree + Distributed。ReplicatedGraphiteMergeTree裡，共用同一個ZK路徑的表，會相互，注意是，相互同步資料
• 每個IDC有3個分區，各自佔1/3資料
• 每個節點，依賴ZK，各自有2個副本

這塊詳細步驟和思路，請參考ClickHouse叢集搭建從0到1。感謝新浪的鵬哥指點。只不過我們實際情境是時序資料，所以將ReplicatedMergeTree表引擎改為ReplicatedGraphiteMergeTree，讓資料具備graphite_rollup的功能。

Prometheus-Clickhuse-Adapter組件

Prometheus-Clickhuse-Adapter(Prom2click) 是一個將clickhouse作為prometheus 資料遠程儲存的適配器。
prometheus-clickhuse-adapter，該項目缺乏日誌，對於一個實際生產的項目，是不夠的，此外一些資料庫連接細節實現的也不夠完善，已經在實際使用過程中將改進部分作為pr提交。

在實際使用過程中，要注意並發寫入資料的數量，及時調整啟動參數ch.batch 的大小，實際就是批量寫入ck的數量，目前我們設定的是65536。因為ck的Merge引擎有一個300的限制，超過會報錯

Too many parts (300). Merges are processing significantly slower than inserts

300是指 processing，不是指一次批量插入的條數。

總結

這篇文章主要講了我司Prometheus在儲存方面的探索和實戰的一點經驗。後續會講Prometheus查詢和採集分離的高可用架構方案。