VictoriaMetrics 1.146.0 源码专题【左扬精讲】------ VictoriaLogs 协同：Metrics 到 Logs 的一体化监控

当 Prometheus 触发了一条告警"订单服务 P99 延迟超过 2 秒"，你想立刻看到是哪些慢请求、哪些错误堆栈导致了延迟飙升------这就是 Metrics 与 Logs 协同的经典场景。VictoriaLogs 作为 VictoriaMetrics 家族的"日志孪生兄弟"，让这种协同从"理想"变成"开箱即用"。

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

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

学习重点

必须掌握：Metrics+Logs 协同架构、LogQL 语法、vmui 联合查询

需要理解：VictoriaLogs 数据接入、压缩原理、与 Loki 的差异

一、可观测性三支柱：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 = CT 影像（穿越式扫描）：把多个科室的检查结果串联起来，看清内部结构。优点是能看到全链路；缺点是开销大、采样率受限。

VictoriaMetrics 家族（VM + VictoriaLogs）的优势是**"两个科室共用一套病历号"**------同一个请求的 metric 和 log 用相同的 label 关联，无需额外配置就能在 vmui 里联合查询。

1.1 VM 家族的"Metrics+Logs"双产品战略

VictoriaMetrics 公司在 2023 年推出了 VictoriaLogs，与 VictoriaMetrics 组成"Metrics+Logs"双产品矩阵。两者共享相同的架构哲学：
设计精髓

VictoriaMetrics 和 VictoriaLogs 共用同一套核心库（lib/），包括 storage、encoding、mergeset、fs 等。这意味着 VM 在 Metrics 领域的所有优化（MergeSet、6 种压缩算法、inmemoryPart 1 秒刷盘）都自动复用到 VictoriaLogs。这是"代码即资产"的最佳实践------90% 的代码可复用，10% 差异化定制。

对比维度	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 家族的"Metrics+Logs"双产品通过共享核心库实现代码复用，VictoriaLogs 在 MergeSet 引擎上构建 LogQL 查询，让 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 查询由过滤表达式 和管道聚合两部分组成：

text 复制代码

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 基础上，新增了 14 个独有函数，让 LogQL 拥有类似 PromQL 的能力：

扩展函数	功能	类比 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 ，并扩展了 14 个独有函数（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 种主流接入方式

text 复制代码

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：

yaml 复制代码

# 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://victorialogs: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 的用户）。

四、Metrics+Logs 联合查询：vmui 实战

思考记忆提示 --- 联合查询是"看 metric → 跳 log"的工作流核心

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

Metrics+Logs 协同的最高价值是"从异常指标一键跳转到关联日志"。vmui（VictoriaMetrics 自带的 Web UI）原生支持这种工作流。

4.1 vmui 的双面板布局

vmui 提供左右双面板布局，左侧是 Metrics 查询，右侧是 Logs 查询，两者通过共享 label联动：

text 复制代码

vmui 双面板工作流
┌─────────────────────────────┬─────────────────────────────┐
│  Metrics Query              │  Logs Query                 │
│                             │                             │
│  sum(rate(                  │  {app="order-service",      │
│    http_request_duration_   │   level="error"}            │
│    seconds_bucket{          │   |= "timeout"              │
│      app="order-service"    │   | stats count() as errs   │
│    }[5m]                    │                             │
│  )) by (status)             │                             │
│                             │                             │
│  [时序图]                   │  [日志条目列表]              │
│  P99 突刺 2.5s →            │  - 12:34:56 db timeout     │
│                             │  - 12:34:57 db timeout     │
│                             │  - 12:34:58 retry failed   │
│                             │                             │
│  [点击异常点]                │  [自动跳转到该时段日志]       │
└─────────────────────────────┴─────────────────────────────┘
   ↑                              ↑
   │                              │
   └─── 共享 label: app="order-service" ───┘

当用户在左侧 Metrics 面板发现异常点（某个时间戳的指标飙升），点击该点，右侧 Logs 面板自动定位到该时间点附近的相关日志。这是真正的"指标驱动日志"工作流。

4.2 Grafana 联合查询方案

在 Grafana 中，可以通过变量联动实现类似的联合查询：

yaml 复制代码

# 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}}"

  # 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)'

当用户在下拉框选择某个 app 时，指标面板和日志面板同时筛选，实现 Grafana 层面的联合查询。
实战技巧：跨数据源 traceID 跳转

更高级的联合查询需要通过 traceID 关联：

应用在日志中输出 trace_id=abc123
在 metric 中也携带 trace_id label（通过 relabel 添加）
在 Grafana 中配置 Data Links，点击 metric 异常点 → 跳转到 Jaeger UI 查 trace → 再跳转到 VictoriaLogs 查该 trace 的所有日志

这是"Metrics→Traces→Logs"完整工作流的实现方式。
必记闭环逻辑（核心考点）

vmui 双面板布局是"看 metric → 跳 log"的核心工作流，左侧 Metrics 异常点可一键跳转到右侧 Logs 面板。Grafana 通过变量联动 和数据源 Data Links实现类似功能。高级场景通过 traceID 串联，实现 Metrics→Traces→Logs 的完整可观测性链路。

五、VictoriaLogs vs Grafana Loki：架构差异

思考记忆提示 --- 两者查询语法兼容，但架构哲学截然不同

关联前面章节：#10 与其他 TSDB 对比、#11 CNCF 生态、#41 MergeSet vs LSM Tree
关联工具：VictoriaLogs、Loki、MinIO、Cassandra
面试/考试高频提问：VictoriaLogs 和 Loki 在存储引擎上有什么本质区别？

VictoriaLogs 和 Grafana Loki 都属于"日志领域的 Prometheus 替代品"，但两者的架构哲学差异巨大。

5.1 核心差异对比

对比维度	VictoriaLogs	Grafana Loki
存储引擎	自研 MergeSet（基于 VM 核心库）	分片 + 对象存储（S3/GCS）+ BoltDB 索引
数据存储位置	本地 SSD（单二进制，无外部依赖）	S3/GCS/Azure Blob（必须云存储）
索引存储	本地文件（类似 VM indexDB）	BoltDB（单机）/ Cortex 模式（多租户）
部署复杂度	单二进制，开箱即用	需要 MinIO + Cassandra + 多个组件
查询性能	本地 SSD 高速读取，P99 通常 < 1s	对象存储 IO 受限，P99 通常 2-5s
压缩比	字典压缩 + 增量编码，10-30x	Gzip 块压缩，3-5x
运维成本	低（无外部依赖）	高（需要管理 MinIO、Cassandra）
适用场景	中小规模日志（< 10TB/天）	大规模日志（> 10TB/天）

5.2 性能基准对比

根据 VictoriaMetrics 官方博客（VictoriaLogs vs Loki）的基准测试：

写入吞吐：VictoriaLogs 比 Loki 高 3-5 倍（同样硬件配置）
查询延迟：VictoriaLogs 比 Loki 低 5-10 倍（本地 SSD vs 对象存储）
资源占用：VictoriaLogs CPU/内存只有 Loki 的 1/3
压缩比：VictoriaLogs 比 Loki 高 2-3 倍

这些性能差异的根源是存储引擎的选择------Loki 依赖对象存储做冷数据存储，天生受限于 S3/GCS 的 IO 延迟；VictoriaLogs 用本地 SSD 跑 MergeSet 引擎，IO 延迟低 100 倍以上。
设计精髓

VictoriaLogs 的架构哲学是**"以 VM 的成功经验复制到日志领域"**。VM 的核心优势是 MergeSet 引擎 + 本地 SSD + 单二进制部署，VL 完全复用这套设计。结果是：VL 在中小规模（< 10TB/天）场景下，部署简单度、性能、资源占用全面优于 Loki。但 VL 缺乏 Loki 的多租户、Cortex 模式、长期冷存储能力，更适合"中小规模 + 追求性能 + 运维简单"的场景。
必记闭环逻辑（核心考点）

VictoriaLogs vs Loki 的核心差异是存储引擎：VL 用 MergeSet + 本地 SSD（单二进制、无外部依赖），Loki 用分片 + 对象存储 + BoltDB 索引（需要 MinIO/Cassandra 多组件）。性能上 VL 全面领先（写入 3-5x、查询 5-10x、压缩 2-3x），运维上 VL 更简单（无外部依赖）。选择 VL 适合中小规模 + 性能优先；选择 Loki 适合大规模 + 多租户场景。

六、生产部署最佳实践

思考记忆提示 --- VictoriaMetrics + VictoriaLogs 一体化部署的 5 个关键点

关联前面章节：#95 HA 高可用、#134 k8s 生产部署、#140 安全加固
关联工具：Helm、Operator、vmagent、vmauth
面试/考试高频提问：如何部署生产级 VictoriaMetrics + VictoriaLogs 一体化监控？

最后给出生产部署的 5 个关键最佳实践，确保 Metrics+Logs 一体化监控稳定运行。

6.1 实践 1：vmagent 统一采集，Metrics 和 Logs 复用

不要为 Metrics 和 Logs 分别部署采集 agent。vmagent 同时支持：

抓取 Prometheus metrics（通过 scrape_configs）
监听 syslog 日志（通过 -syslog.listenAddr=:1514）
接收 Loki push API（通过 Loki 协议路径）

统一用 vmagent DaemonSet，简化运维。

6.2 实践 2：label 命名空间统一规划

Metrics 和 Logs 应该使用相同的核心 label 命名，方便联合查询：

yaml 复制代码

# 推荐的统一 label
# 业务标识
- app: 应用名（如 order-service）
- env: 环境（prod/staging/dev）
- region: 地域（us-east-1/cn-north-1）
- version: 版本号（v1.2.3）

# 资源标识
- namespace: k8s 命名空间
- pod: Pod 名
- container: 容器名
- node: 节点名

# 不要在 Logs 中使用高频变化 label（如 request_id、user_id）

避坑指南：避免 label cardinality 爆炸

LogQL 的 label 索引类似 indexDB，高频变化 label 会导致索引膨胀 。例如把 request_id 当作 label，1 万 QPS × 100 标签值 = 100 万/秒 cardinality，索引很快爆掉。

正确做法：request_id 放在日志内容中（通过 line filter 查询），不作为 label。

6.3 实践 3：vmui 部署为统一入口

vmui 是 VictoriaMetrics 自带的 Web UI，1.146.0 版本起支持 Metrics+Logs 双面板。部署方式：

bash 复制代码

# 单节点部署
docker run -d --name vmui \
  -p 8429:8429 \
  victoriametrics/vmui:latest

# 访问 http://localhost:8429
# 在 settings 里配置 VM 和 VL 的地址
# - VM URL: http://victoriametrics:8428
# - VL URL: http://victorialogs:9428

6.4 实践 4：Grafana 数据源配置

在 Grafana 中添加两个数据源：

VictoriaMetrics 数据源 ：类型 Prometheus，URL 填 http://victoriametrics:8428
VictoriaLogs 数据源 ：类型 Loki，URL 填 http://victorialogs:9428

然后用 变量联动 + Data Links 实现面板级联合查询。

6.5 实践 5：容量规划与成本控制

日志量	VM 节点数	VL 节点数	存储	预估成本
1GB/天	1 (4C8G)	1 (4C8G)	1TB SSD	$50/月
10GB/天	1 (8C16G)	1 (8C16G)	5TB SSD	$200/月
100GB/天	3 (Cluster)	3 (HA)	50TB SSD	$1500/月
1TB/天	5+ (Cluster)	5+ (HA)	500TB SSD	$10000+/月

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

Metrics+Logs 一体化部署的 5 个关键：① vmagent 统一采集；② label 命名空间统一；③ vmui 统一入口；④ Grafana 双数据源联动；⑤ 容量规划与成本控制。核心思想是复用基础设施、统一 label 规范、联合查询工作流，避免重复建设和数据孤岛。

七、FAQ 问答模块

思考记忆提示 --- FAQ 是全篇的"临考前速背"模块，把 Metrics+Logs 协同的关键点浓缩成 20 个高频问题

Q1-Q5 围绕产品定位：三支柱、Metrics+Logs 双产品、LogQL 兼容
Q6-Q10 围绕查询语言：LogQL 语法、扩展函数、解析能力
Q11-Q15 围绕数据接入：vmagent、Promtail、syslog、协议
Q16-Q20 围绕实战：vmui、Grafana、性能对比、部署

Q1. Metrics 和 Logs 各自解决什么问题？

**Metrics 解决"什么坏了"（聚合数值），Logs 解决"为什么坏了"（详细上下文），Traces 解决"哪里坏了"（调用链）。**三者协同构成完整可观测性体系。

Q2. VictoriaLogs 和 VictoriaMetrics 是什么关系？

**VictoriaLogs 是 VictoriaMetrics 公司的日志产品，与 VM 共享核心库（lib/storage、lib/mergeset）。**VM 处理 metrics，VL 处理 logs，两者通过相同 label 联合查询。

Q3. LogQL 是什么？

**LogQL 是日志查询语言，最初由 Grafana Loki 定义，VictoriaLogs 完全兼容并扩展了 14 个独有函数。**LogQL 由过滤表达式（label filter + line filter）和管道聚合（统计函数）组成。

Q4. VictoriaLogs 的 LogQL 和 Loki 的 LogQL 有什么区别？

**VictoriaLogs 完全兼容 Loki 标准 LogQL，并扩展了 stats/partition/sort/fields/values 等 14 个独有函数。**VL 的 LogQL 拥有接近 PromQL 的表达力，能做半结构化数据分析。

Q5. Metrics+Logs 协同的核心价值是什么？

**从 metrics 异常一键跳转到 logs 上下文，实现"看 metric 找问题、看 log 找原因"的工作流。**vmui 双面板布局和 Grafana 变量联动是两种典型实现。

Q6. LogQL 的过滤表达式怎么写？

用 {app="order", level="error"} |= "timeout" != "healthcheck" 的格式。 花括号是 label filter，|= 是 line filter（包含），!= 是 line filter（排除）。

Q7. LogQL 的管道聚合有哪些常用函数？

**rate、count_over_time、sum by、stats、partition、sort、limit 等。**所有 PromQL 的聚合函数在 LogQL 中都能用，只是参数从数值变成了日志流。

Q8. VictoriaLogs 的 stats 函数能做什么？

stats 函数类似 SQL 的聚合，支持 uniq/count/sum/avg/max/min 等统计。 例如 stats count() as total, unq(app) as apps 可以统计日志条数和不同 app 数量。

Q9. 如何在 LogQL 中提取 JSON 字段？

用 | unpack 函数或 | fields 函数。 unpack 把 JSON 字符串解析为可查询的字段，fields 提取指定字段用于后续过滤。

Q10. LogQL 能做数学运算吗？

能，用管道运算符。 例如 {app="api"} | stats avg(latency) as avg_lat | eval avg_lat / 1000 把毫秒转换为秒。

Q11. VictoriaLogs 支持哪些数据接入方式？

**5 种主流方式：vmagent 推送、Promtail 推送、Fluent Bit/Filebeat、syslog 监听、HTTP POST。**其中 vmagent 推送是推荐方案，复用 Prometheus 生态。

Q12. 如何在 k8s 中部署 VictoriaLogs？

官方提供 Helm Chart 和 Operator 两种方式。 Helm Chart 简单直接（helm install vl vm/victoria-logs-single），Operator 适合集群模式。

Q13. vmagent 怎么推送日志到 VictoriaLogs？

配置 vmagent 的 -syslog.listenAddr=:1514，它会监听 syslog 并推送到 -remoteWrite.url=http://vl:9428/insert/syslog。 也可以走 Loki push API 路径 /insert/loki/api/v1/push。

Q14. VictoriaLogs 的写入协议是 Loki push API 吗？

**兼容 Loki push API，但推荐用 VL 的原生 JSON 协议（/insert/jsonline 或 /insert/jsonstream），性能更好。**JSON 协议支持批量写入和流式写入。

Q15. syslog 格式和 Loki 格式怎么选？

**应用直接 syslog 输出用 syslog 格式；已有 Promtail/Fluent Bit 等 agent 用 Loki push API 格式。**VL 同时支持两种格式，可灵活选择。

Q16. vmui 如何实现 Metrics+Logs 联合查询？

**vmui 提供左右双面板，左侧 Metrics 异常点点击后右侧 Logs 面板自动定位该时间点附近的相关日志。**1.146.0 版本起 vmui 原生支持该功能。

Q17. 在 Grafana 中如何配置 VictoriaLogs 数据源？

**在 Grafana 中添加 Loki 类型数据源，URL 填 http://victorialogs:9428。**VL 实现了 Loki 的 HTTP API，Grafana 无需任何插件即可查询。

Q18. VictoriaLogs vs Loki 的性能差异如何？

**VL 写入比 Loki 高 3-5 倍、查询低 5-10 倍、压缩高 2-3 倍、资源占用只有 1/3。**根源是 VL 用本地 SSD + MergeSet，Loki 用对象存储 + BoltDB 索引。

Q19. VictoriaLogs 适合什么规模？

**中小规模（< 10TB/天）的最佳选择。**VL 缺乏 Loki 的 Cortex 多租户模式、对象存储冷数据归档，更适合追求性能 + 运维简单的场景。

Q20. VictoriaLogs 数据怎么备份？

**类似 VM，用 vmbackup/vmrestore 工具备份本地数据目录。**VL 的数据存储格式与 VM 兼容（同样基于 MergeSet），备份工具可复用。
全篇必记总纲

VictoriaLogs 与 VictoriaMetrics 组成"Metrics+Logs"双产品矩阵，共享核心库（MergeSet、6 种压缩算法、inmemoryPart 1 秒刷盘） 。LogQL 完全兼容 Grafana Loki 标准，扩展了 14 个独有函数让日志查询拥有类 PromQL 表达力。Metrics+Logs 协同的核心是统一 label + 联合查询工作流：从 metrics 异常一键跳转到 logs 上下文，vmui 双面板和 Grafana 变量联动是两种典型实现。

八、Roadmap：后续预告

本篇覆盖了 VictoriaLogs 与 VictoriaMetrics 的协同架构，后续将深入各个专题：

#14 Enterprise vs OpenSource：关键功能差异------版本选择指南
#15 发布节奏与版本策略：LTS 选择与升级路线
#91 Grafana 集成：Prometheus 数据源 + VMUI + Explore
#183 vmui 日志探索器：联合查询 Metrics 和 Logs
#185 从 Metrics 到 Logs：一体化可观测性最佳实践

本文参考与源码链接：

• VictoriaLogs 官方文档

• Grafana Loki LogQL 文档

• VictoriaLogs vs Loki 性能对比

• VictoriaLogs 源码

• LogQL 扩展函数参考

VictoriaMetrics 架构设计篇【左扬精讲】· VictoriaLogs 协同：Metrics 到 Logs 的一体化监控 · 来源：VictoriaMetrics v1.146.0 深度分析

VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— VictoriaLogs 协同：Metrics 到 Logs 的一体化监控

VictoriaMetrics 1.146.0 源码专题【左扬精讲】------ VictoriaLogs 协同：Metrics 到 Logs 的一体化监控

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

1.1 VM 家族的"Metrics+Logs"双产品战略

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

2.1 LogQL 基础语法

2.2 VictoriaLogs 对 LogQL 的扩展

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

3.1 5 种主流接入方式

3.2 推荐方案：vmagent + k8s DaemonSet

四、Metrics+Logs 联合查询：vmui 实战

4.1 vmui 的双面板布局

4.2 Grafana 联合查询方案

五、VictoriaLogs vs Grafana Loki：架构差异

5.1 核心差异对比

5.2 性能基准对比

六、生产部署最佳实践

6.1 实践 1：vmagent 统一采集，Metrics 和 Logs 复用

6.2 实践 2：label 命名空间统一规划

6.3 实践 3：vmui 部署为统一入口

6.4 实践 4：Grafana 数据源配置

6.5 实践 5：容量规划与成本控制

七、FAQ 问答模块

Q1. Metrics 和 Logs 各自解决什么问题？

Q2. VictoriaLogs 和 VictoriaMetrics 是什么关系？

Q3. LogQL 是什么？

Q4. VictoriaLogs 的 LogQL 和 Loki 的 LogQL 有什么区别？

Q5. Metrics+Logs 协同的核心价值是什么？

Q6. LogQL 的过滤表达式怎么写？

Q7. LogQL 的管道聚合有哪些常用函数？

Q8. VictoriaLogs 的 stats 函数能做什么？

Q9. 如何在 LogQL 中提取 JSON 字段？

Q10. LogQL 能做数学运算吗？

Q11. VictoriaLogs 支持哪些数据接入方式？

Q12. 如何在 k8s 中部署 VictoriaLogs？

Q13. vmagent 怎么推送日志到 VictoriaLogs？

Q14. VictoriaLogs 的写入协议是 Loki push API 吗？

Q15. syslog 格式和 Loki 格式怎么选？

Q16. vmui 如何实现 Metrics+Logs 联合查询？

Q17. 在 Grafana 中如何配置 VictoriaLogs 数据源？

Q18. VictoriaLogs vs Loki 的性能差异如何？

Q19. VictoriaLogs 适合什么规模？

Q20. VictoriaLogs 数据怎么备份？

八、Roadmap：后续预告