VictoriaMetrics推出VictoriaStack，涵盖指标、日志、追踪与AI辅助故障排查

VictoriaMetrics推出了VictoriaStack，这是一套开源可观测性技术栈，将其指标、日志和分布式追踪产品整合到协同运作模式中。此次发布旨在为工程团队提供一种扩展遥测覆盖范围的方式，无需替换整个监控环境，也不必将所有信号都存入同一个数据库。

VictoriaStack整合了用于指标的VictoriaMetrics、用于日志的VictoriaLogs，以及用于追踪的VictoriaTraces。团队可以先采用所需的信号，之后再逐步添加其他信号；共享的部署工具和对OpenTelemetry的支持则有助于将各部分连接起来。

此次发布还将这一模式扩展至AI辅助运维。官方的Model Context Protocol服务器和智能体技能使AI助手能够调查整个技术栈中的遥测数据，同时由工程师负责决定应用哪些变更。

三种信号，三种专用数据库

指标、日志和追踪分别回答不同的运维问题。指标概括一段时间内的运行情况，例如请求速率、错误数或内存用量。日志记录事件及其详细信息。分布式追踪则跟踪请求在多个服务间的流转过程，揭示时间花在了哪里，以及故障出现在何处。

发生故障时，工程师可能会先从指标中发现延迟激增，再通过追踪将问题范围缩小到某个服务，随后检查日志以查找根本错误。将这些信号纳入一致的工作流程，有助于缩短调查时间，同时不必让它们采用相同的存储要求。

VictoriaStack的架构文档介绍了采用通用组件模型、彼此独立的数据库。每个数据库都可以作为单一二进制文件运行，也可以采用集群部署，将数据摄取、存储和查询分开。该技术栈还可将vmauth用作路由和负载均衡的入口。

各数据库仍采用各自专用的查询接口：VictoriaMetrics使用兼容PromQL的MetricsQL，VictoriaLogs使用LogsQL，而VictoriaTraces除了支持LogsQL，还支持兼容Jaeger和Tempo的API。因此，协同运作并不意味着使用单一数据库或一种通用查询语言。

这三种核心数据库均采用Apache 2.0许可证。此外，该公司还提供企业级功能和商业支持，以及支持这三种信号的全托管VictoriaMetrics Cloud服务。

OpenTelemetry打通数据采集层

OpenTelemetry为应用程序插桩和遥测数据导出提供了一种通用方法。VictoriaStack的指标、日志和追踪均支持其OTLP协议，因此即使数据最终进入不同的后端，团队仍可采用一致的数据摄取路径。

当应用从少数几个服务扩展为分布式系统时，这一区别就很重要。插桩应有助于描述应用的运行情况；更改遥测数据的目标位置，不应要求重新设计每个服务的监控代码。

在适用情况下，该技术栈还支持其他数据摄取格式。例如，已经采用Prometheus采集指标的团队可以保留现有生态，同时在其基础上引入日志或追踪。协议兼容性能够减少迁移工作，但保留期限、容量和查询模式的选择仍属于工程决策。

对于Kubernetes部署，VictoriaMetrics将其Operator和Helm图表列为常用管理工具。其目标是在提高部署和升级一致性的同时，保留根据各类信号自身的工作负载分别扩展的能力。

AI智能体可跨遥测数据开展调查

VictoriaStack从两个方面着手应用AI：可观测性系统必须能够处理智能体应用生成的遥测数据，而AI助手则可以帮助工程师查询和分析这些数据。

该公司的AI工具文档介绍了分别用于指标、日志和追踪的MCP服务器。它们提供结构化功能，例如查询时间序列、探索日志字段、查找服务和操作，以及检索追踪数据。指标集成还支持对基数、查询行为和告警配置进行调查。

其智能体技能仓库还提供可复用的工作流程，用于多信号调查及相关运维任务。助手可以跨多个信号遵循故障排查流程，而不是只依赖单个仪表板或粘贴过来的错误消息。

公告介绍了面向Claude Code、Codex、Cursor及内部智能体的只读访问权限。预期的工作流程因此侧重于调查：收集证据、关联症状并提出解释，同时由工程师决定应用哪些内容。将遥测数据源连接到智能体，本身并不能证明该智能体已正确找出根本原因。

分别扩展数据摄取与查询能力

VictoriaStack 快速入门展示了单节点和集群两种配置。其 Docker Compose 演示包含一个 OpenTelemetry 应用及采集器、三个数据库、Grafana、vmalert 和 vmauth。文档明确指出，这个本地环境仅用于演示，并非生产部署。

在集群模式下，数据写入和查询组件均为无状态组件，可以独立扩展；存储组件则负责保存数据。这样可以分别应对不同的负载压力：传入的遥测数据增多时，可能需要提升数据写入能力；运行调查任务的工程师或智能体增多时，查询需求也可能随之上升。

存储规划仍然至关重要。文档指出，各数据库会将遥测数据保存在本地文件系统中；S3 或 Google Cloud Storage 用于备份，而不作为对象存储查询层。文档还指出，减少存储分片数量是一项复杂操作。在选择拓扑结构和预测增长情况时，都需要考虑这些特性。

协同运作的技术栈，无需一次性迁移

VictoriaMetrics 将在 KubeCon + CloudNativeCon North America 2026 上展示 VictoriaStack：演示一个经过 OTLP 埋点的 Kubernetes 应用，将三种遥测信号分别发送到对应的后端，随后展示跨信号故障排查流程。

VictoriaMetrics 联合创始人兼工程经理 Roman Khavronenko 在公告中表示：“智能体时代将带来更多遥测数据，也会对数据处理方式提出更高要求。”他表示，VictoriaStack 的设计着眼于随着需求增长而实现可扩展性和效率。

这一方案的实际价值在于循序渐进地采用：保留现有且实用的采集生态，补充缺失的信号，并通过更统一的模式管理由此产生的服务。随着遥测数据量和调查需求不断增加，VictoriaStack 的价值取决于这些组件能否协同运作，同时让团队继续掌控数据的存放位置以及各类信号的扩展方式。