一个完整的三数据源 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 多组件）。