1.背景
Promtheus 本身只支持单机部署，没有自带支持集群部署，也不支持高可用以及水平扩容，它的存储空间受限于本地磁盘的容量。同时随着数据采集量的增加，单台 Prometheus 实例能够处理的时间序列数会达到瓶颈，这时 CPU 和内存都会升高，一般内存先达到瓶颈，主要原因有：
Prometheus 的内存消耗主要是因为每隔 2 小时做一个 Block 数据落盘，落盘之前所有数据都在内存里面，因此和采集量有关。 加载历史数据时，是从磁盘到内存的，查询范围越大，内存越大。这里面有一定的优化空间。 一些不合理的查询条件也会加大内存，如 Group 或大范围 Rate。
2.简介 VictoriaMetrics(VM) 是一个支持高可用、经济高效且可扩展的监控解决方案和时间序列数据库，可用于 Prometheus 监控数据做长期远程存储。
谈到VictoriaMetrics就必须要提到Prometheus，VictoriaMetrics是一个新兴的监控解决方案。它借助Prometheus强大的exporter生态、成熟的规范、服务发现等优点等，融入到Prometheus生态中。VictoriaMetrics官网很多兼容Prometheus参数解释都是直接跳转到Prometheus官网。 VictoriaMetrics可以作为Prometheus的长期远程存储方案，当然VictoriaMetrics也可以完全取代Prometheus，因为VictoriaMetrics基本支持Prometheus配置文件、PromQL、各类API、数据格式等等。 相对于 Thanos，VictoriaMetrics 主要是一个可水平扩容的本地全量持久化存储方案(性能比thanos性能要好，thanos不是本地全量的，它很多历史数据是存放在对象存储当中的，如果要查询历史数据都要从对象存储当中去拉取，这肯定比本地获取数据要慢，VM要比Thanos性能要好，这是必然的)。
2.1特性
VictoriaMetrics 不仅仅是时序数据库，它的优势主要体现在以下几点： 对外支持 Prometheus 相关的 API，可以直接用于 Grafana 作为 Prometheus 数据源使用（可以直接使用VictoriaMetrics 对接grafana） 指标数据摄取和查询具备高性能和良好的可扩展性，性能比 InfluxDB 和 TimescaleDB 高出 20 倍 在处理高基数时间序列时，内存方面也做了优化，比 InfluxDB 少 10x 倍，比 Prometheus、Thanos 或 Cortex 少 7 倍 高性能的数据压缩方式，与 TimescaleDB 相比，可以将多达 70 倍的数据点存入有限的存储空间，与 Prometheus、Thanos 或 Cortex 相比，所需的存储空间减少 7 倍 它针对具有高延迟 IO 和低 IOPS 的存储进行了优化 提供全局的查询视图，多个 Prometheus 实例或任何其他数据源可能会将数据摄取到 VictoriaMetrics 操作简单 VictoriaMetrics 由一个没有外部依赖的小型可执行文件组成 所有的配置都是通过明确的命令行标志和合理的默认值完成的 所有数据都存储在 -storageDataPath 命令行参数指向的目录中 可以使用 vmbackup/vmrestore 工具轻松快速地从实时快照备份到 S3 或 GCS 对象存储中 支持从第三方时序数据库获取数据源 由于存储架构，它可以保护存储在非正常关机（即 OOM、硬件重置或 kill -9）时免受数据损坏 同样支持指标的 relabel 操作 2.2架构 VM 分为单节点和集群两个方案，根据业务需求选择即可。单节点版直接运行一个二进制文件，官方建议采集数据点(data points)低于 100w/s，推荐 VM 单节点版，简单好维护，但不支持告警。集群版支持数据水平拆分。 下图是 VictoriaMetrics 集群版官方的架构图。 上面这里是客户端，比如grafana，它通过负载均衡去查询我们的数据，vmselect是一个无状态的，如果有压力就可以随意去扩展，它从存储上面获取数据，然后返回回去。 vmstorge是有状态的，它是整个集群组件里面唯一一个有状态的组件，所有的时序数据都是存储在这个vmstorge里面的。 vminsert也是一个无状态的，所以也可以随便水平去扩展，它是将数据插入到vmstorge里面去的，可以通过Prometheus远程写的接口将数据写到vminsert。 所以分为了两端，一端是vminsert写数据，一端是vmselect将数据查询出来。 写入数据的来源除了来自于Prometheus，还支持其他数据库。
集群版主要包含以下几个组件：
vmstorage：数据存储以及查询结果返回，默认端口为 8482 vminsert：数据录入，可实现类似分片、副本功能，默认端口 8480（可以将数据分片插入到多个storage实例当中去，具体怎么插入是有一套算法，将数据哈希到某个节点上面去）（vminsert也是无状态的，所以暴露的时候可以使用LB的形式，Prometheus可以通过远程写的方式写入到LB，LB后面对应的是vminsert，vminsert就可以将数据存储到vmstorage里面去）(Prometheus通过remote write远程写的接口将数据写入vminsert) vmselect：数据查询，汇总和数据去重，默认端口 8481，如果有压力可以横向扩展 vmagent：数据指标抓取，支持多种后端存储，会占用本地磁盘缓存，默认端口 8429 vmalert：报警相关组件，不如果不需要告警功能可以不使用该组件，默认端口为 8880 集群方案把功能拆分为 vmstorage、 vminsert、vmselect 组件，如果要替换 Prometheus，还需要使用 vmagent、vmalert（如果完全不想使用Prometheus，那么可以使用vmagent）。从上图也可以看出 vminsert 以及 vmselect（几乎）都是无状态的，所以扩展很简单，只有 vmstorage 是有状态的。
3.操作步骤
3.1安装部署 这里演示环境采用单节点安装，下载二进制文件并配置启动文件。
github地址链接为：https://github.com/VictoriaMetrics/VictoriaMetrics
这里下载的是1.87版本，下载安装包后解压得到二进制文件。
配置服务启动文件放在/etc/systemd/system/目录下。
[Unit] Description=VictoriaMetrics Service After=network.target
[Service] Restart=on-failure WorkingDirectory=/home ExecStart=/usr/local/bin/victoria-metrics -retentionPeriod 3 -selfScrapeInterval 15s -storageDataPath /data
[Install] WantedBy=multi-user.target 解释说明： -storageDataPath 存储路径 -retentionPeriod 指标数据保存时间，单位为月，默认保存周期是一个月 -selfScrapeInterval 开启自身指标抓取，用于普罗监控，采集周期和普罗采集周期保持一致。
启动服务：systemctl daemon-reload
systemctl start victoria-metrics.service
设置开机自启：systemctl enable victoria-metrics.service
服务运行监听端口为8428
3.2普罗配置远程存储
集群使用prometheus operator部署的监控，需要修改crd资源配置普罗远程写入：
添加配置
remoteWrite:
- url: http://172.16.1.128:8428/api/v1/write
普罗配置远程写入后，本地存储数据默认保存一天，这里修改为2h(retention: 2h)，减少本地存储空间使用。
4.验证结果 grafana添加普罗数据源，填入VictoriaMetrics服务地址http://172.16.1.128:8428 如果有多个集群，普罗指标可以都接入VictoriaMetrics进行存储，然后grafana统一对接VictoriaMetrics数据源，通过externalLabels标签进行集群区分，从而实现多集群统一监控展示。
选择该数据源：
可以正常查看监控信息：
添加VictoriaMetrics监控面板，模板id为10229，添加完数据源选择上面配置的。可以看到VictoriaMetrics服务的一些监控信息。
