一、問題背景
目前thanos已經穩定線上上執行了5年了，隨著叢集的數量越來越多，資料量也是水漲船高，大得驚人，查詢時延需要5s以上。
透過對比各種開源時序資料庫，選擇了VictoriaMetrics，以為特定需求的使用者提供最合適的解決方案。
以下是效能比較
二、整體架構
跟官方推薦架構並無太大區別 cluster-victoriametrics
PS：藍色為IDC部署，綠色為k8s pod部署
https://docs.victoriametrics.com/vmagent/
- Can be used as a drop-in replacement for Prometheus for discovering and scraping targets such as node_exporter. Note that single-node VictoriaMetrics can also discover and scrape Prometheus-compatible targets in the same way as
vmagentdoes - see these docs.
vmagent可以用於直接替換prometheus，因此沒必要再架一個prometheus
三、採集端
指標鑑權
指標鑑權是否可以整合在vm-agent？或者我們直接用vmagent的relabel的功能
採集鏈路
採集的鏈路比較長，中間某一個元件如果出現故障或者網路問題都無法保證採集的資料到vmagent。並且假設collector推送指標到指標閘道器失敗，事實上也會導致指標資料丟失
待最佳化項：
簡化採集的鏈路，同時考慮增加一個WAL的模組，保證資料能夠盡力推送到vm-agent。同時vm-agent採用就近部署，降低網路異常帶來的影響。同時可以設定一個TTL，避免失效的資料推到vm
https://docs.victoriametrics.com/stream-aggregation/#reducing-the-number-of-stored-samples
這個純粹是vm-agent的特性，不需要要額外部署元件。
四、備份
speeding-up-backups-for-big-time-series-databases-533c1a927883
總結來說官方說明就是複製並不能解決災難性故障，vm的預設策略是優先保證可用性，而不是資料一致性。我們可以使用vm-backup工具進行增量/全量資料備份
參考文件
migrating-data-from-thanos
thanos-vs-victoriametrics/
github VictoriaMetrics
prometheus-vs-victoriametrics-benchmark-on-node-exporter-metrics
k8s-monitoring-via-vm-cluster