前言

Prometheus 就是一个很好的时序数据库，对于监控数据量没有超过千万级的 情况下没必要进行分布式存储。一般的监控数据存3个月以内即可，所以数据量并不会很大。

并且生产环境可以搞多个Proms数据源在Grafana中做统一的告警。并且在时序数据库的排名表如下， VictoriaMetrics  都排不上号。

官网

##  github
https://github.com/VictoriaMetrics/operator### 
https://github.com/VictoriaMetrics/VictoriaMetrics/## web
https://victoriametrics.com/##  参考文档
https://www.nestealin.com/7dbee069/

VictoriaMetrics 优点

当前单节点Prometheus集中存储多个集群数据，官方架构问题无法横向扩展优化。数据可异地存储。

• 需要分布式数据存储，支持并发查询，优化查询性能
• 可以兼容Prometheus写入或服务端中转写入
• 可支持数据副本（次要）
• VictoriaMetrics是一个快速、高效和可扩展的时序数据库，可作为Prometheus的长期存储，比如要存监控数据半年或者一年以上
• VictoriaMetrics支持PromQL查询语言，也支持Influxdb行协议，对当前主流的时序协议支持比较好

VictoriaMetrics 架构图

单实例的 victoriametric只有一个进程。

集群版的victoriametrics有3类进程，即3类微服务组成：

• vmstorage: 数据存储节点，负责存储时序数据；
• vmselect: 数据查询节点，负责接收用户查询请求，向vmstorage查询时序数据；
• vminsert: 数据插入节点，负责接收用户插入请求，向vmstorage写入时序数据;

在部署时可以按照需求，不同的微服务部署不同的副本，以应对业务需求：

• 若数据量比较大，部署较多的vmstorage副本；
• 若查询请求比较多，部署较多的vmselect副本；
• 若插入请求比较多，部署较多的vminsert副本；

集群中vmselect、vminsert节点都是无状态的，唯一有状态的是vmstorage。

部署模式

单节点版

直接运行一个二进制文件，既可以运行，官方建议采集数据点(data points)低于100w/s，推荐VM单节点版，简单好维护，但不支持告警。

集群版

支持数据水平拆分，把功能拆分为vmstorage、 vminsert、vmselect，如果要替换Prometheus，还需要vmagent、vmalert。

集群版主要特点：

• 支持单节点版本的所有功能。
• 性能和容量水平扩展。
• 支持时间序列数据的多个独立命名空间（多租户）。
• 支持多副本。
• 图表功能比Proms强大

单机部署实践

## 
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.84.0/victoria-metrics-linux-amd64-v1.84.0.tar.gz##
systemctl enable --now victoria-metrics-prod.service

编写启动文件

vim /etc/systemd/system/victoria-metrics-prod.service

[Unit]
Description=For Victoria-metrics-prod Service
After=network.target[Service]
ExecStart=/opt/victoria-metrics/victoria-metrics-prod -storageDataPath=/opt/victoria-metrics/data -retentionPeriod=3[Install]
WantedBy=multi-user.target

配置Prometheus：

## 写入其他时序数据库
remote_write:- url: http://10.10.10.120:8428/api/v1/write

验证：

###
http://10.10.10.120:8428/vmui/

添加Grafana数据源

因为Prometheus的数据是 存其他时序数据库，所以你原来的Prometheus数据源也是可以查到数据的，两者不冲突。

当然你也可以配置 vm的数据源查数据。因为vm支持PromsSQL。 Grafana 导入指定模板：8919