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
数据源配置步骤

登录 Grafana → Configuration → Data Sources
点击 “Add data source”
搜索 “Prometheus”，填写 VictoriaMetrics URL，保存
搜索 “Loki”，填写 VictoriaLogs URL，保存
搜索 “Jaeger”，填写 VictoriaTraces URL，保存
5.2 Grafana Dashboard 配置
一个完整的三数据源 Dashboard 配置示例：

Grafana Dashboard JSON 配置

{
“panels”: [
# ========== Panel 1: Metrics 指标面板 ==========
{
“title”: “HTTP 请求 P99 延迟”,
“type”: “timeseries”,
“datasource”: “VictoriaMetrics”,
“targets”: [
{
“expr”: "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{app=~“KaTeX parse error: Expected group as argument to '\"' at position 6: app\"}̲[5m]))", …{__from📅iso}%22,%22KaTeX parse error: Expected group after '_' at position 2: {_̲_to:date:iso}%2…{trace_id}%22%7D%5D”
}
]
},

# ========== Panel 2: Logs 日志面板 ==========
{
  "title": "错误日志",
  "type": "logs",
  "datasource": "VictoriaLogs",
  "targets": [
    {
      "expr": "{app=~\"$app\", level=\"error\"} |= \"timeout\"",
      "refId": "A"
    }
  ]
},

# ========== Panel 3: Traces 链路面板 ==========
{
  "title": "链路追踪",
  "type": "tracing",
  "datasource": "VictoriaTraces",
  "targets": [
    {
      "query": "${trace_id}",
      "refId": "A"
    }
  ]
}

],

========== 变量定义（实现联动） ==========

“templating”: {
“list”: [
{
“name”: “app”,
“type”: “query”,
“datasource”: “VictoriaMetrics”,
“query”: “label_values(http_request_duration_seconds_bucket, app)”,
“description”: “选择应用”
},
{
“name”: “trace_id”,
“type”: “text”,
“description”: “从 Metrics 传递的 traceID”
}
]
}
}
5.3 变量联动配置
变量联动是 Grafana 多面板协作的核心机制：

Grafana 变量联动机制
│
├── 【变量定义】
│ ├── app: 从 VM 提取所有 app label 值
│ ├── trace_id: 用户输入或从 Metrics 提取
│ └── time: Grafana 内置时间范围变量
│
├── 【面板联动】
│ ├── Metrics 面板: {app=“KaTeX parse error: Expected 'EOF', got '}' at position 5: app"}̲ │ ├── Logs 面…app”}
│ └── Traces 面板: trace_id=“$trace_id”
│
└── 【效果】
└── 选择 app 后，所有面板同时筛选该应用数据
5.4 Data Links 跨数据源跳转
Data Links 允许从任一面板跳转到其他数据源：

从 Metrics 跳转到 Traces：点击异常指标，携带 traceID 跳转到 Traces 面板
从 Traces 跳转到 Logs：点击某个 span，查询该 trace_id 的所有日志
从 Logs 跳转到 Metrics：点击某条日志，跳转到对应时间段的指标

Metrics 面板的 Data Link 配置（JSON 格式）

{
“title”: “查看链路”,
“url”: “${__field.labels.trace_id}”,
“internal”: false,
“targetDashboardUid”: “traces-dashboard”,
“targetPanelId”: 3
}

或使用 Grafana Explore 跳转

{
“title”: “Grafana Explore”,
“url”: “http://grafana:3000/explore?left=%5B”KaTeX parse error: Expected group after '_' at position 2: {_̲_from:date:iso}…{__to📅iso}“,“VictoriaTraces”,%7B%22query%22:%22${trace_id}%22%7D%5D”
}