Configurando um ambiente Kafka real, longe da documentação oficial
A primeira coisa que você aprende é que o o processo kafka não começa com um tar.gz; começa com a sua necessidade de latência e a capacidade operacional que você tem para manter os logs limpos. A instalação padrão do ZooKeeper (ou KRaft, se você for moderno e corajoso) é só o começo. O trabalho real está em entender como o broker escolhe a partição para um producer e como o consumer group reage quando um nó cai durante um rebalanceamento. Eu passei três dias tentando diagnosticar por que offsets não avançavam em um cluster de teste. Descobri que o tema tinha apenas uma partição e um consumer que processava mensagens síncronas de forma extremante lenta, travando todo o grupo. A solução foi aumentar o número de partições para corresponder ao máximo de consumers paralelos e mudar a configuração max.poll.interval.ms para algo maior que o tempo de processamento da sua lógica de negócio.
👉 Clique no botão abaixo para saber mais sobre o assunto!
o processo kafka na prática de produção
A maioria dos tutoriais mostra um comando kafka-console-producer.sh e chama de tutorial completo. Isso é útil para confirmar que o serviço está no ar, mas não ensina nada sobre a gestão de estado. No mundo real, o processo gira em torno de garantir a durabilidade (acks=all), a ordenação dentro da partição e o manejo do replay de mensagens quando um consumer falha. Um detalhe técnico que poucos mencionam: o parâmetro min.insync.replicas deve ser sempre menor que o replication.factor para evitar que o cluster pare de aceitar escritas na menor falha de nó. Se você configurar igual, uma única instância caindo vai derrubar a disponibilidade de escrita do seu tópico inteiro. O download e a extração dos binários é trivial, mas o custo oculto está na configuração de rede. Você precisa definir corretamente o advertised.listeners. Se você colocar apenas o hostname interno, consumidores externos não conseguirão conectar. Coloquei o IP interno de um container e perdi duas horas tentando entender por que o broker retornava um endereço inalcançável para o cliente. Ajustar esse campo para o IP que é roteável a partir da máquina que está rodando o consumer resolveu o problema imediatamente.
Sobre a parte operacional, você terá que lidar com o crescimento descontrolado de logs. O Kafka não expira dados por padrão da forma mais eficiente para todos os casos. Definir log.retention.hours ou log.retention.bytes no nível do tópico é obrigatório se você não quiser que seu disco encha e o broker entre em modo read-only de emergência. Em um ambiente que processei recentemente, um tópico de auditoria com retenção de 30 dias e alta taxa de produção ocupava 4TB em pouco tempo. Ativamos a compactação por chave (cleanup.policy=compact) e reduzimos a retenção para eventos críticos, o que cortou o uso de disco em cerca de 70%. A monitoração é outro ponto onde a simplicidade inicial engana. O JMX é a fonte primária de dados, mas extrair métricas como UnderReplicatedPartitions ou FailedFetchRequests requer um collector configurado. Se isso ficar invisível, você só saberá que algo está errado quando o consumer apresentar um lag crescente e mensagens perdidas para o seu sistema de destino. Configurei o Kafka Exporter para expor isso em Prometheus e defini alertas para partição sem réplica ativa; isso me avisava antes que a perda de dados se tornasse uma situação crítica.
