VictoriaMetrics 家族：Metrics + Logs + Traces 一体化可观测性-平芜编程栈

当 Prometheus 触发了一条告警"订单服务 P99 延迟超过 2 秒"，你想立刻看到是哪些慢请求、哪些错误堆栈导致了延迟飙升，然后定位到具体是哪一步数据库调用慢——这就是 Metrics、Logs、Traces 三者协同的经典场景。

VictoriaMetrics 家族（VictoriaMetrics + VictoriaLogs + VictoriaTraces）让这种协同从 "理想" 变成 "开箱即用"。

读完本篇，你应该能回答：VictoriaLogs/VictoriaTraces 与 VictoriaMetrics 是什么关系？LogQL 和 MetricsQL 如何统一设计？Metrics+Logs+Traces 一体化监控如何落地？Grafana 如何实现三数据源联合查询？

VictoriaMetrics VictoriaLogs VictoriaTraces MetricsQL LogQL 一体化监控 vmui Grafana Promtail 可观测性 OTLP

学习重点
必须掌握：Metrics+Logs+Traces 三支柱协同架构、LogQL 语法、Grafana 联合查询
需要理解：VictoriaLogs/VictoriaTraces 数据接入、与 Loki/Jaeger 的差异

一、可观测性三支柱：Metrics、Logs、Traces

思考记忆提示— Metrics 告诉你"什么坏了"，Logs 告诉你"为什么坏了"

关联前面章节：#04 整体数据流、#11 CNCF 生态、#70 Prometheus API 兼容
关联工具：vmagent、Promtail、vmui、Grafana
面试/考试高频提问：Metrics 和 Logs 各自适用什么场景？为什么要协同？

在云原生监控领域，Metrics（指标）、Logs（日志）、Traces（链路）是可观测性的三大支柱，每一种都回答不同的问题：

Metrics（指标）：聚合的、低成本的数值型数据，回答"什么坏了"——比如"订单服务 P99 延迟飙升"。典型代表：Prometheus、VictoriaMetrics。
Logs（日志）：详细的、原始的事件记录，回答"为什么坏了"——比如"这次慢请求是因为数据库查询超时"。典型代表：Elasticsearch、Loki、VictoriaLogs。
Traces（链路）：跨服务的请求追踪，回答"哪里坏了"——比如"延迟发生在第 3 步数据库调用"。典型代表：Jaeger、Zipkin。

三大支柱不是孤立的，而是互补协同的。Metrics 发现异常 → 通过 traceID 跳转到 Traces 查看调用链 → 通过 requestID 跳转到 Logs 查看具体错误堆栈——这是现代可观测性平台的"金标准"工作流。

我理解源码的意思是说

可观测性三支柱各有优势和局限，互补构成完整体系：

Metrics：定期采集聚合数值，发现异常触发告警。优点是快、便宜、能看趋势；缺点是粒度粗，看不到具体病因。
Logs：记录原始事件详情，提供完整上下文。优点是有上下文、能看到细节；缺点是量大。
Traces：跨服务请求追踪，定位延迟发生在哪一步。优点是能看到全链路；缺点是开销大、采样率受限。

VictoriaMetrics 家族（VM + VictoriaLogs + VictoriaTraces）覆盖可观测性三支柱：

VictoriaMetrics：处理 metrics，Prometheus 兼容
VictoriaLogs：处理 logs，LogQL（Loki 兼容）
VictoriaTraces：处理 traces，支持 OTLP 协议，兼容 Jaeger/Tempo API

三者的优势是统一的 label 关联机制——同一个请求的 metric、log、trace 用相同的 label 标识，无需额外配置就能在 vmui 里联合查询。

1.1 VM 家族的三产品战略：Metrics+Logs + Traces

VictoriaMetrics 公司推出了 VictoriaMetrics、VictoriaLogs、VictoriaTraces 三款产品，覆盖可观测性三支柱。三者共享相似的架构哲学：单二进制部署、MergeSet 存储引擎、本地 SSD 优先。

设计精髓

VictoriaMetrics 和 VictoriaLogs 共用部分核心库，包括 storage、encoding、mergeset、fs 等。VictoriaLogs 在 MergeSet 引擎上构建 LogQL 查询，实现与 VictoriaMetrics 的协同。具体复用程度请参考 VictoriaLogs 源码（github.com/VictoriaMetrics/VictoriaLogs）。

对比维度	VictoriaMetrics	VictoriaLogs
数据类型	数值型（float64/int64）	文本型（任意 UTF-8 字符串）
查询语言	MetricsQL（PromQL 扩展）	LogQL（Grafana Loki 兼容 + VM 扩展）
核心库	lib/storage, lib/mergeset	vlstorage（基于 lib/mergeset）
压缩策略	NearestDelta 等 6 种数值算法	字典压缩 + 增量编码
索引结构	indexDB（8 种 nsPrefix）	类似 indexDB（针对 log labels）
写入协议	Prometheus remote_write	JSON / Loki push API / syslog
查询协议	Prometheus HTTP API	LogsQL HTTP API / Grafana Loki API

必记闭环逻辑（核心考点）

可观测性三支柱（Metrics/Logs/Traces）解决不同问题，协同工作流是"Metrics 发现异常 → Traces 看调用链 → Logs 看错误堆栈"。VictoriaMetrics 公司的产品矩阵覆盖全部三支柱：VictoriaMetrics 处理 metrics，VictoriaLogs 处理 logs，VictoriaTraces 处理 traces（三者均为独立开源产品）。Metrics 和 Logs 在 vmui 中实现联合查询。

二、LogQL 与 MetricsQL 的统一设计哲学

思考记忆提示— LogQL 是 Loki 兼容 + VM 扩展

关联前面章节：#56 PromQL 执行引擎、#57 MetricsQL vs PromQL
关联工具：Grafana 数据源配置、vmui 查询构建器
面试/考试高频提问：VictoriaLogs 的 LogQL 和 Grafana Loki 的 LogQL 有什么区别？

LogQL（Loki 查询语言）最初由 Grafana Loki 定义。VictoriaLogs 在保持兼容的基础上做了大幅扩展，让 LogQL 拥有接近 PromQL 的表达力。

2.1 LogQL 基础语法

LogQL 查询由过滤表达式和管道聚合两部分组成：

LogQL 查询语法 │ ├── 【过滤表达式】筛选日志条目 │ ├── label filter: {app="order-service", level="error"} │ ├── line filter: "timeout"或"database.*error" │ └── 组合: {app="order"} |= "error" != "healthcheck" │ └── 【管道聚合】对结果做统计 ├── 数值函数: | rate(), count_over_time() ├── 聚合函数: | sum by (app) (rate(...)) ├── 解析函数: | unpack, regexp, line_format └── 数学运算: | / 1000, + 1, * 0.5

一个完整示例：sum by (app) (rate({app="order-service", level="error"}[5m]))，意思是"过去 5 分钟内、订单服务、错误日志、按 app 聚合的速率"。

2.2 VictoriaLogs 对 LogQL 的扩展

VictoriaLogs 在兼容标准 LogQL 基础上，新增了多个扩展函数，让 LogQL 拥有类似 PromQL 的能力。具体函数列表和数量请参考 VictoriaLogs 官方文档（docs.victoriametrics.com/victoria-logs/querying/）。

扩展函数	功能	类比 PromQL
stats	统计函数（uniq/count/sum/avg/max/min）	count、sum
partition	分组聚合	by (...)
sort	排序	topk/bottomk
limit	限制返回数量	无直接对应
offset	分页偏移	无直接对应
fields	提取字段	label_replace
field_names	列出所有字段	无直接对应
values	提取字段值	无直接对应
row	行操作	无直接对应
copy	复制字段	无直接对应
rename	重命名字段	label_replace
delete	删除字段	无直接对应
pack	打包字段为 JSON	无直接对应
unpack	解包 JSON	无直接对应

这些扩展让 VictoriaLogs 摆脱了"只能做日志查询"的局限，可以处理半结构化数据（如 JSON 日志），完成类似 SQL 的复杂分析。

实战技巧：从 PromQL 用户过渡到 LogQL

如果你熟悉 PromQL，LogQL 几乎可以零成本学习：

PromQL 的 {label="value"} 选择器 = LogQL 的 {label="value"} 选择器，语法完全一致
PromQL 的 rate(metric[5m]) = LogQL 的 rate({...}[5m])
PromQL 的 sum by (app) (...) = LogQL 的 sum by (app) (...)
唯一的差异是 LogQL必须以 | 管道开头才能做 line filter（按日志内容筛选）

必记闭环逻辑（核心考点）

LogQL 是 VictoriaLogs 的查询语言，完全兼容 Grafana Loki 的标准 LogQL，并扩展了多个独有函数（stats/partition/sort/fields 等）。LogQL 的核心是过滤表达式（label filter + line filter）+ 管道聚合（统计函数 + 解析函数）。对熟悉 PromQL 的用户几乎零学习成本。

三、数据接入：从日志产生到 VictoriaLogs 存储

思考记忆提示— 日志接入有两种方式：vmagent 复用 + Promtail 专用

关联前面章节：#71 vmagent 架构、#88 streamaggr 实时聚合
关联工具：vmagent、Promtail、Fluent Bit、Filebeat、syslog
面试/考试高频提问：如何把 k8s 中的容器日志采集到 VictoriaLogs？

VictoriaLogs 支持多种数据接入方式，覆盖了云原生环境的几乎所有日志源。

3.1 5 种主流接入方式

VictoriaLogs 数据接入全景 │ ├── 【1. vmagent 推送】（推荐） │ └── vmagent 抓取 /var/log/containers/*.log，解析为 syslog 格式推送到 VL │ 优势: 复用 vmagent，无需额外部署 │ 适用: k8s DaemonSet 部署，统一采集 │ ├── 【2. Promtail / Loki 推送】（Loki 生态） │ └── Promtail 用 Loki push API 写入，VictoriaLogs 兼容该 API │ 优势: Grafana 生态成熟，文档多 │ 适用: 已部署 Promtail 的环境 │ ├── 【3. Fluent Bit / Fluentd】（CNCF 生态） │ └── 通过 fluent-bit 插件或 HTTP output 推送 │ 优势: 生态最广，400+ 插件 │ 适用: 复杂日志解析需求 │ ├── 【4. Filebeat / Logstash】（Elastic 生态） │ └── 配置 http output 推送到 VictoriaLogs │ 优势: ELK 生态成熟 │ 适用: 已有 ELK 栈的环境 │ └── 【5. 直接 HTTP POST】（轻量场景） └── curl 推送 JSON 日志 优势: 简单直接，无需 agent 适用: 应用直接写入、调试场景

3.2 推荐方案：vmagent + k8s DaemonSet

在 Kubernetes 环境中，最推荐用vmagent DaemonSet采集容器日志。vmagent 复用 Prometheus 抓取配置，天然支持 k8s 服务发现和 relabel：

# vmagent 配置示例（抓取容器日志并推送到 VictoriaLogs） scrape_configs: - job_name: 'k8s-pods-logs' kubernetes_sd_configs: - role: pod relabel_configs: # 把 k8s label 提取为 log label - source_labels: [__meta_kubernetes_pod_label_app] target_label: app - source_labels: [__meta_kubernetes_pod_name] target_label: pod - source_labels: [__meta_kubernetes_namespace] target_label: namespace # 推送到 VictoriaLogs remote_write: - url: http://victoria-logs:9428/insert/loki/api/v1/push # VictoriaLogs 兼容 Loki push API # 启动 vmagent 时加上 syslog 监听 # vmagent -syslog.listenAddr=:1514

vmagent 会监听容器运行时（containerd/CRI-O）的日志目录 /var/log/containers/*.log，解析为 syslog 格式，附带 k8s metadata，然后推送到 VictoriaLogs。

避坑指南：syslog 格式 vs Loki 格式

vmagent 推送日志时，有两种格式可选：

syslog 格式（/insert/syslog）：标准 RFC5424 格式，适合应用直接 syslog 输出
Loki push API 格式（/insert/loki/api/v1/push）：JSON streams 格式，适合 Promtail/Fluent Bit 等已有 agent 推送

推荐Loki push API 格式，因为它支持 JSON 嵌套字段，更适合现代结构化日志。

必记闭环逻辑（核心考点）

VictoriaLogs 支持 5 种主流数据接入方式，vmagent DaemonSet 是 k8s 环境推荐方案。vmagent 复用 Prometheus 抓取配置，通过 syslog 监听或 Loki push API 推送到 VictoriaLogs。整个接入链路无需额外学习成本（对熟悉 PromQL/Promtail 的用户）。

四、Grafana 三数据源联合查询实战

思考记忆提示— 联合查询通过 Grafana 变量联动 + Data Links 实现

关联前面章节：#11 CNCF 生态、#70 Prometheus API 兼容、#91 Grafana 集成
关联工具：vmui、Grafana Explore、Grafana Data Links
面试/考试高频提问：如何从一条 metrics 告警跳转到对应的日志和链路？

Metrics+Logs+Traces 协同的最高价值是"从异常指标一键跳转到关联日志和链路"。在 v1.146.0 版本中，vmui 提供独立的 Metrics 页面（ExploreMetrics）和 Trace 页面（TracePage），而三数据源联合查询主要通过 Grafana 实现。

4.1 vmui 的实际页面结构

vmui 包含以下核心页面，通过 URL 路径访问：

/#/explore：ExploreMetrics，指标发现和快速查询
/#/trace：TracePage，JSON 文件导入查看链路
/#/custom-panel：自定义面板，支持 Metrics + Traces 联合展示
/#/alert：告警规则管理

重要澄清：vmui 没有独立的 Logs 查询页面

vmui 在 v1.146.0 中没有内置的 Logs 查询面板。日志查询需要通过以下方式：

部署独立的 VictoriaLogs 实例，访问其自带 UI
在 Grafana 中添加 Loki 类型数据源（VictoriaLogs 兼容）

VictoriaLogs 提供独立的 Web UI，可通过 http://victoria-logs:9428/ 直接访问。

4.2 Grafana 三数据源联合查询

在 Grafana 中，可以通过变量联动 + Data Links实现 Metrics + Logs + Traces 三者联合查询：

# Grafana Dashboard JSON 配置片段 panels: # 1. 指标面板（VictoriaMetrics 数据源） - title: "P99 延迟" datasource: prometheus # 配置为 VictoriaMetrics targets: - expr: 'histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{app=~"$app"}[5m]))' legendFormat: "{{status}}" # Data Link：点击指标跳转到 Logs links: - url: 'http://grafana:3000/explore?schema=loki&queries...' title: "查看相关日志" params: expr: '{app="${__field.labels.app}", level="error"}' # 2. 日志面板（VictoriaLogs 数据源，通过 Loki 兼容） - title: "错误日志" datasource: loki # 配置为 VictoriaLogs targets: - expr: '{app=~"$app", level="error"} |= "timeout"' refId: "B" # 3. 变量定义（让多个面板联动） templating: variables: - name: app type: query datasource: prometheus query: 'label_values(http_request_duration_seconds_bucket, app)'

4.3 Metrics→Traces→Logs 完整工作流

三数据源联合的"金标准"工作流通过 traceID 串联：

三数据源联合查询工作流 │ ├── 【Step 1】vmui 发现异常 │ └── Metrics 面板显示 P99 延迟突刺 │ ├── 【Step 2】Grafana 跳转 Traces │ └── 通过 Data Link 携带 traceID 跳转到 Jaeger/VictoriaTraces │ └── 查看完整调用链，定位到 slow span │ ├── 【Step 3】跳转 Logs 查详情 │ └── 从 trace span 获取 traceID │ └── 查询 VictoriaLogs: {trace_id="xxx"} │ └── 获取该请求的完整错误堆栈 │ └── 【核心】统一 label 关联 └── 同一请求共享: app, trace_id, request_id └── 三数据源无缝跳转

实战技巧：vmui + Grafana 组合使用

vmui：快速发现指标异常、查看告警、探索 Metrics 命名
Grafana：复杂 Dashboard、变量联动、Data Links 跳转
VictoriaLogs UI：独立日志查询、LogQL 调试

三者组合使用，覆盖可观测性全场景。

必记闭环逻辑（核心考点）

vmui 在 v1.146.0 中没有内置 Logs 查询面板，三数据源联合查询主要通过Grafana实现。核心机制是变量联动（多个面板共用相同变量筛选）和Data Links（点击跳转到其他数据源）。完整工作流是 Metrics 发现异常 → 跳转 Traces 定位慢调用 → 跳转 Logs 查错误堆栈，通过 traceID 串联。

五、Grafana 三数据源集成：Metrics + Logs + Traces 联动

思考记忆提示— Grafana 是 VM 家族三产品联合查询的最佳入口

关联产品：VictoriaMetrics（Prometheus 数据源）、VictoriaLogs（Loki 数据源）、VictoriaTraces（Jaeger/Tempo 数据源）
关联工具：Grafana Explore、Grafana Data Links、Grafana Variables
核心机制：变量联动 + Data Links 跨数据源跳转

Grafana 是 VM 家族三产品联合查询的最佳入口。通过添加三个数据源、配置变量联动和 Data Links，可以实现 Metrics → Traces → Logs 的完整可观测性工作流。

5.1 Grafana 数据源配置

在 Grafana 中添加三个数据源：

数据源名称	Grafana 类型	URL	备注
VictoriaMetrics	Prometheus	http://victoriametrics:8428	支持 Prometheus HTTP API
VictoriaLogs	Loki	http://victoria-logs:9428	VL 兼容 Loki HTTP API
VictoriaTraces	Jaeger 或 Tempo	http://victoria-traces:9417	VT 兼容 Jaeger API