VictoriaMetrics lanza VictoriaStack para métricas, registros, trazas y resolución de problemas asistida por IA

VictoriaMetrics ha presentado VictoriaStack, una plataforma de observabilidad de código abierto que integra sus productos de métricas, registros y trazas distribuidas en un modelo operativo coordinado. El lanzamiento busca ofrecer a los equipos de ingeniería una forma de ampliar la cobertura de telemetría sin sustituir todo su entorno de monitorización ni obligar a almacenar todas las señales en la misma base de datos.

VictoriaStack combina VictoriaMetrics para las métricas, VictoriaLogs para los registros y VictoriaTraces para las trazas. Los equipos pueden adoptar las señales que necesiten y añadir otras más adelante, con herramientas de implementación compartidas y compatibilidad con OpenTelemetry para conectar los distintos componentes.

El anuncio también amplía este modelo a las operaciones asistidas por IA. Los servidores oficiales del Protocolo de Contexto de Modelo y las habilidades para agentes permiten a los asistentes investigar la telemetría en toda la plataforma, mientras que los ingenieros siguen siendo responsables de decidir qué cambios aplicar.

Tres señales, tres bases de datos especializadas

Las métricas, los registros y las trazas responden a distintas preguntas operativas. Las métricas resumen el comportamiento a lo largo del tiempo, por ejemplo, las tasas de solicitudes, la cantidad de errores o el consumo de memoria. Los registros consignan los eventos y sus detalles. Las trazas distribuidas siguen una solicitud a través de varios servicios y revelan dónde se empleó el tiempo y dónde se produjo un fallo.

Durante un incidente, un ingeniero podría detectar primero un aumento repentino de la latencia en las métricas, acotar el problema a un servicio mediante las trazas y, después, inspeccionar los registros para encontrar el error subyacente. Reunir esas señales en un flujo de trabajo coherente puede agilizar la investigación sin exigir que todas tengan los mismos requisitos de almacenamiento.

La documentación sobre la arquitectura de VictoriaStack describe bases de datos independientes que comparten un modelo común de componentes. Cada una puede ejecutarse como un único binario o como un clúster que separa la ingesta, el almacenamiento y las consultas. La plataforma puede usar vmauth como punto de entrada para el enrutamiento y el balanceo de carga.

Las interfaces de consulta también siguen siendo especializadas: VictoriaMetrics utiliza MetricsQL, compatible con PromQL; VictoriaLogs utiliza LogsQL; y VictoriaTraces admite LogsQL, además de API compatibles con Jaeger y Tempo. Por tanto, la operación coordinada no implica que haya una sola base de datos ni un lenguaje de consulta universal.

Las tres bases de datos principales están disponibles con la licencia Apache 2.0. La empresa también ofrece funcionalidades empresariales y asistencia comercial, además del servicio VictoriaMetrics Cloud, totalmente gestionado y compatible con las tres señales.

OpenTelemetry conecta la capa de recopilación

OpenTelemetry ofrece un enfoque común para instrumentar aplicaciones y exportar telemetría. Su protocolo OTLP es compatible con las métricas, los registros y las trazas de VictoriaStack, lo que proporciona a los equipos una vía de ingesta uniforme, aunque los datos se almacenen en distintos sistemas de respaldo.

Esta distinción es importante cuando una aplicación pasa de tener unos pocos servicios a convertirse en un sistema distribuido. La instrumentación debe ayudar a describir el comportamiento de la aplicación; cambiar el destino de la telemetría no debería exigir rediseñar el código de monitorización de cada servicio.

La plataforma también admite otros formatos de ingesta cuando corresponde. Por ejemplo, los equipos que ya recopilan métricas con Prometheus pueden conservar ese ecosistema e incorporar registros o trazas. La compatibilidad de protocolos reduce el trabajo de migración, mientras que la elección de la retención, la capacidad y los patrones de consulta sigue siendo una decisión de ingeniería.

Para las implementaciones de Kubernetes, VictoriaMetrics señala su operador y sus gráficos de Helm como herramientas habituales de gestión. El objetivo es dar más coherencia a las implementaciones y las actualizaciones, sin perder la posibilidad de escalar cada señal según las características de su propia carga de trabajo.

Los agentes de IA pueden investigar toda la telemetría

VictoriaStack aborda la IA desde dos perspectivas: los sistemas de observabilidad deben gestionar la telemetría generada por aplicaciones basadas en agentes, y los asistentes de IA pueden ayudar a los ingenieros a analizar esa telemetría.

La documentación de las herramientas de IA de la empresa describe servidores MCP independientes para métricas, registros y trazas. Estos ofrecen funciones estructuradas, como consultar series temporales, explorar campos de registros, localizar servicios y operaciones, y recuperar trazas. La integración de métricas también permite investigar la cardinalidad, el comportamiento de las consultas y la configuración de alertas.

El repositorio de habilidades para agentes incorpora flujos de trabajo reutilizables para investigar varias señales y realizar tareas operativas relacionadas. Un asistente puede seguir un proceso de resolución de problemas que abarque distintas señales, en lugar de depender de un único panel o de un mensaje de error copiado y pegado.

El anuncio describe el acceso de solo lectura para asistentes como Claude Code, Codex, Cursor y agentes internos. El flujo de trabajo previsto es, por tanto, de investigación: recopilar pruebas, relacionar síntomas y proponer una explicación, mientras los ingenieros deciden qué cambios aplicar. Conectar una fuente de telemetría a un agente no demuestra por sí solo que este haya identificado correctamente la causa raíz.

Escalar la ingesta y las consultas por separado

La guía de inicio rápido de VictoriaStack muestra configuraciones tanto de un solo nodo como en clúster. Su demostración con Docker Compose incluye una aplicación y un recopilador de OpenTelemetry, las tres bases de datos, Grafana, vmalert y vmauth. La documentación presenta explícitamente este entorno local como una demostración, no como un despliegue de producción.

En el modelo de clúster, los componentes de ingesta y consulta no tienen estado y pueden escalarse de forma independiente, mientras que los componentes de almacenamiento conservan los datos. Así se separan distintas necesidades: un mayor volumen de telemetría entrante puede requerir más capacidad de ingesta, mientras que un mayor número de ingenieros o agentes que realizan investigaciones puede aumentar la demanda de consultas.

La planificación del almacenamiento sigue siendo importante. La documentación indica que las bases de datos guardan la telemetría en sistemas de archivos locales; S3 o Google Cloud Storage se utilizan para las copias de seguridad, no como una capa de consulta sobre almacenamiento de objetos. También señala que reducir el número de fragmentos de almacenamiento es una operación compleja. Estas características son importantes al elegir una topología y prever el crecimiento.

Una pila coordinada sin migrarlo todo de una vez

VictoriaMetrics presentará VictoriaStack en KubeCon + CloudNativeCon North America 2026, con una demostración de una aplicación de Kubernetes instrumentada con OTLP que envía sus tres señales de telemetría a los backends correspondientes, seguida de un flujo de trabajo de resolución de problemas que abarca varias señales.

«La era agéntica traerá más telemetría y mayores exigencias sobre cómo la procesamos», afirmó Roman Khavronenko, cofundador y gerente de ingeniería de VictoriaMetrics, en el anuncio. Añadió que VictoriaStack está diseñado para ofrecer escalabilidad y eficiencia a medida que crece esa demanda.

La propuesta práctica consiste en adoptarlo de forma gradual: conservar un ecosistema de recopilación útil, incorporar las señales que falten y gestionar los servicios resultantes con un modelo más coherente. El valor de VictoriaStack reside en lo bien que funcionan en conjunto esos componentes a medida que aumentan el volumen de telemetría y la demanda de investigación, al tiempo que los equipos mantienen el control sobre dónde residen sus datos y cómo escala cada señal.