Sistemas de dados
    Atualizado maio de 2026
    Apache Kafka logo

    Apache Kafka Monitorização

    Monitorize o estado dos brokers do Apache Kafka, o atraso nas partições, os grupos de consumidores e o débito em tempo real, sem necessidade de configuração.

    Iniciar período de avaliação gratuitaVer documentos

    Por que monitorizar Apache Kafka?

    O Apache Kafka é a espinha dorsal dos fluxos de dados em tempo real e da transmissão de eventos. A monitorização do Kafka garante o bom funcionamento dos clusters de brokers, um atraso mínimo nos consumidores, uma distribuição ideal das partições e uma entrega fiável das mensagens.

    Deteção automática via Xitogent
    Acompanhamento da saúde dos brokers e do ISR
    Monitorização do lag de consumer groups
    Métricas de distribuição de partições
    Taxas de throughput de mensagens
    Utilização de disco por broker
    Métricas ao nível do topic
    Intervalos de recolha de 1 minuto
    Limiares de alerta personalizáveis para cada métrica
    Intervalos de recolha de métricas de 1 minuto, prontos a usar
    O que é a monitorização do Kafka?

    Monitorização do Kafka, explicada

    A monitorização do Kafka deteta partições sub-replicadas, partições offline, picos de lag em consumer groups, contrações de ISR, falhas de controlador e pressão de disco antes que causem perda de dados, falhas em microsserviços a jusante ou falhas totais de brokers. Para pipelines de CDC, sistemas de event sourcing, eventing de microsserviços e qualquer cluster Kafka em produção, a visibilidade por broker + por consumer group é o que separa um alerta em 60 segundos sobre um consumidor atrasado de encontrar um backlog de 50 milhões de mensagens ao fim do dia. O Xitoring descobre automaticamente os seus brokers, lê MBeans JMX + offsets de consumidores, e encaminha alertas para Slack, PagerDuty, Telegram ou para a sua equipa de plantão existente.

    Métricas

    O que monitorizamos

    Número de brokers

    Brokers ativos no cluster.

    Lag dos consumidores

    Mensagens em atraso para cada consumer group.

    Mensagens recebidas/s

    Taxa de ingestão de mensagens.

    Bytes recebidos/enviados

    Throughput de rede por broker.

    Partições sub-replicadas

    Partições abaixo do fator de replicação.

    Reduções de ISR

    Eventos de shrink de réplicas em sincronia.

    UncleanLeaderElectionsPerSec

    Taxa de réplicas fora de sincronia a serem promovidas a líder (com perda de dados). Deve ser 0 — diferente de zero significa que `unclean.leader.election.enable=true` E ocorreu um evento de falha real.

    MessagesInPerSec / BytesIn / BytesOut

    Débito por broker e por tópico. Quedas súbitas com contagem de produtores estável = problema de ingestão; picos súbitos = tempestade de retries ou produtor descontrolado.

    Latência de pedidos (p99)

    p99 do tempo de processamento de pedidos Produce, Fetch, Metadata em `kafka.network:type=RequestMetrics`. Apanha sobrecarga do broker antes que cause timeouts nos clientes.

    LeaderCount por broker

    Líderes de partição por broker. Distribuição desigual (um broker a deter 60%+ dos líderes) = cluster desequilibrado, corrija com `kafka-reassign-partitions.sh` ou.

    Tamanho do log por tópico

    Tamanho agregado do log em disco por tópico a partir de `kafka.log:type=Log,name=Size`. Alimenta alertas de espaço em disco e informa políticas de tiered storage no Kafka 3.8+.

    RemoteLogManager (tiered storage)

    Métricas de tiered storage do Kafka 3.8+: bytes carregados para o tier remoto, segmentos em remoto vs local, latência de fetch a partir do remoto. Apanha problemas de conectividade S3 / IAM que quebram fetches em tier remoto.

    Alerta e notificação

    Configurável condições de alerta

    Configure alertas personalizados no seu painel para ser notificado assim que as métricas dApache Kafka ultrapassarem os limites que definiu.

    Apache Kafka painel de controlo da configuração dos gatilhos de monitorização

    Lag dos consumidores

    crítico

    Dispara quando um consumidor fica para trás.

    Partições sub-replicadas

    crítico

    Alerta sobre problemas de replicação.

    Broker em baixo

    crítico

    Dispara quando um broker abandona o cluster.

    Utilização de disco

    aviso

    Dispara quando o disco do broker está a encher.

    01

    Importância da monitorização do Kafka

    O Kafka processa biliões de mensagens diariamente. Lag dos consumidores, falhas de brokers e desequilíbrio de partições podem causar falhas em pipelines de dados.

    • Detete o lag dos consumidores antes da perda de dados
    • Monitorize o ISR para a durabilidade dos dados
    • Acompanhe a saúde dos brokers entre clusters
    • Garanta o equilíbrio das partições
    Monitorização do Kafka
    Analítica de partições
    02

    Porquê escolher Xitoring

    Monitorização Kafka de nível empresarial.

    • Configuração zero-config
    • Nós globais
    • Dashboard unificado
    • Alertas multicanal
    • Retenção histórica
    Visão geral
    Alertas
    Casos de uso

    Cenários comuns de monitorização do Kafka

    Onde o Kafka normalmente é executado hoje — e o que pode correr mal se ninguém estiver a monitorizar.

    A espinha dorsal de mensagens que conecta as suas aplicações

    Quando o Kafka transporta as mensagens que movem dados entre as suas aplicações, qualquer lentidão significa que uma aplicação está silenciosamente a ficar para trás — e as consequências (atualizações atrasadas, dados desatualizados, fluxos de trabalho quebrados) só aparecem mais tarde. Detetamos o atraso no momento em que começa para que nunca se torne um problema visível para o cliente.

    Kafka a correr dentro do Kubernetes

    Quando o Kafka corre no Kubernetes, a plataforma move-o constantemente — e um reinício de rotina pode enfraquecer brevemente a rede de segurança que mantém os seus dados protegidos. Monitorizamos cada reinício e reequilíbrio para que uma atualização normal não possa silenciosamente deixar o sistema a uma falha de distância da perda de dados.

    Kafka autogerido para dados de alto volume

    Empresas que executam o seu próprio Kafka em escala precisam que ele seja sólido como uma rocha — geralmente está a transportar os dados mais valiosos que possuem. Monitorizamos os sinais que o mantêm saudável para que a equipa possa focar-se na construção de produtos em vez de combater incêndios na camada de mensagens.

    Antes de começar

    Pré-requisitos para Apache Kafka

    Certifique-se de que tem tudo isto pronto — depois disso, a maioria das instalações leva 60 segundos.

    • Brokers Kafka com JMX ativado (porta predefinida 9999)
    • Acessibilidade de rede do Xitogent à porta JMX de cada broker
    • Credenciais de autenticação JMX se a segurança estiver configurada
    Guia de configuração

    Comece a minutos

    1

    Instalar o Xitogent em cada broker

    Instale o leve agente de monitorização Xitogent em cada broker Kafka que pretende monitorizar.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Ativar JMX em cada broker

    O Kafka expõe métricas de broker através de JMX. Defina `KAFKA_JMX_OPTS` para ativar um listener JMX (tipicamente porta 9999) em cada broker, recarregue o serviço e confirme que o host do agente consegue ligar-se à porta JMX.

    sudo xitogent integrate
    3

    Ativar a integração do Kafka

    Use o painel do Xitoring ou a CLI para ativar a integração do Kafka. O Xitogent descobre automaticamente os IDs dos brokers, tópicos e consumer groups no cluster.

    4

    Configurar limiares de alerta (opcional)

    Defina limiares personalizados para Consumer Lag, partições sub-replicadas ou eventos Broker Down para apanhar problemas de replicação e back-pressure antes que os consumers fiquem atrasados.

    5

    Confirme que está a funcionar

    Execute este comando no servidor para confirmar que o Xitogent detetou a integração. Em cerca de 30 segundos começam a chegar novas métricas ao seu painel.

    sudo xitogent status
    Comparar

    Está a considerar alternativas?

    Veja como o Xitoring se compara às alternativas para a monitorização de Apache Kafka — preços fixos, integrações mais profundas e um único agente que cobre toda a sua stack.

    Ver todas as comparações

    Frequentemente perguntas feitas

    Versões de Kafka?
    São suportadas as versões 2.x e 3.x do Kafka.
    ZooKeeper ou KRaft?
    Ambos os modos são suportados.
    O que são partições sub-replicadas e como as corrijo?
    As partições sub-replicadas têm menos ISRs (in-sync replicas) do que o fator de replicação — normalmente porque um broker está morto, atrasado ou a reiniciar. Execute `kafka-topics.sh --describe --under-replicated-partitions` para as listar. Corrija o broker subjacente e o ISR recupera automaticamente. Se um broker estiver permanentemente perdido, use `kafka-reassign-partitions.sh` para mover réplicas para brokers sobreviventes. UnderReplicatedPartitions > 0 sustentado = chamar a equipa de plantão.
    Como monitorizo as métricas JMX dos brokers Kafka com Prometheus?
    Padrão habitual: implemente o prometheus como agente Java da JVM em cada broker (`-javaagent:jmx_prometheus_javaagent.jar=8080:kafka-config.yml`), e o Prometheus faz scraping do endpoint `/metrics` do exportador. O `kafka-config.yml` define a whitelist de mapeamento MBean → métrica. O Xitogent lê JMX diretamente sem o exportador, mas é compatível com ambientes que já o executam para dashboards Grafana.
    O que é o modo KRaft e como muda a monitorização sem ZooKeeper?
    O KRaft (Kafka Raft) substitui o ZooKeeper por um quórum de controladores interno baseado em Raft (predefinição desde o Kafka 3.3, única opção na 4.0). Mudanças na monitorização: sem métricas do ensemble ZK; em vez disso, vigie o quórum de controladores (3 ou 5 brokers correm como controladores), os MBeans `kafka.controller:type=KafkaController` e `kafka.server:type=raft-metrics`. A semântica de `ActiveControllerCount` é a mesma (deve ser exatamente 1 líder ativo).
    Como deteto partições offline no Kafka?
    `kafka.controller:type=KafkaController,name=OfflinePartitionsCount` — deve ser 0. Qualquer valor diferente de zero = dados indisponíveis tanto para leitura como para escrita. Combinado com `UncleanLeaderElectionsPerSec > 0` = o cluster perdeu dados por ter promovido uma réplica fora de sincronia. Liste as partições afetadas via `kafka-topics.sh --describe --unavailable-partitions`.
    Como monitorizo um cluster Kafka em Kubernetes (Strimzi)?
    O operador Strimzi ativa JMX em cada broker por omissão na porta `:9999`. Instale o Xitogent num nó K8s com acesso de rede aos pods dos brokers, ou implemente como DaemonSet que se liga ao endpoint JMX de cada pod via DNS de Service. Vigie eventos de rolling updates orientadas pelo operador (visíveis como contrações de ISR) e delimite a janela de alerta para que atualizações rotineiras não chamem a equipa de plantão. A utilização de disco por pod em relação ao limiar de tiered storage também importa aqui.
    Monitorização de Kafka vs Redpanda — quais são as diferenças?
    O Redpanda é compatível ao nível de wire com a API Kafka e expõe métricas equivalentes, mas via Prometheus diretamente (sem JMX — o Redpanda é em C++, não em JVM). Mesma semântica de métricas (UnderReplicatedPartitions, ConsumerLag, etc.), mas transporte diferente. O Xitogent funciona com ambos — caminho JMX para Apache Kafka / Confluent / Strimzi, caminho Prometheus para Redpanda. O conjunto de alertas de saúde do cluster é idêntico.
    Que versões do Kafka são suportadas?
    Kafka 3.x (a 3.8 adicionou tiered storage GA via KIP-405), Kafka 4.0 (KRaft obrigatório, sem ZooKeeper), Kafka 4.1 (protocolo de rebalance de consumidores de nova geração KIP-848 com coordenador do lado do servidor). A 2.x mais antiga funciona, mas não tem KRaft nem tiered storage. Confluent Platform 7.x / 8.x e Redpanda são compatíveis através da API Kafka partilhada.

    Comece a monitorizar Apache Kafka hoje

    Configure em menos de 60 segundos. Não é necessário cartão de crédito. Estatísticas completas desde o primeiro dia.

    Iniciar período de avaliação gratuita

    Continue a explorar

    Relacionado Integrações