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