Para a maioria da última década, observabilidade tinha um segredo incômodo: a restrição principal no que você conseguia observar não era técnica mas financeira. Equipes rodavam clusters Elasticsearch cuja contas de armazenamento cresciam mais rápido que seu tráfego, e a resposta padrão era jogar dados fora — corte retenção de noventa dias para sete, amostra logs em dez por cento, jogue saída debug inteiramente. Então inevitavelmente um incidente pousaria na lacuna. Os dados que teria explicado tinha sido descartado para economizar dinheiro, e o item de ação postmortem lia "aumentar retenção de log," que ninguém financiava.
A economia mudou porque uma nova geração de ferramentas moveu armazenamento de log de discos locais caros para object storage barato — S3, GCS, Azure Blob. Quando armazenamento custa uma ordem de magnitude menos, retenção para de ser uma negociação de orçamento. Este guia cobre essa mudança: por que a arquitetura antiga era cara, como o modelo object-storage funciona, e as ferramentas que o implementam — Quickwit para retenção pesquisável de log e trace, OpenObserve como plataforma de observabilidade completa, e Vector como o pipeline que as alimenta.
Por que a arquitetura antiga era cara
Elasticsearch e as stacks construídas nele foram projetadas para um caso de uso exigente: busca de texto completo interativa sobre dados que mudam, com resultados em milissegundos. Para entregar isto, eles mantêm índices em discos locais rápidos anexados a nós sempre-rodando, replicam cada shard para durabilidade e disponibilidade, e mantêm estruturas de índice substanciais em memória. Cada uma daquelas escolhas é razoável para busca, e cada uma é cara.
Os custos se combinam de formas que surpreendem equipes. Armazenamento é provisionado em vez de consumido — você paga pelos discos whether estão cheios ou não, e você sobre-provisiona porque ficar sem é uma outage. Replicação multiplica isto por dois ou três. Os nós devem rodar continuamente even though a maioria de logs nunca é lida depois do dia em que foram escritos. E escalar é acoplado: precisando de mais armazenamento significa adicionar nós, que significa pagar por CPU e RAM que você não precisa. O resultado é uma curva de custo que sobe abruptamente com retenção, que é exatamente por que "reduzir retenção" ficou o lever de controle de custo padrão.
O mismatch mais profundo é que logs não são a carga de trabalho que Elasticsearch foi otimizado para. Dados de log são apenas append — escritos uma vez, nunca atualizados. É overwhelmingly frio: a vasta maioria nunca é consultada, e a pequena fração que é fica consultada durante um incidente, onde alguns segundos de latência é perfeitamente aceitável. Pagar por busca interativa de milissegundo e maquinaria de documento mutável em petabytes de dados write-once que ninguém lê é o erro arquitetural debaixo da conta.
O modelo object-storage
A arquitetura mais nova começa daquelas propriedades. Se dados é append-only e mostly frio, armazene em object storage — que é roughly uma ordem de magnitude mais barato por terabyte que block storage provisionado, é efetivamente infinito, e é durável por padrão sem você gerenciar replicação. Depois desacople computação de armazenamento: rode nós de consulta que leem de object storage on-demand, e escale-os independentemente de quantos dados você retém. Armazenar mais um ano de logs custa armazenamento apenas, não mais nós.
O catch é claro que object storage é lento relativo a disco local — cada leitura é uma solicitação de rede com latência significativa. O insight de engenharia que torna isto funcionar é que você consegue compensar com formato e indexação. Dados são escritos em formatos colunares comprimidos (Parquet é comum) ao lado de estruturas de índice que deixam uma consulta buscar apenas os intervalos de byte que realmente precisa, em vez de scanear tudo. Caching agressivo mantém dados quentes próximos. O resultado é consultas que retornam em segundos em vez de milissegundos — um trade-off que é completamente aceitável para busca de log e completamente inaceitável para uma search box virada ao usuário, que é precisamente por que esta arquitetura se adequa observabilidade e não busca geral.
O que isto compra, beyond dinheiro, é uma mudança em comportamento. Quando retenção é barata, você para de pre-emptively descartar dados, o que significa a resposta ao próximo incidente é mais provavelmente ainda existir. Aquele é o payoff real: não uma invoice menor, mas investigações menos que dead-end porque a evidência foi deletada.
Quickwit: busca construída para logs e traces
Quickwit é a expressão mais pura da ideia. É um mecanismo de busca Rust projetado de start para dados append-only em object storage — precisa sem disco local para índices e sem maquinaria de estado de cluster por elas, porque o índice vive em S3 como splits imutáveis. Fornece busca de texto completo genuína (não só filtragem baseada em rótulo), expõe uma API de busca compatível com Elasticsearch que facilita migração, e serve como backend nativo Jaeger para traces, que o torna um fit natural para equipes já rodando OpenTelemetry.
O sweet spot de Quickwit é armazenamento barato, pesquisável, long-retention para logs e traces onde você quer capacidade de busca real. Gerenciamento de retenção fica trivial — expirar dados antigos é apenas deletar splits antigos. Seu trade-off é escopo: é um mecanismo de busca, não uma plataforma de observabilidade completa, então você traz seus próprios dashboards (Grafana), sua própria alerting, e sua própria stack de métricas. Para equipes que já têm aqueles pedaços e querem fixar o custo de armazenamento especificamente, aquele foco é uma feature.
OpenObserve: a plataforma batteries-included
OpenObserve toma o mesmo insight de armazenamento e embrulha uma plataforma completa em volta dele. Ele manipula logs, métricas, e traces em um sistema, armazena dados como Parquet comprimido em object storage, e é enviado com uma UI integrada, queries SQL, dashboards, e um motor de alerting — tudo como um binário Rust único que é genuinamente fácil de levantar. Ingere OpenTelemetry nativamente e suporta Prometheus remote write, então encaixa em instrumentação existente.
O apelo é consolidação. Em vez de rodar um mecanismo de busca plus Grafana plus uma stack de alerting plus armazenamento de métricas separado, você roda uma coisa. Para equipes pequenas e médias especialmente, a economia operacional consegue importar mais que qualquer comparação per-terabyte — cada componente adicional em uma stack de observabilidade é algo para fazer upgrade, securizar, e debugar às 3 da manhã. Seu trade-off é o usual para plataformas integradas: menos flexibilidade que montar componentes best-of-breed, e um ecossistema mais jovem que o Grafana ou mundos Elastic. Escolha isto quando simplicidade operacional é digna mais que modularidade.
Vector: o pipeline que torna migração segura
Nenhum backend importa se você não consegue colocar dados nele, e isto é onde Vector fica o pivot silencioso. Vector é um pipeline de alto-desempenho, agnóstico de fornecedor: coleta logs, métricas, e traces de qualquer origem, os reformula através de transformações escritas em VRL, e os entrega para qualquer destino. Escrito em Rust, usa uma fração de recursos de Logstash ou Fluentd — que importa porque um agente roda em cada nó que você possui.
Seu valor estratégico é que desacopla sua instrumentação de seu backend. Aplicações e agentes enviam dados para Vector; Vector decide para onde vai. Isto transforma uma migração de backend de um projeto de re-instrumentação em toda-frota em uma mudança de config — e crucialmente, deixa você dual-write durante uma transição, enviando os mesmos dados para sua stack existente e nova então consegue validar a substituição em tráfego real antes de cortar. Transformações de Vector também cortam custo na fonte: dropar logs debug, amostrar eventos de alto-volume, e redactar PII antes do armazenamento tudo reduz o que você paga para manter. Até equipes sem intenção de mudar backends frequentemente acham Vector paga por si apenas em redução de volume.
Adotando isto sem uma migração arriscada
O caminho sensato é incremental, e Vector é o que torna isto seguro. Comece colocando um pipeline na frente de sua stack existente. Implante Vector, aponte suas origens nela, e deixe-a encaminhar para o que você roda hoje. Nada muda funcionalmente, mas você ganhou um ponto de controle — e consegue imediatamente usar transformações para dropar ruído e cortar custos atuais.
Depois dual-write para um backend candidato. Adicione um segundo sink apontando em Quickwit ou OpenObserve e deixe dados de produção real fluirem para ambos. Agora consegue avaliar honestamente: as queries que você realmente roda são rápidas o bastante? A sintaxe de busca cobre suas necessidades? Que armazenamento realmente custa em seu volume? Isto é uma base muito melhor para uma decisão que um benchmark, e custa apenas armazenamento do novo backend durante a prova.
Mude retenção antes de mudar consultanting primária. Um estado intermediário de baixo-risco é manter dados hot de curta-retenção onde está enquanto envia dados de long-retention para object storage. Você pega o ganho de custo na parte cara (long retention) sem apostar sua incident response em um sistema desconhecido. Depois mude consultanting gradualmente, começando com análise não-urgente e movendo para incident response uma vez a equipe confia nisto. E mantenha a stack antiga rodando até que você tenha passado por um incidente real na nova — o momento que descobre se funciona é o momento que menos quer uma surpresa.
O que você abre mão, honestamente
Cada arquitetura troca algo, e vale ser explícito sobre o que mover para object storage custa para que a decisão seja informada em vez de entusiasta.
Latência de consulta. Leituras de object storage são solicitações de rede, então queries retornam em segundos em vez de respostas sub-segundo que um índice warm de disco local consegue entregar. Para busca de log durante um incidente isto é genuinamente fine — você está lendo resultados, não digitando ahead. Mas se você construiu workflows que dependem de filtragem interativa instantânea, ou dashboards que disparam dúzias de queries em cada refresh, eles se sentirão mais lentos. Teste seus padrões de query reais, não um benchmark sintético.
Maturidade de ecossistema. Elasticsearch tem uma década de integrações acumuladas, tutoriais, respostas Stack Overflow e engenheiros que já o conhecem. As ferramentas mais novas têm comunidades menores, documentação mais fina para casos extremos, e menos pessoas você consegue contratar que rodaram elas em escala. Quando algo quebra em uma hora incômoda, aquela diferença é real. APIs compatíveis com Elasticsearch amortizam a migração mas não eliminam a lacuna de conhecimento.
Superfície de feature. Elasticsearch faz muito além de busca de log — agregações complexas, trabalhos machine-learning, relevance tuning, uma linguagem de query rica. Mecanismos de log propositalmente construídos fazem deliberadamente menos. Se você depende daquelas capacidades, verifique equivalentes existem antes de se comproometer em vez de descobrir a lacuna mid-migração.
Familiaridade operacional. Seus runbooks, alertas e instintos são calibrados para sua stack atual. Um novo backend significa novos modos de falha e um período onde a equipe é mais lenta diagnosticando seus problemas. Este é o argumento mais forte para a abordagem dual-write e por manter a stack antiga rodando através de pelo menos um incidente real — você quer a curva de aprendizado acontecer enquanto você ainda tem um fallback.
Nenhum desses supera uma redução de custo uma ordem de magnitude para a maioria de equipes, particularmente aquelas atualmente deletando dados que desejariam ter. Mas eles são a razão para migrar deliberadamente em vez de tudo de uma vez.
A linha de fundo
Observabilidade ficou dramaticamente mais barato porque as ferramentas finalmente combinam a carga de trabalho. Logs são append-only e mostly frio, então armazenar eles em replicated, always-on disco locais otimizados para busca mutável de milissegundo era pagar um prêmio grande por propriedades que os dados não precisa. Mover para object storage com formatos colunares e indexação inteligente troca milissegundos por segundos — irrelevante para busca de log — e corta custo de armazenamento uma ordem de magnitude. Quickwit entrega isto como um log focado e loja de trace pesquisável com um backend Jaeger; OpenObserve entrega isto como uma plataforma consolidada com UI, dashboards e alerting construído; e Vector é o pipeline que desacopla sua instrumentação de qualquer um, tornando adoção uma mudança de config e dual-write em vez de migração. Coloque o pipeline na frente primeiro, dual-write para avaliar em tráfego real, mude long retention antes de hot querying, e pare de deletar os dados que explicam seus incidentes.
Referências e Recursos
Ferramentas
Background e análise
1337skills cheatsheets relacionados