Seis nós, 6 TB de NVMe, um rack privado — e tudo isso segurava 28 dias de dado. Pra funcionar direito eu precisaria de 18 TB. Eu quebrei o cluster de propósito, e a parte constrangedora é que o erro estava no nome da ferramenta desde o primeiro dia.
Resposta rápida: eu montei um ELK (Filebeat → Logstash → Elasticsearch → Kibana) pra ler o log de saída de todos os POPs do meu CDN e entregar estatística até pro cliente que usa player próprio. Funcionou, e me custou caro: os 6 TB de NVMe guardavam de 28 a 30 dias; o tier seguinte pedia mais 6 TB de SSD; a conta real pra rodar folgado era 18 TB. Cada nó pedia 20 a 24 GB de RAM, eram mais de 300 Filebeats mandando em tempo real, e NVMe tem vida — escrita mata disco, mesmo enterprise. A limitação de armazenamento acabou definindo os meus planos comerciais de retenção. O erro de origem: escolhi um motor de busca pra armazenar e somar evento. Quando eu troquei por pré-processamento em tempo real, o problema morreu. Hoje, pra log, o padrão da casa é Prometheus, Grafana e Loki.
Gravei esses 16 minutos no canal @josimarjmv, publicados em 14 de julho de 2026. Assista e leia junto: aqui embaixo eu abro a conta com mais calma, com o fluxo desenhado e com o que eu fui conferir depois, com fonte e data.
🎧 PREFERE OUVIR? · 16 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar a minha carteirada antes de falar de cluster, porque o assunto atrai muito palpite. Eu sou CEO de uma empresa de tecnologia de verdade e ponho a mão na massa pra valer: eu cuido de infraestrutura real, com operação no Brasil e nos Estados Unidos. Não sou um dos papagaios digitais que a gente tem por aí repetindo o que leu num fórum.
Falo isso porque o que vem aqui embaixo não é benchmark de laboratório. É dinheiro meu, disco meu, prejuízo meu. E é por isso que eu insisto tanto que infraestrutura virou o superpoder de quem faz tecnologia: quem não faz a conta antes de subir o serviço descobre o preço depois, com o cluster de pé e o cliente dentro.
Se você nunca ouviu falar de ELK stack, pausa e pesquisa: é o conjunto Elasticsearch, Logstash, Kibana e Filebeat. É esse ecossistema que eu usei, e é dele que eu vou falar.
Há muito tempo, o nosso sistema de estatística de vídeo era baseado no player. Ou seja: eu só tinha número do usuário que assistia no meu player, igual YouTube, igual várias plataformas. O player mandava uma requisição pra uma API, e a API registrava num cluster MongoDB.
Esse cluster não era muito otimizado, os dados não eram pré-processados e, a partir dali, começava o fluxo de mineração. Chame do nome que quiser — mineração, pós-processamento, enriquecimento. Haja sofrimento. Dava um trabalho do cão, comia espaço em disco, comia memória, e já pedia NVMe pra dar conta.
Aí veio a ideia dentro da empresa — e olha que isso é anterior à onda de inteligência artificial, não tem nada a ver com IA. Vamos botar Elasticsearch. Por quê? Porque assim a gente daria um avanço de verdade: instalar o Filebeat nos nossos POPs de entrega de vídeo, ler o log de saída do CDN e fazer a ingestão no Elasticsearch.
O ganho comercial era claro, e é aqui que mora a beleza da coisa: eu tenho muito cliente emissora de rádio, igreja, TV, gente com aplicativo próprio e com plataforma de ensino própria. Esse cliente não usa o meu player — ele quer o player dele, o recurso dele, o registro de progresso dele. E desses eu perdia a estatística pra oferecer de volta. Eu tinha número de tráfego e de volume, mas era coisa de infraestrutura, dado interno.
Então: subir o Elastic pra passar a entregar dado de todo o CDN, o cliente usando o meu player ou não. Sensacional. Vou gerar um valor absurdo pro meu cliente, e eu já tenho a minha infraestrutura mesmo. Era esse o raciocínio — o mesmo raciocínio que me fez tirar as coisas da nuvem e trazer pra casa. Só que dessa vez a conta não fechou.
A primeira versão foi um cluster de três nós, e eu achei que estava arrebentando. Deu bom não. A gente subiu com SSD — e olha que era SSD enterprise. Trava tudo, cara. Você não acredita não.
E aqui vai a lição que vale pra qualquer serviço, não só pro Elastic: o servidor pode ter CPU boa, kernel atualizado e tunado, memória sobrando. Se o disco ficar lento, trava tudo. É igual à sua máquina com disco ruim. E não adianta argumentar que não é o disco raiz, que é outro SATA, outra partição, outra formatação: disco saturado deixa a máquina inteira lenta, começa a gerar fila, e o resto vai junto.
Só estabilizou quando a gente migrou pro NVMe. Aí sim ficou certinho, foi show de bola. Colocamos mais nós pra ter mais espaço em disco — os seis servidores num rack privado, cada um com NVMe de 1 TB, plaquinha de rede local conversando entre eles pro cluster sincronizar.
Quem trabalha com Elastic sabe: ele é um comedor de I/O e de memória. Tem a otimização de shard — quantos shards, quantos gigas em cada, quantas réplicas pra que a queda de um nó não leve o dado embora. Ele é distribuído: quando eu subo um documento, ele espalha nas réplicas configuradas, porque NVMe morre, e morre rápido com escrita, mesmo o enterprise. Se um disco vai embora, o cluster redistribui. É a mesma lógica de distribuição de objeto que eu já expliquei quando falei de Ceph, guardadas as proporções.
Não vou entrar em ILM, política de limpeza, ingestão e enriquecimento, que dá um curso inteiro. Eu quero é te mostrar o número que doeu: 6 TB de dado davam pra guardar 28 a 30 dias. Só.
E antes que você me diga que dá pra economizar: dá, e eu economizei. O Elastic guarda o documento, então quanto menos campo você armazena, mais dia cabe. Tirei o referer, que eu não precisava. Mas o IP do acesso eu precisava manter pra fazer a geolocalização da estatística — esse não tinha como tirar. Você vai raspando o que dá, e mesmo assim a média foi essa.
Aí entra a política de tier: depois de 30 dias, mover o dado pro warm, que no meu caso seria SSD. Ou seja, mais 6 TB. Por que não jogar tudo em disco lento e pronto? Porque o cliente quer ver a estatística dos últimos 30 dias rápido. Se você bota o índice num disco lento e o cara pede um relatório de milhões de acessos do mês, vai ficar rodando a bolinha. No fritar dos ovos, eu precisava de no mínimo 18 TB pra esse negócio funcionar bem.
Some a memória: cada nozinho do Elastic pede 20, 24 GB de RAM pra trabalhar folgado, com todos os workers. E eu não gosto de processamento lento: pra acompanhar os mais de 300 Filebeats em tempo real, ingerindo tudo. Se acontece alguma coisa agora, eu quero ver o log em 10 minutos, não daqui a dois dias — senão ele atropela, e depois você tem que voltar e reprocessar pra ver o que ficou pra trás.
Essa é a parte que quase ninguém conta, e é a que mais interessa pra quem tem empresa: a limitação de disco virou regra de negócio. A gente mudou o modelo: nos planos de stream pré-pagos, a estatística passou a ser de até 30 dias; nos planos enterprise, a gente entregava mais, até um ano, de acordo com o contrato.
Olha o tamanho disso. Uma decisão de infraestrutura impactou o meu modelo de negócio e ficou caro pra caramba pra sustentar. E o cold tier eu nem cheguei a usar, porque poucos clientes queriam manter estatística de 12 meses — não chegava a 300 clientes naquela época, e pra esse punhado não valia a estrutura.
É o mesmo tipo de armadilha que eu já descrevi quando contei por que eu parei de pagar VM na nuvem e montei o meu Proxmox: o preço não aparece na fatura do primeiro mês, aparece quando o volume cresce e você já prometeu o recurso pro cliente.
Agora a parte constrangedora, e eu prefiro falar do que fingir. A gente estava usando errado. O nome do bicho é Elastic SEARCH. Por que cargas d'água eu comecei a usar ele pra registro de estatística de evento?
Ele é maravilhoso pra busca. Troço sensacional pra busca. Só que eu precisava de armazenamento de evento e soma — e pra isso existe tecnologia muito melhor, com pré-processamento pra você não salvar tudo cru e minerar depois, que era exatamente o vício que eu já tinha no tempo do Mongo. Quando eu passei a pré-processar em tempo real, o problema se resolveu.
E olha, não foi de maldade dele, não: resolveu o nosso problema por um bom tempo. Foi bom enquanto durou. Só custou caro demais pro que entregava. É o tipo de decisão que eu só aprendi a tomar melhor depois de me queimar escolhendo ferramenta pela fama e não pelo problema.
Então a gente quebrou o cluster de propósito e parou de usar. Hoje eu não uso Elastic nem pra busca, e admito: é trauma de custo. Cheguei a pensar em jogar o log das aplicações nele e a conta não fechava de jeito nenhum.
Pra gestão de log e observabilidade, o padrão da casa hoje é Prometheus, Grafana e Loki. O Kibana é legal, viu — você monta gráfico ali fácil, é bem bacana de mexer. Hoje muita gente está usando Metabase, que é rápido e fácil, e tem o Grafana pro lado de log. Tem variante pra todo gosto.
O que eu uso hoje no lugar do pipeline de estatística eu não abri na gravação — deixei como pauta de outro vídeo. E eu não vou inventar aqui só pra fechar bonito o texto: quando eu contar, eu conto com o desenho todo, do jeito que eu contei o dia dos 30 GB de log pra achar um bug.
Eu falei de cabeça na gravação, então fui conferir depois pra te entregar com fonte. Checagem feita em 23/09/2026.
Esse caso do cluster é de anos atrás — bem antes da onda de inteligência artificial — e eu contei ele na gravação de 14 de julho de 2026. De lá pra cá o Elastic mudou, ganhou tier novo e recurso de snapshot pesquisável, e o preço de NVMe caiu. Não leia isto como "Elasticsearch é ruim": ele continua sendo excelente no que ele faz. Leia como o método, que não envelhece: faça a conta de disco e de memória antes, e escolha a ferramenta pelo problema, não pela reputação dela. E, como eu já disse quando falei que o gargalo mudou de lugar no meu pipeline, o que mata a operação quase nunca é a parte que parece difícil.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Se você quer aprender os nossos perrengues e montar uma infraestrutura sem passar o que eu passei — qual placa comprar, servidor de primeira ou de segunda mão, cabo DAC, switch, VLAN, VPN, cluster, virtualização, pipeline, redundância de DNS e de proxy em todas as camadas —, é isso que eu vou ministrar na imersão de infraestrutura: presencial em São Paulo, três dias, com os cenários reais e a maldade que ninguém te conta. Eu paguei caro, em dinheiro e em raiva, pra aprender esse negócio e nunca mais ficar refém de ninguém. Valor, data e condição ficam na página da imersão, que é onde essa informação é mantida atualizada.
Baseado na gravação do canal @josimarjmv publicada em 14/07/2026 (16min10), com transcrição própria das legendas do próprio vídeo. São da minha vivência e foram ditos na gravação: ser CEO de uma empresa de tecnologia botando a mão na massa, com infraestrutura no Brasil e nos Estados Unidos; a estatística antiga baseada no player próprio, registrada num cluster MongoDB pouco otimizado, sem pré-processamento, com mineração e enriquecimento posteriores pesando disco e memória; a decisão de instalar Filebeat nos POPs de entrega de vídeo para ler o log de saída do CDN e fazer ingestão no Elasticsearch, motivada pelos clientes de rádio, igreja e TV que usam aplicativo e plataforma de ensino próprios; o primeiro cluster de três nós subido com SSD, que travava, e a estabilização depois da migração para NVMe; os seis servidores em rack privado com NVMe de 1 TB cada e rede local; o Elastic como comedor de I/O e memória, a configuração de shards e réplicas, e o fato de NVMe morrer rápido com escrita mesmo em versão enterprise; os 6 TB segurando de 28 a 30 dias, a remoção do referer e a manutenção do IP para geolocalização, a política de tier movendo para SSD depois de 30 dias e a necessidade real de 18 TB; os 20 a 24 GB de RAM por nó e os mais de 300 Filebeats em tempo real; a mudança do modelo comercial, com 30 dias de estatística nos planos pré-pagos e até um ano nos enterprise; o cold tier não utilizado por não chegar a 300 clientes interessados em 12 meses; a admissão de que usar um motor de busca para registro de evento foi erro de origem, resolvido depois com pré-processamento em tempo real; a quebra proposital do cluster; e o padrão atual de Prometheus, Grafana e Loki para log, com menção a Kibana e Metabase. É apuração minha, feita em 23/09/2026, e não estava na gravação: a recomendação de shards entre 10 GB e 50 GB e até 200 milhões de documentos por shard; a definição oficial dos data tiers hot, warm, cold e frozen, incluindo a redução de cerca de 50% de disco no cold e o frozen até 20 vezes mais barato que o warm; e a explicação do Grafana Loki sobre indexar apenas labels e guardar os blocos comprimidos em armazenamento de objeto. Ressalva: eu cito a minha imersão de infraestrutura na gravação, com faixa de valor e número de vagas; como preço, data e condição são finais e mudam a cada turma, aqui eu não repito nenhum desses números e mando pra página da imersão. O que eu uso hoje no lugar do pipeline de estatística não foi dito na gravação e, por isso, não está afirmado aqui.