VictoriaMetrics VictoriaLogs VictoriaTraces MetricsQL LogQL 一体化监控 vmui Grafana Promtail 可观测性 OTLP学习重点必须掌握MetricsLogsTraces 三支柱协同架构、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处理 metricsPrometheus 兼容VictoriaLogs处理 logsLogQLLoki 兼容VictoriaTraces处理 traces支持 OTLP 协议兼容 Jaeger/Tempo API三者的优势是统一的 label 关联机制——同一个请求的 metric、log、trace 用相同的 label 标识无需额外配置就能在 vmui 里联合查询。1.1 VM 家族的三产品战略MetricsLogs TracesVictoriaMetrics 公司推出了 VictoriaMetrics、VictoriaLogs、VictoriaTraces 三款产品覆盖可观测性三支柱。三者共享相似的架构哲学单二进制部署、MergeSet 存储引擎、本地 SSD 优先。设计精髓VictoriaMetrics 和 VictoriaLogs 共用部分核心库包括 storage、encoding、mergeset、fs 等。VictoriaLogs 在 MergeSet 引擎上构建 LogQL 查询实现与 VictoriaMetrics 的协同。具体复用程度请参考 VictoriaLogs 源码github.com/VictoriaMetrics/VictoriaLogs。对比维度VictoriaMetricsVictoriaLogs数据类型数值型float64/int64文本型任意 UTF-8 字符串查询语言MetricsQLPromQL 扩展LogQLGrafana Loki 兼容 VM 扩展核心库lib/storage, lib/mergesetvlstorage基于 lib/mergeset压缩策略NearestDelta 等 6 种数值算法字典压缩 增量编码索引结构indexDB8 种 nsPrefix类似 indexDB针对 log labels写入协议Prometheus remote_writeJSON / Loki push API / syslog查询协议Prometheus HTTP APILogsQL HTTP API / Grafana Loki API必记闭环逻辑核心考点可观测性三支柱Metrics/Logs/Traces解决不同问题协同工作流是Metrics 发现异常 → Traces 看调用链 → Logs 看错误堆栈。VictoriaMetrics 公司的产品矩阵覆盖全部三支柱VictoriaMetrics 处理 metricsVictoriaLogs 处理 logsVictoriaTraces 处理 traces三者均为独立开源产品。Metrics 和 Logs 在 vmui 中实现联合查询。二、LogQL 与 MetricsQL 的统一设计哲学思考记忆提示— LogQL 是 Loki 兼容 VM 扩展关联前面章节#56 PromQL 执行引擎、#57 MetricsQL vs PromQL关联工具Grafana 数据源配置、vmui 查询构建器面试/考试高频提问VictoriaLogs 的 LogQL 和 Grafana Loki 的 LogQL 有什么区别LogQLLoki 查询语言最初由 Grafana Loki 定义。VictoriaLogs 在保持兼容的基础上做了大幅扩展让 LogQL 拥有接近 PromQL 的表达力。2.1 LogQL 基础语法LogQL 查询由过滤表达式和管道聚合两部分组成LogQL 查询语法 │ ├── 【过滤表达式】筛选日志条目 │ ├── label filter: {apporder-service, levelerror} │ ├── line filter: timeout或database.*error │ └── 组合: {apporder} | error ! healthcheck │ └── 【管道聚合】对结果做统计 ├── 数值函数: | rate(), count_over_time() ├── 聚合函数: | sum by (app) (rate(...)) ├── 解析函数: | unpack, regexp, line_format └── 数学运算: | / 1000, 1, * 0.5一个完整示例sum by (app) (rate({apporder-service, levelerror}[5m]))意思是过去 5 分钟内、订单服务、错误日志、按 app 聚合的速率。2.2 VictoriaLogs 对 LogQL 的扩展VictoriaLogs 在兼容标准 LogQL 基础上新增了多个扩展函数让 LogQL 拥有类似 PromQL 的能力。具体函数列表和数量请参考 VictoriaLogs 官方文档docs.victoriametrics.com/victoria-logs/querying/。扩展函数功能类比 PromQLstats统计函数uniq/count/sum/avg/max/mincount、sumpartition分组聚合by (...)sort排序topk/bottomklimit限制返回数量无直接对应offset分页偏移无直接对应fields提取字段label_replacefield_names列出所有字段无直接对应values提取字段值无直接对应row行操作无直接对应copy复制字段无直接对应rename重命名字段label_replacedelete删除字段无直接对应pack打包字段为 JSON无直接对应unpack解包 JSON无直接对应这些扩展让 VictoriaLogs 摆脱了只能做日志查询的局限可以处理半结构化数据如 JSON 日志完成类似 SQL 的复杂分析。实战技巧从 PromQL 用户过渡到 LogQL如果你熟悉 PromQLLogQL 几乎可以零成本学习PromQL 的 {labelvalue} 选择器 LogQL 的 {labelvalue} 选择器语法完全一致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 中的容器日志采集到 VictoriaLogsVictoriaLogs 支持多种数据接入方式覆盖了云原生环境的几乎所有日志源。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: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/pushJSON 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 告警跳转到对应的日志和链路MetricsLogsTraces 协同的最高价值是从异常指标一键跳转到关联日志和链路。在 v1.146.0 版本中vmui 提供独立的 Metrics 页面ExploreMetrics和 Trace 页面TracePage而三数据源联合查询主要通过 Grafana 实现。4.1 vmui 的实际页面结构vmui 包含以下核心页面通过 URL 路径访问/#/exploreExploreMetrics指标发现和快速查询/#/traceTracePageJSON 文件导入查看链路/#/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?schemalokiqueries... title: 查看相关日志 params: expr: {app${__field.labels.app}, levelerror} # 2. 日志面板VictoriaLogs 数据源通过 Loki 兼容 - title: 错误日志 datasource: loki # 配置为 VictoriaLogs targets: - expr: {app~$app, levelerror} | 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_idxxx} │ └── 获取该请求的完整错误堆栈 │ └── 【核心】统一 label 关联 └── 同一请求共享: app, trace_id, request_id └── 三数据源无缝跳转实战技巧vmui Grafana 组合使用vmui快速发现指标异常、查看告警、探索 Metrics 命名Grafana复杂 Dashboard、变量联动、Data Links 跳转VictoriaLogs UI独立日志查询、LogQL 调试三者组合使用覆盖可观测性全场景。必记闭环逻辑核心考点vmui 在 v1.146.0 中没有内置 Logs 查询面板三数据源联合查询主要通过Grafana实现。核心机制是变量联动多个面板共用相同变量筛选和Data Links点击跳转到其他数据源。完整工作流是 Metrics 发现异常 → 跳转 Traces 定位慢调用 → 跳转 Logs 查错误堆栈通过 traceID 串联。五、Grafana 三数据源集成Metrics Logs Traces 联动思考记忆提示— Grafana 是 VM 家族三产品联合查询的最佳入口关联产品VictoriaMetricsPrometheus 数据源、VictoriaLogsLoki 数据源、VictoriaTracesJaeger/Tempo 数据源关联工具Grafana Explore、Grafana Data Links、Grafana Variables核心机制变量联动 Data Links 跨数据源跳转Grafana 是 VM 家族三产品联合查询的最佳入口。通过添加三个数据源、配置变量联动和 Data Links可以实现 Metrics → Traces → Logs 的完整可观测性工作流。5.1 Grafana 数据源配置在 Grafana 中添加三个数据源数据源名称Grafana 类型URL备注VictoriaMetricsPrometheushttp://victoriametrics:8428支持 Prometheus HTTP APIVictoriaLogsLokihttp://victoria-logs:9428VL 兼容 Loki HTTP APIVictoriaTracesJaeger 或 Tempohttp://victoria-traces:9417VT 兼容 Jaeger API数据源配置步骤登录 Grafana → Configuration → Data Sources点击 Add data source搜索 Prometheus填写 VictoriaMetrics URL保存搜索 Loki填写 VictoriaLogs URL保存搜索 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 详情实战技巧快速定位问题Step 1在 Explore 中用 Prometheus 查询发现异常的 P99 延迟突刺Step 2复制该时间点的 traceIDStep 3切换到 Loki 数据源查询 {trace_idxxx}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 架构对比维度VictoriaLogsGrafana Loki存储引擎自研 MergeSet基于 VM 核心库分片 对象存储S3/GCS BoltDB 索引数据存储位置本地 SSD单二进制无外部依赖S3/GCS/Azure Blob必须云存储索引存储本地文件类似 VM indexDBBoltDB单机/ Cortex 模式多租户部署复杂度单二进制开箱即用需要 MinIO Cassandra 多个组件查询性能本地 SSD 高速读取对象存储 IO 受限压缩比字典压缩 增量编码VL 官方称 10xGzip 块压缩约 3-5x运维成本低无外部依赖高需要管理 MinIO、Cassandra适用场景中小规模日志具体阈值参考 VL 官方文档大规模日志 多租户需求5.2 性能基准对比根据 VictoriaLogs 官方博客VictoriaLogs vs Loki的基准测试具体性能数据请参考官方博客原文VictoriaLogs 和 Loki 在存储引擎上存在架构差异Loki 依赖对象存储做冷数据存储VictoriaLogs 用本地 SSD 跑 MergeSet 引擎。性能对比数字请以官方博客最新发布为准。存储架构VictoriaLogs 单二进制 本地 SSDLoki 多组件 对象存储核心差异存储引擎选择不同导致适用场景不同这些差异的根源是存储引擎的选择——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 家族的链路追踪产品关联产品VictoriaMetricsMetrics、VictoriaLogsLogs、VictoriaTracesTraces关联工具OTLP、Jaeger、Grafana Tempo核心特点与 VM/VL 共用部分核心库单二进制部署VictoriaTraces 是 VictoriaMetrics 公司推出的链路追踪产品与 VictoriaMetrics、VictoriaLogs 共同构成完整的可观测性三支柱解决方案。7.1 VictoriaTraces 架构VictoriaTraces 采用与 VictoriaMetrics 相似的架构哲学单二进制部署所有功能集成在一个可执行文件中本地 SSD 优先数据存储在本地高速磁盘MergeSet 存储引擎复用 VM 核心库的存储逻辑无外部依赖不像 Jaeger 需要 Cassandra/Elasticsearch7.2 OTLP 协议支持VictoriaTraces 支持 OTLPOpenTelemetry Protocol可接收来自任何 OTLP 兼容 SDK 的链路数据# 启动 VictoriaTraces默认监听 :10428 victoria-traces # 或指定端口 victoria-traces -httpListenAddr:8428 # 查看帮助 victoria-traces -help7.3 与 Jaeger/Grafana Tempo 的对比对比维度VictoriaTracesJaegerGrafana Tempo存储引擎MergeSet本地 SSDBoltDB/Cassandra/Elasticsearch对象存储 块索引部署复杂度单二进制多组件单二进制需对象存储外部依赖无Cassandra/ES生产S3/GCS/Azure BlobOTLP 支持是是是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 个关键最佳实践确保 MetricsLogsTraces 一体化监控稳定运行。6.1 实践 1vmagent 统一采集vmagent 可同时采集 Metrics、Logs 和 TracesMetrics通过 scrape_configs 抓取Logs通过 -syslog.listenAddr:1514 监听Traces通过 OTLP 接收需要 vmagent 支持统一用 vmagent简化运维。6.2 实践 2label 命名空间统一规划三数据源应使用相同的核心 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可选高 cardinality6.3 实践 3Grafana 三数据源配置在 Grafana 中添加三个数据源VictoriaMetrics类型 PrometheusURL: http://victoriametrics:8428VictoriaLogs类型 LokiURL: http://victoria-logs:9428VictoriaTraces类型 Tempo 或 JaegerURL: http://victoria-traces:94176.4 实践 4容量规划规模VMVLVT存储小规模1 节点1 节点1 节点1TB SSD中规模3 节点3 节点3 节点10TB SSD大规模ClusterHA 部署集群模式100TB SSD6.5 实践 5vmui 统一入口vmui 提供统一的 Web 界面/#/exploreExploreMetrics指标发现/#/traceTracePage链路查看/#/custom-panel自定义 Dashboard/#/alert告警规则管理必记闭环逻辑核心考点VM 家族三产品一体化部署的 5 个关键① vmagent 统一采集② label 命名空间统一③ Grafana 三数据源配置④ 容量规划⑤ vmui 统一入口。核心思想是复用基础设施、统一 label 规范、Grafana 联合查询。- namespace: k8s 命名空间 - pod: Pod 名 - container: 容器名 - node: 节点名 # 不要在 Logs 中使用高频变化 label如 request_id、user_id6.3 实践 3vmui 统一入口vmui 是 VictoriaMetrics 自带的 Web UI通过 URL 路径访问不同功能/#/exploreExploreMetrics指标发现/#/traceTracePage链路查看/#/custom-panel自定义 Dashboard/#/alert告警规则管理6.4 实践 4Grafana 三数据源配置在 Grafana 中添加三个数据源VictoriaMetrics类型 PrometheusURL: http://victoriametrics:8428VictoriaLogs类型 LokiURL: http://victoria-logs:9428VictoriaTraces类型 Tempo 或 JaegerURL: http://victoria-traces:94176.5 实践 5容量规划规模VMVLVT存储小规模1 节点1 节点1 节点1TB SSD中规模3 节点3 节点3 节点10TB SSD大规模ClusterHA 部署集群模式100TB SSD
VictoriaMetrics VictoriaLogs VictoriaTraces MetricsQL LogQL 一体化监控 vmui Grafana Promtail 可观测性 OTLP学习重点必须掌握MetricsLogsTraces 三支柱协同架构、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处理 metricsPrometheus 兼容VictoriaLogs处理 logsLogQLLoki 兼容VictoriaTraces处理 traces支持 OTLP 协议兼容 Jaeger/Tempo API三者的优势是统一的 label 关联机制——同一个请求的 metric、log、trace 用相同的 label 标识无需额外配置就能在 vmui 里联合查询。1.1 VM 家族的三产品战略MetricsLogs TracesVictoriaMetrics 公司推出了 VictoriaMetrics、VictoriaLogs、VictoriaTraces 三款产品覆盖可观测性三支柱。三者共享相似的架构哲学单二进制部署、MergeSet 存储引擎、本地 SSD 优先。设计精髓VictoriaMetrics 和 VictoriaLogs 共用部分核心库包括 storage、encoding、mergeset、fs 等。VictoriaLogs 在 MergeSet 引擎上构建 LogQL 查询实现与 VictoriaMetrics 的协同。具体复用程度请参考 VictoriaLogs 源码github.com/VictoriaMetrics/VictoriaLogs。对比维度VictoriaMetricsVictoriaLogs数据类型数值型float64/int64文本型任意 UTF-8 字符串查询语言MetricsQLPromQL 扩展LogQLGrafana Loki 兼容 VM 扩展核心库lib/storage, lib/mergesetvlstorage基于 lib/mergeset压缩策略NearestDelta 等 6 种数值算法字典压缩 增量编码索引结构indexDB8 种 nsPrefix类似 indexDB针对 log labels写入协议Prometheus remote_writeJSON / Loki push API / syslog查询协议Prometheus HTTP APILogsQL HTTP API / Grafana Loki API必记闭环逻辑核心考点可观测性三支柱Metrics/Logs/Traces解决不同问题协同工作流是Metrics 发现异常 → Traces 看调用链 → Logs 看错误堆栈。VictoriaMetrics 公司的产品矩阵覆盖全部三支柱VictoriaMetrics 处理 metricsVictoriaLogs 处理 logsVictoriaTraces 处理 traces三者均为独立开源产品。Metrics 和 Logs 在 vmui 中实现联合查询。二、LogQL 与 MetricsQL 的统一设计哲学思考记忆提示— LogQL 是 Loki 兼容 VM 扩展关联前面章节#56 PromQL 执行引擎、#57 MetricsQL vs PromQL关联工具Grafana 数据源配置、vmui 查询构建器面试/考试高频提问VictoriaLogs 的 LogQL 和 Grafana Loki 的 LogQL 有什么区别LogQLLoki 查询语言最初由 Grafana Loki 定义。VictoriaLogs 在保持兼容的基础上做了大幅扩展让 LogQL 拥有接近 PromQL 的表达力。2.1 LogQL 基础语法LogQL 查询由过滤表达式和管道聚合两部分组成LogQL 查询语法 │ ├── 【过滤表达式】筛选日志条目 │ ├── label filter: {apporder-service, levelerror} │ ├── line filter: timeout或database.*error │ └── 组合: {apporder} | error ! healthcheck │ └── 【管道聚合】对结果做统计 ├── 数值函数: | rate(), count_over_time() ├── 聚合函数: | sum by (app) (rate(...)) ├── 解析函数: | unpack, regexp, line_format └── 数学运算: | / 1000, 1, * 0.5一个完整示例sum by (app) (rate({apporder-service, levelerror}[5m]))意思是过去 5 分钟内、订单服务、错误日志、按 app 聚合的速率。2.2 VictoriaLogs 对 LogQL 的扩展VictoriaLogs 在兼容标准 LogQL 基础上新增了多个扩展函数让 LogQL 拥有类似 PromQL 的能力。具体函数列表和数量请参考 VictoriaLogs 官方文档docs.victoriametrics.com/victoria-logs/querying/。扩展函数功能类比 PromQLstats统计函数uniq/count/sum/avg/max/mincount、sumpartition分组聚合by (...)sort排序topk/bottomklimit限制返回数量无直接对应offset分页偏移无直接对应fields提取字段label_replacefield_names列出所有字段无直接对应values提取字段值无直接对应row行操作无直接对应copy复制字段无直接对应rename重命名字段label_replacedelete删除字段无直接对应pack打包字段为 JSON无直接对应unpack解包 JSON无直接对应这些扩展让 VictoriaLogs 摆脱了只能做日志查询的局限可以处理半结构化数据如 JSON 日志完成类似 SQL 的复杂分析。实战技巧从 PromQL 用户过渡到 LogQL如果你熟悉 PromQLLogQL 几乎可以零成本学习PromQL 的 {labelvalue} 选择器 LogQL 的 {labelvalue} 选择器语法完全一致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 中的容器日志采集到 VictoriaLogsVictoriaLogs 支持多种数据接入方式覆盖了云原生环境的几乎所有日志源。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: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/pushJSON 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 告警跳转到对应的日志和链路MetricsLogsTraces 协同的最高价值是从异常指标一键跳转到关联日志和链路。在 v1.146.0 版本中vmui 提供独立的 Metrics 页面ExploreMetrics和 Trace 页面TracePage而三数据源联合查询主要通过 Grafana 实现。4.1 vmui 的实际页面结构vmui 包含以下核心页面通过 URL 路径访问/#/exploreExploreMetrics指标发现和快速查询/#/traceTracePageJSON 文件导入查看链路/#/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?schemalokiqueries... title: 查看相关日志 params: expr: {app${__field.labels.app}, levelerror} # 2. 日志面板VictoriaLogs 数据源通过 Loki 兼容 - title: 错误日志 datasource: loki # 配置为 VictoriaLogs targets: - expr: {app~$app, levelerror} | 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_idxxx} │ └── 获取该请求的完整错误堆栈 │ └── 【核心】统一 label 关联 └── 同一请求共享: app, trace_id, request_id └── 三数据源无缝跳转实战技巧vmui Grafana 组合使用vmui快速发现指标异常、查看告警、探索 Metrics 命名Grafana复杂 Dashboard、变量联动、Data Links 跳转VictoriaLogs UI独立日志查询、LogQL 调试三者组合使用覆盖可观测性全场景。必记闭环逻辑核心考点vmui 在 v1.146.0 中没有内置 Logs 查询面板三数据源联合查询主要通过Grafana实现。核心机制是变量联动多个面板共用相同变量筛选和Data Links点击跳转到其他数据源。完整工作流是 Metrics 发现异常 → 跳转 Traces 定位慢调用 → 跳转 Logs 查错误堆栈通过 traceID 串联。五、Grafana 三数据源集成Metrics Logs Traces 联动思考记忆提示— Grafana 是 VM 家族三产品联合查询的最佳入口关联产品VictoriaMetricsPrometheus 数据源、VictoriaLogsLoki 数据源、VictoriaTracesJaeger/Tempo 数据源关联工具Grafana Explore、Grafana Data Links、Grafana Variables核心机制变量联动 Data Links 跨数据源跳转Grafana 是 VM 家族三产品联合查询的最佳入口。通过添加三个数据源、配置变量联动和 Data Links可以实现 Metrics → Traces → Logs 的完整可观测性工作流。5.1 Grafana 数据源配置在 Grafana 中添加三个数据源数据源名称Grafana 类型URL备注VictoriaMetricsPrometheushttp://victoriametrics:8428支持 Prometheus HTTP APIVictoriaLogsLokihttp://victoria-logs:9428VL 兼容 Loki HTTP APIVictoriaTracesJaeger 或 Tempohttp://victoria-traces:9417VT 兼容 Jaeger API数据源配置步骤登录 Grafana → Configuration → Data Sources点击 Add data source搜索 Prometheus填写 VictoriaMetrics URL保存搜索 Loki填写 VictoriaLogs URL保存搜索 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 详情实战技巧快速定位问题Step 1在 Explore 中用 Prometheus 查询发现异常的 P99 延迟突刺Step 2复制该时间点的 traceIDStep 3切换到 Loki 数据源查询 {trace_idxxx}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 架构对比维度VictoriaLogsGrafana Loki存储引擎自研 MergeSet基于 VM 核心库分片 对象存储S3/GCS BoltDB 索引数据存储位置本地 SSD单二进制无外部依赖S3/GCS/Azure Blob必须云存储索引存储本地文件类似 VM indexDBBoltDB单机/ Cortex 模式多租户部署复杂度单二进制开箱即用需要 MinIO Cassandra 多个组件查询性能本地 SSD 高速读取对象存储 IO 受限压缩比字典压缩 增量编码VL 官方称 10xGzip 块压缩约 3-5x运维成本低无外部依赖高需要管理 MinIO、Cassandra适用场景中小规模日志具体阈值参考 VL 官方文档大规模日志 多租户需求5.2 性能基准对比根据 VictoriaLogs 官方博客VictoriaLogs vs Loki的基准测试具体性能数据请参考官方博客原文VictoriaLogs 和 Loki 在存储引擎上存在架构差异Loki 依赖对象存储做冷数据存储VictoriaLogs 用本地 SSD 跑 MergeSet 引擎。性能对比数字请以官方博客最新发布为准。存储架构VictoriaLogs 单二进制 本地 SSDLoki 多组件 对象存储核心差异存储引擎选择不同导致适用场景不同这些差异的根源是存储引擎的选择——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 家族的链路追踪产品关联产品VictoriaMetricsMetrics、VictoriaLogsLogs、VictoriaTracesTraces关联工具OTLP、Jaeger、Grafana Tempo核心特点与 VM/VL 共用部分核心库单二进制部署VictoriaTraces 是 VictoriaMetrics 公司推出的链路追踪产品与 VictoriaMetrics、VictoriaLogs 共同构成完整的可观测性三支柱解决方案。7.1 VictoriaTraces 架构VictoriaTraces 采用与 VictoriaMetrics 相似的架构哲学单二进制部署所有功能集成在一个可执行文件中本地 SSD 优先数据存储在本地高速磁盘MergeSet 存储引擎复用 VM 核心库的存储逻辑无外部依赖不像 Jaeger 需要 Cassandra/Elasticsearch7.2 OTLP 协议支持VictoriaTraces 支持 OTLPOpenTelemetry Protocol可接收来自任何 OTLP 兼容 SDK 的链路数据# 启动 VictoriaTraces默认监听 :10428 victoria-traces # 或指定端口 victoria-traces -httpListenAddr:8428 # 查看帮助 victoria-traces -help7.3 与 Jaeger/Grafana Tempo 的对比对比维度VictoriaTracesJaegerGrafana Tempo存储引擎MergeSet本地 SSDBoltDB/Cassandra/Elasticsearch对象存储 块索引部署复杂度单二进制多组件单二进制需对象存储外部依赖无Cassandra/ES生产S3/GCS/Azure BlobOTLP 支持是是是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 个关键最佳实践确保 MetricsLogsTraces 一体化监控稳定运行。6.1 实践 1vmagent 统一采集vmagent 可同时采集 Metrics、Logs 和 TracesMetrics通过 scrape_configs 抓取Logs通过 -syslog.listenAddr:1514 监听Traces通过 OTLP 接收需要 vmagent 支持统一用 vmagent简化运维。6.2 实践 2label 命名空间统一规划三数据源应使用相同的核心 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可选高 cardinality6.3 实践 3Grafana 三数据源配置在 Grafana 中添加三个数据源VictoriaMetrics类型 PrometheusURL: http://victoriametrics:8428VictoriaLogs类型 LokiURL: http://victoria-logs:9428VictoriaTraces类型 Tempo 或 JaegerURL: http://victoria-traces:94176.4 实践 4容量规划规模VMVLVT存储小规模1 节点1 节点1 节点1TB SSD中规模3 节点3 节点3 节点10TB SSD大规模ClusterHA 部署集群模式100TB SSD6.5 实践 5vmui 统一入口vmui 提供统一的 Web 界面/#/exploreExploreMetrics指标发现/#/traceTracePage链路查看/#/custom-panel自定义 Dashboard/#/alert告警规则管理必记闭环逻辑核心考点VM 家族三产品一体化部署的 5 个关键① vmagent 统一采集② label 命名空间统一③ Grafana 三数据源配置④ 容量规划⑤ vmui 统一入口。核心思想是复用基础设施、统一 label 规范、Grafana 联合查询。- namespace: k8s 命名空间 - pod: Pod 名 - container: 容器名 - node: 节点名 # 不要在 Logs 中使用高频变化 label如 request_id、user_id6.3 实践 3vmui 统一入口vmui 是 VictoriaMetrics 自带的 Web UI通过 URL 路径访问不同功能/#/exploreExploreMetrics指标发现/#/traceTracePage链路查看/#/custom-panel自定义 Dashboard/#/alert告警规则管理6.4 实践 4Grafana 三数据源配置在 Grafana 中添加三个数据源VictoriaMetrics类型 PrometheusURL: http://victoriametrics:8428VictoriaLogs类型 LokiURL: http://victoria-logs:9428VictoriaTraces类型 Tempo 或 JaegerURL: http://victoria-traces:94176.5 实践 5容量规划规模VMVLVT存储小规模1 节点1 节点1 节点1TB SSD中规模3 节点3 节点3 节点10TB SSD大规模ClusterHA 部署集群模式100TB SSD
