Dzmitry Lazerka, Co-fundador de VictoriaMetrics – Serie de entrevistas

Dzmitry Lazerka, cofundador de VictoriaMetrics es un ingeniero de software experimentado y líder tecnológico con profunda experiencia en aprendizaje automático, sistemas de datos a gran escala, observabilidad e infraestructura. Antes de cofundar VictoriaMetrics en 2018, trabajó como Ingeniero de Aprendizaje Automático en la división de vehículos autónomos Level 5 de Lyft, donde ayudó a desarrollar sistemas para reconocer y analizar escenarios de conducción del mundo real. Anteriormente, dirigió proyectos de aprendizaje automático e infraestructura de datos en Spire Global, se desempeñó como cofundador de ingeniería en Bellgram y trabajó en sistemas de datos y analítica en Duetto Research y Google a través de EPAM Systems. A lo largo de su carrera, Lazerka ha construido y liderado proyectos que abarcan conducción autónoma, predicción marítima, búsqueda, analítica, procesamiento distribuido de datos y sistemas backend altamente escalables.

VictoriaMetrics es una empresa de observabilidad de código abierto que crea herramientas para recopilar, almacenar, consultar y analizar grandes volúmenes de datos operacionales. Su tecnología comenzó con VictoriaMetrics, una base de datos de series temporales de alto rendimiento y solución de monitoreo diseñada para la escalabilidad, consultas rápidas, almacenamiento eficiente y bajo consumo operativo, y desde entonces se ha ampliado a una pila de observabilidad más amplia que cubre métricas, registros y trazas distribuidas a través de VictoriaMetrics, VictoriaLogs y VictoriaTraces. La empresa también ofrece implementaciones empresariales y totalmente gestionadas en la nube, junto con capacidades de detección de anomalías que aplican aprendizaje automático a datos de series temporales. Su plataforma soporta tecnologías como OpenTelemetry, flujos de trabajo compatibles con Prometheus, Grafana y Kubernetes, brindando a las organizaciones flexibilidad para integrar VictoriaMetrics en entornos de observabilidad existentes.

Antes de cofundar VictoriaMetrics, trabajaste en sistemas de datos a gran escala, analítica y aprendizaje automático en Google, Spire Global, la división de vehículos autónomos de Lyft y otras startups. ¿Qué te llevó finalmente a fundar VictoriaMetrics y qué problemas de esos roles anteriores te convencieron de que la monitorización y la observabilidad necesitaban un enfoque fundamentalmente diferente?

He dedicado mi carrera a trabajar con grandes volúmenes de datos. En Google, Spire, Lyft y otras empresas, aprendes rápidamente que algo que funciona bien a una escala puede volverse costoso o difícil de operar a otra escala. La monitorización tiene exactamente este problema.

A medida que la infraestructura crece, generas más métricas. Añades más servicios, más instancias y más etiquetas hasta que, de repente, el propio sistema de monitorización necesita una cantidad significativa de infraestructura, lo cual nunca tuvo sentido para nosotros. Un sistema diseñado para monitorizar tu entorno de producción no debería volverse más complicado y costoso de operar.

Esto fue lo que mis cofundadores Aliaksandr Valialkin y Roman Khavronenko observaron directamente. Tenían experiencia operando Prometheus y encontrándose con limitaciones de memoria. Añadir sistemas como Thanos resolvió ciertos problemas de escalado, pero también introdujo más componentes y mayor complejidad operativa. Y con InfluxDB, vimos cómo un cambio de licencia podía afectar decisiones de ingeniería después de que los equipos ya hubieran invertido en la tecnología.

Así que la idea detrás de VictoriaMetrics era práctica: ¿Podemos crear una base de datos de series temporales que haga el mismo trabajo con significativamente menos recursos y sea más sencilla de operar?

No empezamos con el plan de crear una gran empresa de observabilidad. Empezamos resolviendo un problema de ingeniería.

Hacerlo de código abierto formó parte de eso. Los ingenieros podían descargar VictoriaMetrics, ejecutar cargas de trabajo reales de producción contra él y comparar los resultados por sí mismos. No necesitábamos decirles que era más rápido o más eficiente. Podían medirlo.

Esta es la mejor manera de crear software de infraestructura. Si la tecnología es buena, los ingenieros deberían poder demostrarlo por sí mismos.

Los costos de observabilidad pueden convertirse silenciosamente en una parte significativa de la factura de nube de una empresa. ¿Dónde suelen esos costos descontrolarse y qué decisiones arquitectónicas o de compra cometen con más frecuencia los equipos de ingeniería?

Primero observaría la cardinalidad.

Supongamos que comienzas con una métrica razonable y luego añades una etiqueta con valores posibles. De repente, una métrica se convierte en miles o millones de series temporales únicas. El sistema ahora tiene más datos para ingerir, indexar, almacenar y consultar, lo que resulta en mayor uso de CPU, memoria y almacenamiento.

La parte difícil es que esto no ocurre porque alguien haya tomado una mala decisión. Sucede gradualmente. Añade más servicios, pods de K8s, clientes y etiquetas, y el costo se multiplica.

El segundo problema es almacenar todo a la misma resolución durante el mismo período de tiempo. No todos los datos de observabilidad tienen el mismo valor. Las métricas que necesitas para una alerta o un SLO son diferentes de la telemetría diagnóstica de alto volumen que podrías revisar una sola vez durante un incidente.

Si tratas todos esos datos de la misma manera, terminas pagando precios premium de infraestructura o SaaS por datos que no lo requieren.

Por eso algunas empresas abordan la observabilidad como un problema de compra, preguntándose qué plataforma es la más fácil de desplegar hoy. Yo hago preguntas como: «¿Qué ocurre cuando la cantidad de telemetría aumenta 10 veces? ¿Qué pasa con la cardinalidad? ¿Qué estamos almacenando? ¿Durante cuánto tiempo? ¿Y qué ocurre con el costo?»

Existen soluciones de ingeniería para estos problemas. Por ejemplo, con agregación en streaming, puedes agregar métricas antes de que lleguen al almacenamiento en lugar de almacenar cada serie temporal cruda y agregarla después. Puedes separar cargas de trabajo de alta cardinalidad de la monitorización crítica para el negocio. También puedes usar políticas de retención y resolución diferentes según el valor de los datos.

El objetivo no es recopilar la menor cantidad posible de telemetría. Necesitas suficiente información para entender qué están haciendo tus sistemas.

El objetivo es evitar gastar recursos en recopilar, procesar y almacenar datos de una manera que no te aporte valor adicional.

La observabilidad es un sistema de ingeniería. Su costo también debe ser diseñado.

Grammarly ha dicho que su prueba de concepto con VictoriaMetrics se tradujo en una factura de AWS 10 veces menor. Cuando las empresas logran ahorros a esa escala, ¿qué está cambiando realmente bajo el capó: la compresión de datos, los requisitos de cómputo, la arquitectura de almacenamiento, la complejidad operativa o alguna combinación de estos factores?

Es una combinación, pero la compresión y la huella de recursos hacen la mayor parte del trabajo. VictoriaMetrics utiliza compresión diseñada específicamente para datos de series temporales, por lo que las mismas métricas ocupan una fracción del espacio en disco que ocuparían en una base de datos de propósito general. Además, consumimos entre cuatro y cinco veces menos RAM que Prometheus a tasas de ingestión equivalentes, y hasta diez veces menos disco. Cuando Grammarly realizó su prueba de concepto, eso se reflejó directamente en su factura de AWS, porque no solo estaban almacenando menos datos; estaban ejecutando menos y más pequeñas instancias para hacerlo.

El aspecto de la complejidad operativa también importa, aunque es más indirecto. Muchos equipos que calculan los costos de observabilidad solo consideran los ítems de almacenamiento y cómputo y pasan por alto las horas de ingeniería dedicadas a operar una pila de Thanos de cinco componentes frente a un único binario. Eso es dinero real; solo que es más difícil cuantificarlo.

Prometheus se ha convertido en fundamental para la monitorización cloud‑native, sin embargo, algunas organizaciones eventualmente se encuentran con limitaciones de escalabilidad u operativas. ¿Qué suele provocar que una empresa empiece a buscar más allá de una implementación convencional de Prometheus, y cuándo se vuelve VictoriaMetrics una alternativa lógica?

Prometheus es excelente en lo que fue creado: un motor de recopilación y alertas de un solo nodo. Los equipos generalmente se topan con el límite de dos maneras: o bien su cardinalidad supera lo que una única instancia de Prometheus puede mantener en memoria, o necesitan retención a largo plazo y consultas globales en múltiples clústeres, para lo cual Prometheus nunca fue diseñado. Es entonces cuando la gente añade Thanos o Cortex, lo que suele ser el punto donde comienza el dolor operativo. Pasas de ejecutar un único binario a operar un sistema distribuido con un compactor, un consultor, una puerta de enlace de almacenamiento y mucho más que puede fallar a las 3 a.m.

VictoriaMetrics se convierte en el siguiente paso lógico porque es un reemplazo directo, no una re‑arquitectura. Los equipos apuntan su configuración de recopilación de Prometheus existente a VictoriaMetrics y conservan cada panel de Grafana, alerta y regla de grabación que ya habían creado. La migración es un cambio de configuración, no un proyecto, y obtienen la escala sin añadir cinco nuevos componentes para operar.

Estamos viendo a los equipos de ingeniería reconsiderar si necesitan plataformas de observabilidad grandes y totalmente gestionadas o si pueden construir pilas más eficientes a partir de componentes de código abierto. ¿Ve esto como un cambio estructural más amplio en el mercado de observabilidad, y cuánto presión está ejerciendo el código abierto sobre los modelos de precios tradicionales?

Es estructural; no es una reacción temporal a un año de presupuesto deficiente. Los proveedores de observabilidad históricamente han fijado precios según el volumen de ingestión o el número de hosts, y ese modelo perjudica al cliente a medida que su negocio crece. Cuanto más exitosa es una empresa, más paga, y el precio no tiene una relación real con el valor entregado. Los equipos de ingeniería han comenzado a hacer los cálculos por sí mismos, dándose cuenta de que una pila de código abierto auto‑alojada y eficiente cambia esa ecuación por completo. Esto se debe a que el costo escala con la infraestructura realmente ejecutada, en lugar de una fórmula de medición controlada por el proveedor.

Esto ejerce una presión real sobre los precios de los incumbentes. Cuando un equipo puede apuntar su configuración de recopilación existente a una alternativa de código abierto y reducir la factura entre un 60 % y un 80 % sin perder funcionalidad, no es una conversación difícil de mantener internamente. Los proveedores que siguen cobrando por host o métrica personalizada seguirán drenando a los clientes que no hacen estos cálculos.

La infraestructura de IA introduce un recurso nuevo inusualmente costoso en la ecuación: las GPU. ¿Qué deberían monitorear las empresas que ejecutan entrenamiento o inferencia de IA más allá de la utilización básica de la GPU, y dónde puede una mejor observabilidad traducirse directamente en menores costos de infraestructura de IA?

La utilización de la GPU por sí sola no le dice lo suficiente.

Puede ver un 90 % de utilización en un panel y asumir que todo está bien. Pero lo que realmente quiere saber es: ¿Qué está haciendo la GPU?

Necesita mirar más a fondo. ¿Qué kernels CUDA se están ejecutando? ¿Cómo se está asignando la memoria de la GPU? ¿Cuánto tiempo se dedica a mover memoria en lugar de realizar cálculos? ¿La carga de trabajo está usando Tensor Cores cuando debería? ¿La GPU es realmente el cuello de botella, o está esperando datos de otro lugar?

Estas son preguntas importantes porque las GPU son caras. Una pequeña ineficiencia repetida en cientos o miles de GPU se convierte en una cantidad de dinero muy grande.

Por ejemplo, si las GPU están esperando porque la canalización de datos no puede alimentarlas lo suficientemente rápido, comprar más GPU no resolverá el problema. Hay que encontrar el cuello de botella. Lo mismo ocurre con la memoria. Si las cargas de trabajo asignan memoria de forma ineficiente, una mejor visibilidad puede ayudar a los ingenieros a ajustar los tamaños de lote o ejecutar más cargas de trabajo en el mismo hardware.

Esto es donde la observabilidad se vuelve interesante para la infraestructura de IA. No se trata solo de detectar que algo está roto. Puede indicarle dónde está desperdiciando cómputo.

También existe un problema de observabilidad creado por todo este monitoreo. Las GPU pueden generar una gran cantidad de telemetría detallada y de alta cardinalidad. Si recopila todo y lo envía directamente a una plataforma SaaS costosa, puede reducir sus costos de GPU y luego gastar parte del ahorro almacenando datos de monitoreo. Pero eso no es una buena optimización.

Con OpenTelemetry y proyectos como OpenLIT, podemos obtener una visibilidad mucho más profunda de las cargas de trabajo de GPU. Luego, con VictoriaMetrics, podemos agregar los datos, eliminar dimensiones que no son útiles y retener de manera eficiente la información que los ingenieros realmente necesitan.

La pregunta útil no es, “¿Qué tan utilizadas están mis GPU?”

Es, “¿Qué trabajo útil estoy obteniendo de las GPU por las que estoy pagando?”

Una vez que pueda responder eso, podrá comenzar a tomar mejores decisiones de ingeniería y de costos.

Los agentes de IA crean desafíos de observabilidad muy diferentes a los del software tradicional porque una única solicitud puede desencadenar llamadas a modelos, uso de herramientas, consultas a bases de datos vectoriales, transferencias y potencialmente largas cadenas de acciones autónomas. ¿Cómo debe evolucionar la observabilidad a medida que las aplicaciones empresariales se vuelven cada vez más agenticas?

La observabilidad tradicional asume que una solicitud sigue un camino bastante predecible a través de su infraestructura. Las cargas de trabajo agenticas no funcionan de esa manera. Un solo agente puede llamar a un modelo, luego a una herramienta, después a otro modelo y reintentar tres veces antes de devolver algo. Cada uno de esos pasos necesita su propia visibilidad.

Los modos de falla también son diferentes. Un servicio tradicional o responde correctamente o no lo hace. Un agente puede responder con éxito y, sin embargo, estar equivocado, ser lento o costoso, y nada de eso aparece como un error típico en un panel construido para la disponibilidad.

La parte que sorprende a los equipos es la cardinalidad. Un flujo de trabajo de un solo agente puede generar métricas vinculadas a un usuario, solicitud y llamada a herramienta específicos, y ese volumen se acumula rápidamente, especialmente con bucles de recursión donde un planificador sigue llamando a la misma herramienta. Cualquier sistema destinado a observar cargas de trabajo agenticas debe manejar esa escala sin que la curva de costos se vuelva vertical, que es exactamente el problema que estamos resolviendo. Las métricas, los registros y los rastros siguen siendo los bloques de construcción correctos. Lo que debe cambiar es el volumen y el modelo de costos subyacente.

VictoriaMetrics también ha estado aplicando aprendizaje automático y flujos de trabajo asistidos por IA a la detección de anomalías. ¿Dónde cree que la IA puede mejorar genuinamente la monitorización y la respuesta a incidentes hoy, y dónde el juicio humano sigue siendo difícil de reemplazar?

Es importante mantener a una persona en el proceso para generar ideas, dirigir la implementación y validar los resultados. En otras palabras, nada ha cambiado realmente en comparación con el flujo de trabajo tradicional. Lo que ha cambiado es que las capacidades para generar soluciones se han amplificado. Cualquiera puede crear software ahora, pero eso no debería reducir los criterios de aceptación. Debería aumentarlos significativamente.

Donde la IA ayuda genuinamente es al revelar lo que una persona pasaría por alto en el ruido, cosas como valores atípicos y tendencias que no activan un umbral manual. En VictoriaMetrics, tenemos una política interna de IA simple: los empleados son libres de automatizar su flujo de trabajo como deseen, pero siguen siendo responsables del resultado final. Ese es aproximadamente el mismo estándar que aplicaríamos a la detección de anomalías en el entorno de producción de un cliente. El modelo puede señalarlo, pero una persona aún debe decidir qué significa y qué hacer al respecto.

VictoriaMetrics se ha mantenido de código abierto y ha adoptado un enfoque autofinanciado y financiado por clientes, en lugar de seguir el modelo tradicional de startups de infraestructura respaldadas por capital de riesgo. ¿Cómo ha influido eso en la forma en que construye el producto, lo precifica y decide qué tecnologías permanecen de código abierto?

Ser autofinanciado cambia la estructura de incentivos más de lo que la gente espera. Sin una junta que nos exija alcanzar una cifra de ARR en un trimestre específico, no hemos tenido que hacer los compromisos que normalmente vienen con esa presión, como limitar la versión de código abierto para obligar a la gente a pasar a un nivel pago, o cambiar la licencia como hicieron InfluxDB o HashiCorp cuando necesitaban proteger los ingresos de los proveedores de nube. VictoriaMetrics OSS es Apache 2.0 hoy, y no tenemos planes de cambiar eso.

La forma en que decidimos qué permanece en código abierto es simple: el motor central, aquello en lo que los ingenieros deben confiar sus datos de producción, sigue abierto. Cobramos por lo que una empresa necesita una vez que opera a gran escala y requiere a alguien responsable: multitenencia, autenticación empresarial, soporte de cumplimiento, un SLA de CVE y acceso directo a los ingenieros que escribieron el código en lugar de una cola de soporte. Estar financiado por clientes también significa que la hoja de ruta la determina lo que la gente realmente encuentra en producción, no lo que es financiable en una presentación para inversores.

A medida que métricas, registros, trazas, telemetría de aplicaciones de IA, monitoreo de GPU y detección automática de anomalías convergen cada vez más, ¿cómo crees que será el stack de observabilidad en los próximos años y qué esperarán los equipos de ingeniería de las plataformas que quieran seguir siendo relevantes?

El stack converge operativamente antes de converger como un único producto, y esa distinción es importante. La mayoría de los equipos no quieren una plataforma monolítica con una única interfaz que lo bloquee todo. Lo que desean es que métricas, registros y trazas se ejecuten bajo un mismo modelo operativo, un único proveedor y una única política de licencias, sin tener que renunciar a la posibilidad de ejecutar cada señal de forma independiente si eso es lo que necesita un equipo concreto. Esa es la dirección en la que VictoriaMetrics está trabajando. No intentamos integrar todo en un solo binario. Queremos asegurarnos de que las tres señales compartan el mismo motor y las mismas características de eficiencia, de modo que añadir una segunda o tercera señal no signifique adoptar un segundo o tercer dolor de cabeza operativo.

Las plataformas que siguen siendo relevantes son aquellas que pueden absorber la telemetría de IA y el monitoreo de GPU en ese mismo modelo sin que la curva de costos se rompa. Las cargas de trabajo de IA generan telemetría en un volumen para el que los precios tradicionales por métrica o por host nunca fueron diseñados. Los equipos dejan de recopilar los datos que necesitan o su factura de observabilidad crece más rápido que la inversión en IA que se supone deben vigilar. Los equipos de ingeniería esperarán que las plataformas manejen ese volumen de la misma manera que esperan que cualquier infraestructura escale, sin que se les pida re‑arquitecturar o renegociar cada vez que la carga de trabajo aumente.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar VictoriaMetrics.