VictoriaMetrics 1.146.0 源码专题【左扬精讲】—— VictoriaLogs 协同：Metrics 到 Logs 的一体化监控
一、可观测性三支柱：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 查询由过滤表达式和管道聚合两部分组成：
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 种主流接入方式
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://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 推送日志时，有两种格式可选：
- 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联动：
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 中，可以通过变量联动实现类似的联合查询：
# 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 命名，方便联合查询：
# 推荐的统一 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 双面板。部署方式：
# 单节点部署
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:94286.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 规范、联合查询工作流，避免重复建设和数据孤岛。
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
6
0- 0
已为社区贡献3条内容
所有评论(0)