企业官网建设流程全解析

VictoriaMetrics 监控落地：时序数据库从接入到出图的实操笔记

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics

你刚接手一批新机器，需要给它们建一套指标监控：机器上线第二天，就要能回答"过去一个月每台机器的 CPU 走势如何"。Prometheus 默认只留 15 天数据，而这个需求要一年。VictoriaMetrics 就是为这类场景准备的时序数据库——它兼容 PromQL，靠本地存储把长保留期的成本压到可接受范围。它提供二进制、Docker 镜像和集群组件三档部署形态，查询用 MetricsQL（PromQL 的超集，现有 PromQL 可以直接跑），自带一个名叫 vmui 的网页查询界面。这篇内容会带你把单节点跑起来、把第一个 exporter 接进来、用 vmui 查出曲线，最后给出慢查询定位和长保留期的调法。

数据怎么流：一张图看清 VictoriaMetrics 的职责分工

先说结论：单节点形态下，采集、存储、查询、界面全在一个二进制里，官方叫它 vmsingle，一个进程扛数百万条活跃指标没有压力，测试和小规模生产直接用它就行。

规模上来后拆开就是集群，Cluster-VictoriaMetrics.md 里描述的结构如下：

读这张图只需要记住两条链路：

• 写入链路：Prometheus remote write、OTLP、InfluxDB 等协议的数据打进来，经 vmauth 做负载均衡，由 vminsert 按指标名加全部标签做一致性哈希，分片到若干台 vmstorage；
• 读取链路：vmselect 是无状态查询前端，从各 vmstorage 取数、做计算和缓存，前端同样挂一层 vmauth，后面接 Grafana、vmui、告警系统。

采集侧还有一块独立拼图 vmagent：负责本地缓冲、服务发现、relabel 和简单聚合，采完以 Prometheus remote write 协议写回 VictoriaMetrics。它既能被独立部署，也能替代集群中"只采集"的角色。

装起来、接进来、用起来

装起来：单节点一个二进制跑通

先让数据流动起来——启动单节点 VictoriaMetrics，数据落在本地目录。二进制方式从官方 releases 页下载victoria-metrics-linux-amd64-v1.151.0.tar.gz解压即可，里面只有一个victoria-metrics-prod，自包含、无需安装。

tar xzf victoria-metrics-linux-amd64-v1.151.0.tar.gz ./victoria-metrics-prod -storageDataPath=/var/lib/victoriametrics -selfScrapeInterval=10s

-selfScrapeInterval=10s让它每 10 秒采一次自身指标，起步阶段就有数据可查。日志出现started server at http://0.0.0.0:8428/就起来了。Docker 用户可以直接：

docker pull victoriametrics/victoria-metrics:v1.151.0 docker run -d --name vm -p 8428:8428 -v $(pwd)/victoria-metrics-data:/victoria-metrics-data \ victoriametrics/victoria-metrics:v1.151.0 -storageDataPath=/victoria-metrics-data -selfScrapeInterval=10s

接进来：把 node_exporter 抓进 VictoriaMetrics

这步是告诉 VictoriaMetrics 去哪台机器取指标。先在本机跑一个 node_exporter（从官方 releases 下载解压，默认监听 9100 端口），再写一份最小采集配置：

# scrape.yaml scrape_configs: - job_name: node-exporter static_configs: - targets: ['localhost:9100']

重启时加一个参数即可生效，其余配置项都可以先不写：

./victoria-metrics-prod -storageDataPath=/var/lib/victoriametrics -promscrape.config=scrape.yaml

打开http://localhost:8428/targets确认state: up。先别急着怀疑配置：首次抓取完成前它显示down是正常现象，等几秒刷新。目标数量上百、或者需要给采集链路加缓冲和 relabel 时，把抓取任务挪给独立 vmagent，配置格式与上面一致，remote write 指向http://<vm>:8428/api/v1/write即可。vmagent 的接入面长这样：

用起来：在 vmui 里查出第一组曲线

数据进来后不用接 Grafana 也能看图。打开http://localhost:8428/vmui，在查询框输入一条 MetricsQL 按回车：

100 - avg(rate(node_cpu_seconds_total{mode="idle"})) * 100

不出曲线时，去/vmui/#/metrics指标浏览器里翻指标名，比背名字快。要正式看板就接 Grafana：数据源类型选 Prometheus、URL 填http://<vm>:8428，然后把 dashboards/ 目录下现成的 JSON 导入，比如victoriametrics.json（单节点）和victoriametrics-cluster.json（集群）。

跑通之后：三个值得花时间调的方向

慢查询：先定位再优化

加一个启动参数，让执行超过 1 秒的查询打印统计信息（设成0关闭，1us记录全部）：

./victoria-metrics-prod -search.logSlowQueryStats=1s

它输出的是每次慢查询的执行统计，配合 dashboards/query-stats.json 这个官方仪表盘，能把"哪个查询、哪个租户、慢在哪"定位出来。企业版默认就开着这项（阈值 5 秒），开源版靠参数显式打开，行为细节见 docs/victoriametrics/query-stats.md。

长保留期：用降采样压存储

保留期用-retentionPeriod控制，比如直接给-retentionPeriod=1y。一年原始粒度扛不住时上降采样——-downsampling.period=30d:5m表示保留 30 天后只留 5 分钟粒度的数据。这里有个容易漏的点：集群模式下这个参数必须同时传给 vmstorage 和 vmselect 两端，只改一边会出现查询结果与存储粒度对不上的情况，Cluster-VictoriaMetrics.md 的 Downsampling 一节有完整写法。

横向扩容：何时上集群模式

单节点垂直扩展见顶后（写入速率、查询并发或磁盘 IO 持续打满），切到集群：vminsert、vmselect、vmstorage 三类节点各自水平扩，vmauth 前置做负载均衡。扩容和分片的具体规划，按 docs/victoriametrics/Cluster-VictoriaMetrics.md 里的容量估算方法做，别拍脑袋。

常见的坑和继续深入的路径

• 刚写入的数据最长 30 秒后才能被查到。curl 推了一条立刻查不到，先等半分钟再怀疑配置；
• /targets里新 target 显示down不一定是挂了，首抓完成前都是这个状态；
• 降采样参数只配了 vmstorage 没配 vmselect，查询侧仍按原始粒度读，效果等于没配。

想继续往下挖：指标与保留、降采样的概念看 docs/victoriametrics/keyConcepts/，查询语法细节看 docs/victoriametrics/MetricsQL.md，告警规则用 app/vmalert/ 跑。下一步建议：把现有 Prometheus 的 remote write 指过来，先双写一周，再把保留期换成你要的年限。

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics