当 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 告诉你"为什么坏了"
在云原生监控领域，Metrics（指标）、Logs（日志）、Traces（链路）是可观测性的三大支柱，每一种都回答不同的问题：
三大支柱不是孤立的，而是互补协同的。Metrics 发现异常 → 通过 traceID 跳转到 Traces 查看调用链 → 通过 requestID 跳转到 Logs 查看具体错误堆栈——这是现代可观测性平台的"金标准"工作流。
我理解源码的意思是说
可观测性三支柱就像医院的三大检查科室：
VictoriaMetrics 家族（VM + VictoriaLogs）的优势是"两个科室共用一套病历号"——同一个请求的 metric 和 log 用相同的 label 关联，无需额外配置就能在 vmui 里联合查询。
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 是 Loki 兼容 + VM 扩展
LogQL（Loki 查询语言）最初由 Grafana Loki 定义。VictoriaLogs 在保持兼容的基础上做了大幅扩展，让 LogQL 拥有接近 PromQL 的表达力。
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 聚合的速率"。
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 几乎可以零成本学习：
必记闭环逻辑（核心考点）
LogQL 是 VictoriaLogs 的查询语言，完全兼容 Grafana Loki 的标准 LogQL，并扩展了 14 个独有函数（stats/partition/sort/fields 等）。LogQL 的核心是过滤表达式（label filter + line filter）+ 管道聚合（统计函数 + 解析函数）。对熟悉 PromQL 的用户几乎零学习成本。
思考记忆提示 — 日志接入有两种方式：vmagent 复用 + Promtail 专用
VictoriaLogs 支持多种数据接入方式，覆盖了云原生环境的几乎所有日志源。
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
适用: 应用直接写入、调试场景在 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://victorialogs:9428/insert/loki/api/v1/push
# VictoriaLogs 兼容 Loki push API
# 启动 vmagent 时加上 syslog 监听
# vmagent -syslog.listenAddr=:1514vmagent 会监听容器运行时（containerd/CRI-O）的日志目录 /var/log/containers/*.log，解析为 syslog 格式，附带 k8s metadata，然后推送到 VictoriaLogs。
避坑指南：syslog 格式 vs Loki 格式
vmagent 推送日志时，有两种格式可选：
推荐 Loki push API 格式，因为它支持 JSON 嵌套字段，更适合现代结构化日志。
必记闭环逻辑（核心考点）
VictoriaLogs 支持 5 种主流数据接入方式，vmagent DaemonSet 是 k8s 环境推荐方案。vmagent 复用 Prometheus 抓取配置，通过 syslog 监听或 Loki push API 推送到 VictoriaLogs。整个接入链路无需额外学习成本（对熟悉 PromQL/Promtail 的用户）。
思考记忆提示 — 联合查询是"看 metric → 跳 log"的工作流核心
Metrics+Logs 协同的最高价值是"从异常指标一键跳转到关联日志"。vmui（VictoriaMetrics 自带的 Web UI）原生支持这种工作流。
vmui 提供左右双面板布局，左侧是 Metrics 查询，右侧是 Logs 查询，两者通过共享 label联动：
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 面板自动定位到该时间点附近的相关日志。这是真正的"指标驱动日志"工作流。
在 Grafana 中，可以通过变量联动实现类似的联合查询：
# 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 关联：
这是"Metrics→Traces→Logs"完整工作流的实现方式。
必记闭环逻辑（核心考点）
vmui 双面板布局是"看 metric → 跳 log"的核心工作流，左侧 Metrics 异常点可一键跳转到右侧 Logs 面板。Grafana 通过变量联动和数据源 Data Links实现类似功能。高级场景通过 traceID 串联，实现 Metrics→Traces→Logs 的完整可观测性链路。
思考记忆提示 — 两者查询语法兼容，但架构哲学截然不同
VictoriaLogs 和 Grafana Loki 都属于"日志领域的 Prometheus 替代品"，但两者的架构哲学差异巨大。
| 对比维度 | 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/天） |
根据 VictoriaMetrics 官方博客（VictoriaLogs vs Loki）的基准测试：
这些性能差异的根源是存储引擎的选择——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 个关键点
最后给出生产部署的 5 个关键最佳实践，确保 Metrics+Logs 一体化监控稳定运行。
不要为 Metrics 和 Logs 分别部署采集 agent。vmagent 同时支持：
统一用 vmagent DaemonSet，简化运维。
Metrics 和 Logs 应该使用相同的核心 label 命名，方便联合查询：
# 推荐的统一 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。
vmui 是 VictoriaMetrics 自带的 Web UI，1.146.0 版本起支持 Metrics+Logs 双面板。部署方式：
# 单节点部署
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在 Grafana 中添加两个数据源：
然后用 变量联动 + Data Links 实现面板级联合查询。
| 日志量 | 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 是全篇的"临考前速背"模块，把 Metrics+Logs 协同的关键点浓缩成 20 个高频问题
Metrics 解决"什么坏了"（聚合数值），Logs 解决"为什么坏了"（详细上下文），Traces 解决"哪里坏了"（调用链）。三者协同构成完整可观测性体系。
VictoriaLogs 是 VictoriaMetrics 公司的日志产品，与 VM 共享核心库（lib/storage、lib/mergeset）。VM 处理 metrics，VL 处理 logs，两者通过相同 label 联合查询。
LogQL 是日志查询语言，最初由 Grafana Loki 定义，VictoriaLogs 完全兼容并扩展了 14 个独有函数。LogQL 由过滤表达式（label filter + line filter）和管道聚合（统计函数）组成。
VictoriaLogs 完全兼容 Loki 标准 LogQL，并扩展了 stats/partition/sort/fields/values 等 14 个独有函数。VL 的 LogQL 拥有接近 PromQL 的表达力，能做半结构化数据分析。
从 metrics 异常一键跳转到 logs 上下文，实现"看 metric 找问题、看 log 找原因"的工作流。vmui 双面板布局和 Grafana 变量联动是两种典型实现。
用 {app="order", level="error"} |= "timeout" != "healthcheck" 的格式。花括号是 label filter，|= 是 line filter（包含），!= 是 line filter（排除）。
rate、count_over_time、sum by、stats、partition、sort、limit 等。所有 PromQL 的聚合函数在 LogQL 中都能用，只是参数从数值变成了日志流。
stats 函数类似 SQL 的聚合，支持 uniq/count/sum/avg/max/min 等统计。例如 stats count() as total, unq(app) as apps 可以统计日志条数和不同 app 数量。
用 | unpack 函数或 | fields 函数。unpack 把 JSON 字符串解析为可查询的字段，fields 提取指定字段用于后续过滤。
能，用管道运算符。例如 {app="api"} | stats avg(latency) as avg_lat | eval avg_lat / 1000 把毫秒转换为秒。
5 种主流方式：vmagent 推送、Promtail 推送、Fluent Bit/Filebeat、syslog 监听、HTTP POST。其中 vmagent 推送是推荐方案，复用 Prometheus 生态。
官方提供 Helm Chart 和 Operator 两种方式。Helm Chart 简单直接（helm install vl vm/victoria-logs-single），Operator 适合集群模式。
配置 vmagent 的 -syslog.listenAddr=:1514，它会监听 syslog 并推送到 -remoteWrite.url=http://vl:9428/insert/syslog。也可以走 Loki push API 路径 /insert/loki/api/v1/push。
兼容 Loki push API，但推荐用 VL 的原生 JSON 协议（/insert/jsonline 或 /insert/jsonstream），性能更好。JSON 协议支持批量写入和流式写入。
应用直接 syslog 输出用 syslog 格式；已有 Promtail/Fluent Bit 等 agent 用 Loki push API 格式。VL 同时支持两种格式，可灵活选择。
vmui 提供左右双面板，左侧 Metrics 异常点点击后右侧 Logs 面板自动定位该时间点附近的相关日志。1.146.0 版本起 vmui 原生支持该功能。
在 Grafana 中添加 Loki 类型数据源，URL 填 http://victorialogs:9428。VL 实现了 Loki 的 HTTP API，Grafana 无需任何插件即可查询。
VL 写入比 Loki 高 3-5 倍、查询低 5-10 倍、压缩高 2-3 倍、资源占用只有 1/3。根源是 VL 用本地 SSD + MergeSet，Loki 用对象存储 + BoltDB 索引。
中小规模（< 10TB/天）的最佳选择。VL 缺乏 Loki 的 Cortex 多租户模式、对象存储冷数据归档，更适合追求性能 + 运维简单的场景。
类似 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 变量联动是两种典型实现。
本篇覆盖了 VictoriaLogs 与 VictoriaMetrics 的协同架构，后续将深入各个专题：
本文参考与源码链接：
• VictoriaLogs 官方文档
• Grafana Loki LogQL 文档
• VictoriaLogs vs Loki 性能对比
• VictoriaLogs 源码
• LogQL 扩展函数参考
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。