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 组合使用

  1. vmui：快速发现指标异常、查看告警、探索 Metrics 命名
  2. Grafana：复杂 Dashboard、变量联动、Data Links 跳转
  3. 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

数据源配置步骤

  1. 登录 Grafana → Configuration → Data Sources
  2. 点击 "Add data source"
  3. 搜索 "Prometheus"，填写 VictoriaMetrics URL，保存
  4. 搜索 "Loki"，填写 VictoriaLogs URL，保存
  5. 搜索 "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=~\"$app\"}[5m]))",
          "legendFormat": "{{status}}"
        }
      ],
      # Data Link：从指标跳转到 Traces
      "links": [
        {
          "title": "查看链路",
          "url": "http://grafana:3000/explore?left=%5B%22${__from:date:iso}%22,%22${__to:date:iso}%22,%22VictoriaTraces%22,%7B%22query%22:%22${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="$app"}
│   ├── Logs 面板:   {app="$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\"${__from:date:iso}\",\"${__to:date:iso}\",\"VictoriaTraces\",%7B%22query%22:%22${trace_id}%22%7D%5D"
}

5.5 Grafana Explore 联合查询

Grafana Explore 是快速调试和临时查询的最佳工具：

Grafana Explore 工作流
│
├── 【打开 Explore】
│   └── 左侧菜单 → Explore（或按 E 键）
│
├── 【切换数据源】
│   └── 顶部下拉框选择：Prometheus / Loki / Jaeger
│
├── 【Metrics 查询】
│   └── PromQL: rate(http_requests_total[5m])
│   └── 切换到 Table/Graph 视图
│
├── 【Logs 查询】
│   └── LogQL: {app="$app"} |= "error"
│   └── 切换到 Logs 视图，展开行查看详情
│
└── 【Traces 查询】
    └── Trace ID 搜索，或按服务名/操作名筛选
    └── 点击 Trace ID 展开 span 详情

实战技巧：快速定位问题

  1. Step 1：在 Explore 中用 Prometheus 查询发现异常的 P99 延迟突刺
  2. Step 2：复制该时间点的 traceID
  3. Step 3：切换到 Loki 数据源，查询 {trace_id="xxx"}
  4. Step 4：切换到 Jaeger 数据源，输入 traceID 查看完整调用链
  5. Step 5：综合三方面信息定位根因

5.6 Annotations 注解联动

Grafana Annotations 可以在 Metrics 时间线上标注关键事件：

# 配置从 Logs 创建 Annotations
{
  "name": "Error Logs",
  "datasource": "VictoriaLogs",
  "target": {
    "expr": "{level=\"error\"}",
    "tagKeys": "app,level",
    "textFormat": "{{app}}: {{line}}"
  }
}

# 当 Metrics 图表上标注了错误日志位置时
# 可以直接点击标注跳转到对应的日志条目

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

Grafana 是 VM 家族三产品联合查询的最佳入口。配置三个数据源（Prometheus/Loki/Jaeger），通过变量联动实现多面板同时筛选，通过Data Links实现跨数据源跳转。工作流：Metrics 发现异常 → 点击 traceID 跳转 Traces → 查询 Logs 查详情，三者通过统一 label 关联。

六、VictoriaLogs vs Grafana Loki：架构差异

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

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

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

7.1 VictoriaTraces 架构

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

5.2 性能基准对比

根据 VictoriaLogs 官方博客（VictoriaLogs vs Loki）的基准测试（具体性能数据请参考官方博客原文），VictoriaLogs 和 Loki 在存储引擎上存在架构差异：Loki 依赖对象存储做冷数据存储，VictoriaLogs 用本地 SSD 跑 MergeSet 引擎。性能对比数字请以官方博客最新发布为准。

  • 存储架构：VictoriaLogs 单二进制 + 本地 SSD，Loki 多组件 + 对象存储
  • 核心差异：存储引擎选择不同导致适用场景不同

这些差异的根源是存储引擎的选择——Loki 依赖对象存储做冷数据存储，天生受限于 S3/GCS 的 IO 延迟；VictoriaLogs 用本地 SSD 跑 MergeSet 引擎。两者各有适用场景，详见官方博客完整对比。

设计精髓

VictoriaLogs 的架构哲学是"以 VM 的成功经验复制到日志领域"。VM 的核心优势是 MergeSet 引擎 + 本地 SSD + 单二进制部署，VL 完全复用这套设计。两者在存储引擎上的差异是：VL 用 MergeSet + 本地 SSD（单二进制、无外部依赖），Loki 用分片 + 对象存储 + BoltDB 索引（需要 MinIO/Cassandra 多组件）。

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

VictoriaLogs vs Loki 的核心差异是存储引擎：VL 用 MergeSet + 本地 SSD（单二进制、无外部依赖），Loki 用分片 + 对象存储 + BoltDB 索引（需要 MinIO/Cassandra 多组件）。

七、VictoriaTraces：链路追踪新选择

思考记忆提示 — VictoriaTraces 是 VM 家族的链路追踪产品

  • 关联产品：VictoriaMetrics（Metrics）、VictoriaLogs（Logs）、VictoriaTraces（Traces）
  • 关联工具：OTLP、Jaeger、Grafana Tempo
  • 核心特点：与 VM/VL 共用部分核心库，单二进制部署

VictoriaTraces 是 VictoriaMetrics 公司推出的链路追踪产品，与 VictoriaMetrics、VictoriaLogs 共同构成完整的可观测性三支柱解决方案。

7.1 VictoriaTraces 架构

VictoriaTraces 采用与 VictoriaMetrics 相似的架构哲学：

  • 单二进制部署：所有功能集成在一个可执行文件中
  • 本地 SSD 优先：数据存储在本地高速磁盘
  • MergeSet 存储引擎：复用 VM 核心库的存储逻辑
  • 无外部依赖：不像 Jaeger 需要 Cassandra/Elasticsearch

7.2 OTLP 协议支持

VictoriaTraces 支持 OTLP（OpenTelemetry Protocol），可接收来自任何 OTLP 兼容 SDK 的链路数据：

# 启动 VictoriaTraces（默认监听 :10428）
victoria-traces

# 或指定端口
victoria-traces -httpListenAddr=:8428

# 查看帮助
victoria-traces -help

7.3 与 Jaeger/Grafana Tempo 的对比

对比维度 VictoriaTraces Jaeger Grafana Tempo
存储引擎 MergeSet（本地 SSD） BoltDB/Cassandra/Elasticsearch 对象存储 + 块索引
部署复杂度 单二进制 多组件 单二进制（需对象存储）
外部依赖 无 Cassandra/ES（生产） S3/GCS/Azure Blob
OTLP 支持 是 是 是
Jaeger API 兼容 是 原生 部分
运维成本 低 高 中

7.4 vmui 中的 Trace 功能

vmui 提供了 Trace 页面（/#/trace），支持：

  • JSON 文件导入：导入 Jaeger/VictoriaTraces 导出的 JSON trace 文件
  • 链路可视化：查看 span 层级结构
  • 自定义面板集成：在 CustomPanel 中展示 Traces

实战技巧：vmui Trace 页面使用

  1. 在 Jaeger UI 或 VictoriaTraces 中导出 trace 为 JSON
  2. 打开 vmui → Trace 页面（/#/trace）
  3. 拖拽或上传 JSON 文件查看链路详情
  4. 结合 Metrics Dashboard 分析性能问题

设计精髓

VictoriaTraces 延续了 VictoriaMetrics 家族的"简单、可靠、高性能"理念。与 Jaeger 需要复杂的 Cassandra 集群相比，VictoriaTraces 用单二进制就能处理中等规模的链路追踪需求。vmui 的 Trace 页面让用户无需离开 VM 生态即可查看链路数据。

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

VictoriaTraces 是 VM 家族的链路追踪产品，单二进制 + MergeSet + 本地 SSD，无外部依赖。支持 OTLP 协议，兼容 Jaeger API。vmui 中通过 /#/trace 页面导入 JSON 查看链路，配合 Metrics Dashboard 实现可观测性闭环。

八、生产部署最佳实践

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

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

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

6.1 实践 1：vmagent 统一采集

vmagent 可同时采集 Metrics、Logs 和 Traces：

  • Metrics：通过 scrape_configs 抓取
  • Logs：通过 -syslog.listenAddr=:1514 监听
  • Traces：通过 OTLP 接收（需要 vmagent 支持）

统一用 vmagent，简化运维。

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

三数据源应使用相同的核心 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: 节点名

# 链路标识（Traces + Logs 共享）
- trace_id: 链路 ID
- request_id: 请求 ID（可选，高 cardinality）

6.3 实践 3：Grafana 三数据源配置

在 Grafana 中添加三个数据源：

  • VictoriaMetrics：类型 Prometheus，URL: http://victoriametrics:8428
  • VictoriaLogs：类型 Loki，URL: http://victoria-logs:9428
  • VictoriaTraces：类型 Tempo 或 Jaeger，URL: http://victoria-traces:9417

6.4 实践 4：容量规划

规模 VM VL VT 存储
小规模 1 节点 1 节点 1 节点 1TB SSD
中规模 3 节点 3 节点 3 节点 10TB SSD
大规模 Cluster HA 部署 集群模式 100TB+ SSD

6.5 实践 5：vmui 统一入口

vmui 提供统一的 Web 界面：

  • /#/explore：ExploreMetrics，指标发现
  • /#/trace：TracePage，链路查看
  • /#/custom-panel：自定义 Dashboard
  • /#/alert：告警规则管理

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

VM 家族三产品一体化部署的 5 个关键：① vmagent 统一采集；② label 命名空间统一；③ Grafana 三数据源配置；④ 容量规划；⑤ vmui 统一入口。核心思想是复用基础设施、统一 label 规范、Grafana 联合查询。

- namespace: k8s 命名空间 - pod: Pod 名 - container: 容器名 - node: 节点名 # 不要在 Logs 中使用高频变化 label（如 request_id、user_id）

6.3 实践 3：vmui 统一入口

vmui 是 VictoriaMetrics 自带的 Web UI，通过 URL 路径访问不同功能：

  • /#/explore：ExploreMetrics，指标发现
  • /#/trace：TracePage，链路查看
  • /#/custom-panel：自定义 Dashboard
  • /#/alert：告警规则管理

6.4 实践 4：Grafana 三数据源配置

在 Grafana 中添加三个数据源：

  • VictoriaMetrics：类型 Prometheus，URL: http://victoriametrics:8428
  • VictoriaLogs：类型 Loki，URL: http://victoria-logs:9428
  • VictoriaTraces：类型 Tempo 或 Jaeger，URL: http://victoria-traces:9417

6.5 实践 5：容量规划

规模 VM VL VT 存储
小规模 1 节点 1 节点 1 节点 1TB SSD
中规模 3 节点 3 节点 3 节点 10TB SSD
大规模 Cluster HA 部署 集群模式 100TB+ SSD
# oracle # 数据库
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

3分钟掌握Codex技能安装：一键部署你的AI助手工具库

想要为你的Codex AI助手安装新技能？不用再手动复制文件了！skill-installer为你提供了一套完整的解决方案，让你能够从GitHub仓库快速获取和安装各种实用的Codex技能。无论你是AI开发新手还是经验丰富的开发者，这个工具都能让你在几分钟内扩展Codex的功能边界。## 为什么选择skill-installer？ 🤔在AI辅助编程的时代，Codex技能已经成为提升开发效

avatar AI编程社区

DB-GPT分布式AI数据引擎：企业级智能分析平台架构解析

DB-GPT作为新一代AI数据助手，通过分布式架构和智能代理引擎重构了传统数据分析范式。该平台将大型语言模型的自然语言理解能力与企业级数据处理需求深度融合，构建了面向生产环境的可扩展AI数据平台。其核心价值在于将复杂的SQL生成、数据分析和可视化任务转化为简单的自然语言交互，同时确保系统安全性、可追溯性和企业级可靠性。## 技术定位与生态分析在当前数据智能生态中，DB-GPT填补了传统BI

avatar AI编程社区

如何用Awesome Claude Skills将AI助手打造成你的全能创作伙伴和职业顾问

你是否曾想过，如果有一个AI伙伴能帮你完成从专业文章撰写到完美简历定制的所有工作，工作效率会提升多少倍？Awesome Claude Skills正是这样一个神奇的AI技能宝库，它汇集了1000+个精心筛选的Claude技能，覆盖内容创作、职业发展、文档处理等各个方面，让你在AI的帮助下轻松应对各种工作挑战。## 痛点分析：传统工作流程的三大瓶颈在内容创作和职业发展中，我们常常面临这样的困

avatar AI编程社区