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 详情
实战技巧：快速定位问题

Step 1：在 Explore 中用 Prometheus 查询发现异常的 P99 延迟突刺
Step 2：复制该时间点的 traceID
Step 3：切换到 Loki 数据源，查询 {trace_id=“xxx”}
Step 4：切换到 Jaeger 数据源，输入 traceID 查看完整调用链
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 页面使用

在 Jaeger UI 或 VictoriaTraces 中导出 trace 为 JSON
打开 vmui → Trace 页面（/#/trace）
拖拽或上传 JSON 文件查看链路详情
结合 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