Dzmitry Lazerka, cofundador da VictoriaMetrics – Série de entrevistas

Dzmitry Lazerka, cofundador da VictoriaMetrics é um engenheiro de software experiente e líder tecnológico com profunda expertise em aprendizado de máquina, sistemas de dados em larga escala, observabilidade e infraestrutura. Antes de cofundar a VictoriaMetrics em 2018, trabalhou como engenheiro de aprendizado de máquina na divisão de veículos autônomos Level 5 da Lyft, onde ajudou a desenvolver sistemas para reconhecer e analisar cenários de condução do mundo real. Anteriormente, liderou projetos de aprendizado de máquina e infraestrutura de dados na Spire Global, atuou como cofundador de engenharia na Bellgram e trabalhou em sistemas de dados e análise na Duetto Research e no Google através da EPAM Systems. Ao longo de sua carreira, Lazerka construiu e liderou projetos que abrangem condução autônoma, previsão marítima, busca, análise, processamento distribuído de dados e sistemas de backend altamente escaláveis.

VictoriaMetrics é uma empresa de observabilidade de código aberto que desenvolve ferramentas para coletar, armazenar, consultar e analisar grandes volumes de dados operacionais. Sua tecnologia começou com o VictoriaMetrics, um banco de dados de séries temporais de alto desempenho e solução de monitoramento projetada para escalabilidade, consultas rápidas, armazenamento eficiente e baixa sobrecarga operacional, e desde então se expandiu para uma pilha de observabilidade mais ampla que cobre métricas, logs e rastreamentos distribuídos por meio do VictoriaMetrics, VictoriaLogs e VictoriaTraces. A empresa também oferece implantações empresariais e totalmente gerenciadas na nuvem, juntamente com recursos de detecção de anomalias que aplicam aprendizado de máquina a dados de séries temporais. Sua plataforma suporta tecnologias como OpenTelemetry, fluxos de trabalho compatíveis com Prometheus, Grafana e Kubernetes, proporcionando às organizações flexibilidade para integrar o VictoriaMetrics em ambientes de observabilidade existentes.

Antes de cofundar a VictoriaMetrics, você trabalhou em sistemas de dados em larga escala, analytics e aprendizado de máquina na Google, Spire Global, na divisão de veículos autônomos da Lyft e em outras startups. O que finalmente o levou a fundar a VictoriaMetrics, e quais problemas desses cargos anteriores o convenceram de que monitoramento e observabilidade precisavam de uma abordagem fundamentalmente diferente?

Passei minha carreira trabalhando com grandes volumes de dados. Na Google, Spire, Lyft e outras empresas, aprende‑se rapidamente que algo que funciona bem em uma escala pode se tornar caro ou difícil de operar em outra escala. O monitoramento tem exatamente esse problema.

À medida que a infraestrutura cresce, você cria mais métricas. Adiciona mais serviços, mais instâncias e mais rótulos até que, de repente, o próprio sistema de monitoramento precise de uma quantidade significativa de infraestrutura, o que nunca fez sentido para nós. Um sistema projetado para monitorar seu ambiente de produção não deve se tornar mais complicado e caro de operar.

Foi isso que meus co‑fundadores Aliaksandr Valialkin e Roman Khavronenko observaram diretamente. Eles tinham experiência operando o Prometheus e encontrando limitações de memória. A adição de sistemas como o Thanos resolveu alguns problemas de escalabilidade, mas também introduziu mais componentes e maior complexidade operacional. E com o InfluxDB, vimos como uma mudança de licenciamento pode afetar decisões de engenharia depois que as equipes já haviam investido na tecnologia.

Portanto, a ideia por trás da VictoriaMetrics era prática: podemos construir um banco de dados de séries temporais que faça o mesmo trabalho com significativamente menos recursos e seja mais simples de operar?

Não começamos com o plano de criar uma grande empresa de observabilidade. Começamos resolvendo um problema de engenharia.

Torná‑lo de código aberto fez parte disso. Os engenheiros podiam baixar o VictoriaMetrics, aplicar cargas de trabalho reais de produção e comparar os resultados por si mesmos. Não precisávamos dizer a eles que era mais rápido ou mais eficiente. Eles podiam medir.

Essa é a melhor forma de construir software de infraestrutura. Se a tecnologia for boa, os engenheiros devem ser capazes de comprová‑la por si mesmos.

Os custos de observabilidade podem silenciosamente se tornar uma parte significativa da conta de nuvem de uma empresa. Onde esses custos geralmente saem do controle, e quais decisões arquiteturais ou de compra as equipes de engenharia mais frequentemente erram?

Eu começaria analisando a cardinalidade.

Suponha que você comece com uma métrica razoável e, em seguida, adicione um rótulo com valores possíveis. De repente, uma métrica se transforma em milhares ou milhões de séries temporais únicas. O sistema passa a ter mais dados para ingerir, indexar, armazenar e consultar, resultando em mais CPU, memória e armazenamento.

A parte difícil é que isso não acontece porque alguém tomou uma decisão errada. O processo ocorre gradualmente. Adicione mais serviços, pods do K8s, clientes e rótulos, e o custo se multiplica.

O segundo problema é armazenar tudo na mesma resolução pelo mesmo período de tempo. Nem todos os dados de observabilidade têm o mesmo valor. As métricas necessárias para um alerta ou um SLO são diferentes da telemetria diagnóstica de alto volume que você pode analisar apenas uma vez durante um incidente.

Se você tratar todos esses dados da mesma forma, acabará pagando preços premium de infraestrutura ou SaaS por dados que não exigem isso.

É por isso que algumas empresas encaram a observabilidade como um problema de compra, perguntando qual plataforma é mais fácil de implantar hoje. Eu faço perguntas como: “O que acontece quando a quantidade de telemetria aumenta 10 vezes? O que acontece com a cardinalidade? O que estamos armazenando? Por quanto tempo? E o que acontece com o custo?”

Existem soluções de engenharia para esses problemas. Por exemplo, com agregação em streaming, você pode agregar métricas antes que elas cheguem ao armazenamento, em vez de armazenar cada série temporal bruta e agregá‑la depois. Você pode separar cargas de trabalho de alta cardinalidade da monitoramento crítico para o negócio. Também pode usar políticas de retenção e resolução diferentes dependendo do valor dos dados.

O objetivo não é coletar o mínimo de telemetria possível. Você precisa de informações suficientes para entender o que seus sistemas estão fazendo.

O objetivo é evitar gastar recursos coletando, processando e armazenando dados de maneira que não lhe traga valor adicional.

A observabilidade é um sistema de engenharia. Seu custo também deve ser projetado.

A Grammarly afirmou que sua prova de conceito com o VictoriaMetrics resultou em uma conta da AWS 10 vezes menor. Quando as empresas alcançam economias nessa escala, o que realmente está mudando nos bastidores: compressão de dados, requisitos de computação, arquitetura de armazenamento, complexidade operacional ou alguma combinação desses fatores?

É uma combinação, mas a compressão e a pegada de recursos fazem a maior parte do trabalho. O VictoriaMetrics usa compressão desenvolvida especificamente para dados de séries temporais, de modo que as mesmas métricas ocupam uma fração do espaço em disco que ocupariam em um banco de dados de uso geral. Além disso, usamos de quatro a cinco vezes menos RAM que o Prometheus em taxas de ingestão equivalentes, e até dez vezes menos disco. Quando a Grammarly realizou sua prova de conceito, isso apareceu diretamente na conta da AWS, porque eles não estavam apenas armazenando menos dados; estavam executando menos e menores instâncias para isso.

A questão da complexidade operacional também importa, mas é mais indireta. Muitas equipes que calculam os custos de observabilidade olham apenas para os itens de armazenamento e computação e deixam de considerar as horas de engenharia gastas operando uma pilha Thanos de cinco componentes versus um único binário. Isso representa dinheiro real; apenas é mais difícil quantificar.

O Prometheus se tornou fundamental para o monitoramento nativo da nuvem, porém algumas organizações acabam encontrando limitações de escalabilidade ou operacionais. O que normalmente leva uma empresa a começar a buscar além de uma implantação convencional do Prometheus, e quando o VictoriaMetrics se torna uma alternativa lógica?

O Prometheus é excelente no que foi criado: um mecanismo de coleta e alerta de nó único. As equipes geralmente esbarram em duas situações: ou a cardinalidade cresce além do que uma única instância do Prometheus pode armazenar na memória, ou precisam de retenção de longo prazo e consultas globais em vários clusters, para os quais o Prometheus nunca foi projetado. É então que as pessoas adicionam Thanos ou Cortex, o que costuma ser onde a dor operacional começa. Você passa de executar um único binário para operar um sistema distribuído com um compactador, um consultor, um gateway de armazenamento e muito mais, que pode falhar às 3 da manhã.

O VictoriaMetrics se torna o próximo passo lógico porque é um substituto imediato, não uma rearquitetura. As equipes apontam sua configuração de coleta do Prometheus existente para o VictoriaMetrics e mantêm todos os dashboards, alertas e regras de gravação do Grafana que já criaram. A migração é uma mudança de configuração, não um projeto, e elas obtêm a escala sem precisar adicionar cinco novos componentes para operar.

Estamos vendo equipes de engenharia reconsiderarem se precisam de grandes plataformas de observabilidade totalmente gerenciadas ou se podem construir pilhas mais eficientes a partir de componentes de código aberto. Você vê isso como uma mudança estrutural mais ampla no mercado de observabilidade, e quanto pressão o código aberto está exercendo sobre os modelos de precificação tradicionais?

É estrutural; não uma reação temporária a um ano de orçamento ruim. Os fornecedores de observabilidade historicamente precificam por volume de ingestão ou número de hosts, e esse modelo funciona contra o cliente à medida que seu negócio cresce. Quanto mais bem-sucedida a empresa se torna, mais paga, e o preço não tem relação real com o valor entregue. As equipes de engenharia começaram a fazer as contas por conta própria, percebendo que uma pilha de código aberto auto-hospedada e eficiente altera completamente essa equação. Isso ocorre porque o custo escala com a infraestrutura realmente utilizada, e não com uma fórmula de medição controlada pelo fornecedor.

Isso coloca pressão real sobre a precificação dos incumbentes. Quando uma equipe pode apontar sua configuração de coleta existente para uma alternativa de código aberto e reduzir a conta em 60 a 80 % sem perder funcionalidades, não é uma conversa difícil de ter internamente. Os fornecedores que ainda cobram por host ou métrica personalizada continuarão drenando os clientes que não fazem esse cálculo.

A infraestrutura de IA introduz um recurso novo e incomumente caro na equação: GPUs. O que as empresas que executam treinamento ou inferência de IA devem monitorar além da utilização básica de GPU, e onde uma observabilidade melhor pode se traduzir diretamente em menores custos de infraestrutura de IA?

A utilização de GPU por si só não fornece informações suficientes.

Você pode ver 90 % de utilização em um painel e assumir que tudo está bem. Mas o que você realmente quer saber é: o que a GPU está fazendo?

É preciso analisar mais a fundo. Quais kernels CUDA estão em execução? Como a memória da GPU está sendo alocada? Quanto tempo é gasto movendo memória em vez de realizar computação? A carga de trabalho está usando Tensor Cores quando deveria? A GPU é realmente o gargalo, ou está aguardando dados de outro lugar?

Essas são questões importantes porque as GPUs são caras. Uma pequena ineficiência repetida em centenas ou milhares de GPUs se transforma em uma quantia muito grande de dinheiro.

Por exemplo, se as GPUs estão aguardando porque o pipeline de dados não consegue alimentá‑las rapidamente o suficiente, comprar mais GPUs não resolverá o problema. É necessário encontrar o gargalo. O mesmo vale para a memória. Se as cargas de trabalho alocam memória de forma ineficiente, uma melhor visibilidade pode ajudar os engenheiros a ajustar o tamanho dos lotes ou executar mais cargas de trabalho no mesmo hardware.

É aqui que a observabilidade se torna interessante para a infraestrutura de IA. Não se trata apenas de detectar que algo está quebrado. Ela pode indicar onde você está desperdiçando computação.

Há também um problema de observabilidade criado por todo esse monitoramento. As GPUs podem gerar muita telemetria detalhada e de alta cardinalidade. Se você coletar tudo e enviar diretamente para uma plataforma SaaS cara, pode reduzir seus custos de GPU e então gastar parte da economia armazenando dados de monitoramento. Mas isso não é uma boa otimização.

Com OpenTelemetry e projetos como OpenLIT, podemos obter uma visibilidade muito mais profunda das cargas de trabalho de GPU. Em seguida, com o VictoriaMetrics, podemos agregar os dados, remover dimensões que não são úteis e reter de forma eficiente as informações que os engenheiros realmente precisam.

A pergunta útil não é: “Quão utilizadas estão minhas GPUs?”

É: “Que trabalho útil estou obtendo das GPUs pelas quais estou pagando?”

Uma vez que você possa responder a isso, pode começar a tomar decisões de engenharia e custos melhores.

Os agentes de IA criam desafios de observabilidade muito diferentes dos softwares tradicionais porque uma única solicitação pode acionar chamadas de modelo, uso de ferramentas, consultas a bancos de dados vetoriais, transferências e potencialmente longas cadeias de ações autônomas. Como a observabilidade precisa evoluir à medida que as aplicações corporativas se tornam cada vez mais baseadas em agentes?

A observabilidade tradicional assume que uma solicitação segue um caminho relativamente previsível através da sua infraestrutura. As cargas de trabalho baseadas em agentes não funcionam assim. Um único agente pode chamar um modelo, depois uma ferramenta, depois outro modelo e tentar três vezes antes de retornar algo. Cada uma dessas etapas precisa de sua própria visibilidade.

Os modos de falha também são diferentes. Um serviço tradicional responde corretamente ou não. Um agente pode responder com sucesso e ainda estar errado, lento ou caro, e nada disso aparece como um erro típico em um painel construído para disponibilidade.

O que surpreende as equipes é a cardinalidade. Um fluxo de trabalho de agente único pode gerar métricas vinculadas a um usuário específico, prompt e chamada de ferramenta, e esse volume se acumula rapidamente, especialmente com loops recursivos onde um planejador continua chamando a mesma ferramenta. Qualquer sistema destinado a observar cargas de trabalho baseadas em agentes precisa lidar com essa escala sem que a curva de custo se torne vertical, que é exatamente o problema que estamos resolvendo. Métricas, logs e rastreamentos ainda são os blocos de construção corretos. O que precisa mudar é o volume e o modelo de custo subjacente a eles.

O VictoriaMetrics também tem aplicado aprendizado de máquina e fluxos de trabalho assistidos por IA na detecção de anomalias. Onde você acredita que a IA pode realmente melhorar o monitoramento e a resposta a incidentes hoje, e onde o julgamento humano ainda é difícil de substituir?

É importante manter uma pessoa no processo para gerar ideias, orientar a implementação e validar os resultados. Em outras palavras, nada mudou realmente em comparação com o fluxo de trabalho tradicional. O que mudou é que as capacidades de gerar soluções foram amplificadas. Qualquer pessoa pode criar software agora, mas isso não deve reduzir os critérios de aceitação. Eles devem ser aumentados significativamente.

Onde a IA realmente ajuda é ao destacar o que uma pessoa perderia na confusão, coisas como outliers e tendências que não acionam um limite manual. No VictoriaMetrics, temos uma política interna de IA simples: os funcionários são livres para automatizar seu fluxo de trabalho como quiserem, mas permanecem responsáveis pelo resultado final. Esse é, grosso modo, o mesmo padrão que aplicaríamos à detecção de anomalias no ambiente de produção de um cliente. O modelo pode sinalizar, mas uma pessoa ainda precisa decidir o que isso significa e o que fazer a respeito.

O VictoriaMetrics permaneceu de código aberto e adotou uma abordagem autofinanciada, financiada pelos clientes, em vez de seguir o modelo tradicional de startup de infraestrutura apoiada por venture capital. Como isso influenciou a forma como você desenvolve o produto, o precifica e decide quais tecnologias permanecem de código aberto?

Ser autofinanciado altera a estrutura de incentivos mais do que as pessoas esperam. Sem um conselho exigindo que alcancemos um número de ARR em um trimestre específico, não tivemos que fazer as concessões que geralmente acompanham essa pressão, como comprometer a versão de código aberto para forçar as pessoas a um plano pago, ou mudar a licença como a InfluxDB ou a HashiCorp fizeram quando precisaram proteger a receita de provedores de nuvem. O VictoriaMetrics OSS é Apache 2.0 hoje, e não temos planos de mudar isso.

A forma como decidimos o que permanece open source é simples: o motor central, aquilo que os engenheiros precisam confiar a nós para seus dados de produção, permanece aberto. Cobrançamos pelo que uma empresa precisa quando está operando em escala e necessita de alguém responsável: multitenância, autenticação corporativa, suporte à conformidade, um SLA de CVE e acesso direto aos engenheiros que escreveram o código, em vez de uma fila de suporte. Ser financiado pelos clientes também significa que o roadmap é definido pelo que as pessoas realmente enfrentam em produção, não pelo que é financiável em um pitch deck.

À medida que métricas, logs, rastreamentos, telemetria de aplicações de IA, monitoramento de GPU e detecção automática de anomalias convergem cada vez mais, como você acha que será a pilha de observabilidade nos próximos anos, e o que as equipes de engenharia esperarão das plataformas que desejam permanecer relevantes?

A pilha converge operacionalmente antes de convergir como um único produto, e essa distinção é importante. A maioria das equipes não quer uma plataforma monolítica com uma única interface que bloqueie tudo junto. O que elas desejam são métricas, logs e rastreamentos executando em um único modelo operacional, um único fornecedor e uma única história de licenciamento, sem precisar abrir mão da capacidade de operar cada sinal independentemente, caso seja isso que uma equipe específica necessite. Essa é a direção que a VictoriaMetrics está construindo. Não estamos tentando encaixar tudo em um único binário. Estamos tentando garantir que os três sinais compartilhem o mesmo motor e as mesmas características de eficiência, de modo que adicionar um segundo ou terceiro sinal não signifique adotar uma segunda ou terceira dor de cabeça operacional.

As plataformas que permanecem relevantes são aquelas que conseguem absorver a telemetria de IA e o monitoramento de GPU nesse mesmo modelo sem que a curva de custos se quebre. As cargas de trabalho de IA geram telemetria em um volume para o qual a precificação legada por métrica ou por host nunca foi projetada. As equipes ou deixam de coletar os dados de que precisam ou a conta de observabilidade cresce mais rápido que o investimento em IA que deveria estar monitorando. As equipes de engenharia vão esperar que as plataformas lidem com esse volume da mesma forma que esperam que qualquer infraestrutura escale, sem precisar rearquitetar ou renegociar sempre que a carga de trabalho aumenta.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar VictoriaMetrics.