k8s监控指标整改のthanos转VictoriaMetrics

一、问题背景

目前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 vmagent does - see these docs.

vmagent可以用于直接替换prometheus，因此没必要再架一个prometheus

 

三、采集端

指标鉴权

指标鉴权是否可以集成在vm-agent？或者我们直接用vmagent的relabel的功能

采集链路

采集的链路比较长，中间某一个组件如果出现故障或者网络问题都无法保证采集的数据到vmagent。并且假设collector推送指标到指标网关失败，事实上也会导致指标数据丢失

 

待优化项：

简化采集的链路，同时考虑增加一个WAL的模块，保证数据能够尽力推送到vm-agent。同时vm-agent采用就近部署，降低网路异常带来的影响。同时可以设置一个TTL，避免失效的数据推到vm

 

stream aggregation

对于pull的指标，指标的拉取时间间隔由vm指定，但是push的方式指标的量完全由collector控制，假设我们需要监控iotio的请求时延、成功率等业务指标，会导致TSDB的存储数据量非常大。这时候我们需要用stream aggregation来进行指标的汇总和过滤。

https://docs.victoriametrics.com/stream-aggregation/

https://docs.victoriametrics.com/stream-aggregation/#reducing-the-number-of-stored-samples

这个纯粹是vm-agent的特性，不需要要额外部署组件。

 

四、备份

replication-and-data-safety

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