Sistemi informatici
    Aggiornato il maggio 2026
    Apache Kafka logo

    Apache Kafka Monitoraggio

    Monitora in tempo reale lo stato dei broker Apache Kafka, il ritardo delle partizioni, i gruppi di consumer e la velocità di trasmissione senza alcuna configurazione.

    Perché monitorare Apache Kafka?

    Apache Kafka è la colonna portante delle pipeline di dati in tempo reale e dello streaming di eventi. Il monitoraggio di Kafka garantisce il corretto funzionamento dei cluster di broker, un ritardo minimo dei consumer, una distribuzione ottimale delle partizioni e una consegna affidabile dei messaggi.

    Rilevamento automatico tramite Xitogent
    Monitoraggio della salute dei broker e dell'ISR
    Monitoraggio del lag dei consumer group
    Metriche di distribuzione delle partizioni
    Tassi di throughput dei messaggi
    Utilizzo disco per broker
    Metriche a livello di topic
    Intervalli di raccolta di 1 minuto
    Soglie di allerta personalizzabili per ogni metrica
    Intervalli di raccolta metriche di 1 minuto preimpostati
    Che cos'è il monitoraggio di Kafka?

    Monitoraggio di Kafka, in breve

    Il monitoraggio di Kafka intercetta partizioni sotto-replicate, partizioni offline, picchi di lag dei consumer group, restringimenti dell'ISR, fallimenti del controller e pressione sul disco prima che provochino perdita di dati, fallimenti di microservizi a valle o interruzioni complete dei broker. Per pipeline CDC, sistemi di event sourcing, eventistica tra microservizi e qualsiasi cluster Kafka in produzione, la visibilità per broker e per consumer group è ciò che separa un avviso di 60 secondi su un consumer in ritardo dal trovarsi un arretrato di 50 milioni di messaggi a fine giornata. Xitoring rileva automaticamente i suoi broker, legge le MBean JMX e gli offset dei consumer, e instrada gli avvisi verso Slack, PagerDuty, Telegram o il suo on-call esistente.

    Indicatori

    Ciò che monitoriamo

    Numero di broker

    Broker attivi nel cluster.

    Lag dei consumer

    Messaggi in ritardo per ogni consumer group.

    Messaggi in ingresso/sec

    Tasso di ingestione dei messaggi.

    Byte in entrata/uscita

    Throughput di rete per broker.

    Partizioni sottoreplicate

    Partizioni al di sotto del fattore di replica.

    Riduzioni ISR

    Eventi di shrink delle repliche in sincronia.

    UncleanLeaderElectionsPerSec

    Tasso di repliche fuori sincronia promosse a leader (con perdita di dati). Dovrebbe essere 0: un valore diverso da zero significa che `unclean.leader.election.enable=true` E si è verificato un evento di fallimento reale.

    MessagesInPerSec / BytesIn / BytesOut

    Throughput per broker e per topic. Cali improvvisi con numero di producer stabile = problema di ingest; picchi improvvisi = tempesta di retry o producer fuori controllo.

    Latenza delle richieste (p99)

    p99 del tempo di gestione delle richieste Produce, Fetch e Metadata da `kafka.network:type=RequestMetrics`. Intercetta il sovraccarico del broker prima che provochi timeout lato client.

    LeaderCount per broker

    Leader di partizione per broker. Distribuzione disomogenea (un broker che detiene il 60%+ dei leader) = cluster sbilanciato, da correggere con `kafka-reassign-partitions.sh` o.

    Dimensione del log per topic

    Dimensione aggregata del log su disco per topic da `kafka.log:type=Log,name=Size`. Guida gli avvisi sullo spazio su disco e informa le policy di tiered storage in Kafka 3.8+.

    RemoteLogManager (tiered storage)

    Metriche di tiered storage di Kafka 3.8+: byte caricati nel tier remoto, segmenti remoti vs locali, latenza di fetch dal remoto. Intercetta problemi di connettività S3 / IAM che rompono i fetch tiered.

    Notifiche e avvisi

    Configurabile condizioni di attivazione

    Imposta dei trigger personalizzati nella tua dashboard per ricevere una notifica non appena le metriche dell{name}e superano le soglie da te definite.

    Apache Kafka pannello di controllo per la configurazione dei trigger di monitoraggio

    Lag dei consumer

    critico

    Si attiva quando un consumer resta indietro.

    Partizioni sottoreplicate

    critico

    Avvisa su problemi di replica.

    Broker offline

    critico

    Si attiva quando un broker lascia il cluster.

    Utilizzo disco

    avviso

    Si attiva quando il disco del broker si sta riempiendo.

    01

    Importanza del monitoraggio Kafka

    Kafka elabora migliaia di miliardi di messaggi al giorno. Lag dei consumer, guasti dei broker e squilibrio delle partizioni possono causare guasti nelle pipeline dati.

    • Rileva il lag dei consumer prima della perdita di dati
    • Monitora l'ISR per la durabilità dei dati
    • Tieni traccia dello stato dei broker tra cluster
    • Garantisci il bilanciamento delle partizioni
    Monitoraggio Kafka
    Analisi delle partizioni
    02

    Perché scegliere Xitoring

    Monitoraggio Kafka di livello enterprise.

    • Configurazione zero-config
    • Nodi globali
    • Dashboard unificata
    • Avvisi multicanale
    • Conservazione storica
    Panoramica
    Avvisi
    Casi d'uso

    Scenari comuni di monitoraggio di Kafka

    Dove Kafka viene tipicamente eseguito oggi — e cosa potrebbe andare storto se nessuno lo monitora.

    La dorsale di messaggistica che collega le tue app

    Quando Kafka trasporta i messaggi che spostano i dati tra le tue app, qualsiasi rallentamento significa che un'app sta silenziosamente rimanendo indietro — e le conseguenze (aggiornamenti ritardati, dati obsoleti, flussi di lavoro interrotti) si manifestano solo in seguito. Rileviamo il ritardo nel momento in cui inizia in modo che non diventi mai un problema visibile al cliente.

    Kafka in esecuzione all'interno di Kubernetes

    Quando Kafka viene eseguito in Kubernetes, la piattaforma lo sposta costantemente — e un riavvio di routine può indebolire brevemente la rete di sicurezza che protegge i tuoi dati. Monitoriamo ogni riavvio e ribilanciamento in modo che un normale aggiornamento non possa silenziosamente lasciare il sistema a un solo guasto dalla perdita di dati.

    Kafka autogestito per dati ad alto volume

    Le aziende che gestiscono il proprio Kafka su larga scala hanno bisogno che sia estremamente solido — di solito trasporta i dati più preziosi che possiedono. Monitoriamo i segnali che lo mantengono in salute in modo che il team possa concentrarsi sulla creazione di prodotti invece di risolvere problemi sullo strato di messaggistica.

    Prima di iniziare

    Prerequisiti per Apache Kafka

    Assicurati di avere tutto questo in posizione — la maggior parte delle installazioni dura 60 secondi una volta soddisfatte le condizioni.

    • Broker Kafka con JMX abilitato (porta predefinita 9999)
    • Raggiungibilità di rete da Xitogent verso la porta JMX di ciascun broker
    • Credenziali di autenticazione JMX se la sicurezza è configurata
    Guida all'installazione

    Inizia con verbali

    1

    Installa Xitogent su ogni broker

    Installa il leggero agente di monitoraggio Xitogent su ogni broker Kafka che vuoi monitorare.

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

    Abilita JMX su ogni broker

    Kafka espone le metriche broker via JMX. Imposta `KAFKA_JMX_OPTS` per abilitare un listener JMX (tipicamente porta 9999) su ogni broker, ricarica il servizio e conferma che l'host dell'agente possa connettersi alla porta JMX.

    sudo xitogent integrate
    3

    Abilita l'integrazione Kafka

    Usa la dashboard di Xitoring o la CLI per abilitare l'integrazione Kafka. Xitogent scopre automaticamente ID dei broker, topic e consumer group nel cluster.

    4

    Configura le soglie di allerta (opzionale)

    Imposta soglie personalizzate per Consumer Lag, partizioni sotto-replicate o eventi Broker Down per intercettare problemi di replicazione e back-pressure prima che i consumer rimangano indietro.

    5

    Verifica che funzioni

    Esegui questo comando sul server per confermare che Xitogent ha rilevato l'integrazione. In circa 30 secondi nuove metriche cominceranno a comparire sulla tua dashboard.

    sudo xitogent status

    Spesso domande poste

    Versioni di Kafka?
    Sono supportate le versioni 2.x e 3.x di Kafka.
    ZooKeeper o KRaft?
    Sono supportate entrambe le modalità.
    Cosa sono le partizioni sotto-replicate e come le risolvo?
    Le partizioni sotto-replicate hanno meno ISR (in-sync replicas) del replication factor: di solito perché un broker è morto, in ritardo o in fase di riavvio. Esegua `kafka-topics.sh --describe --under-replicated-partitions` per elencarle. Risolva il broker sottostante e l'ISR recupera automaticamente. Se un broker è perso definitivamente, usi `kafka-reassign-partitions.sh` per spostare le repliche sui broker rimasti. Un valore sostenuto di UnderReplicatedPartitions > 0 = paginare l'on-call.
    Come monitoro le metriche JMX dei broker Kafka con Prometheus?
    Pattern standard: distribuire prometheus come Java agent JVM in ciascun broker (`-javaagent:jmx_prometheus_javaagent.jar=8080:kafka-config.yml`); Prometheus fa lo scrape dell'endpoint `/metrics` dell'esportatore. Il `kafka-config.yml` definisce il mapping MBean → metrica. Xitogent legge direttamente JMX senza esportatore, ma è compatibile con ambienti che lo eseguono già per dashboard Grafana.
    Cos'è la modalità KRaft e come cambia il monitoraggio senza ZooKeeper?
    KRaft (Kafka Raft) sostituisce ZooKeeper con un quorum interno di controller basato su Raft (default dalla 3.3, unica opzione nella 4.0). Cambia il monitoraggio: niente metriche dell'ensemble ZK, ma tenga d'occhio il quorum del controller (3 o 5 broker eseguiti come controller), le MBean `kafka.controller:type=KafkaController` e `kafka.server:type=raft-metrics`. La semantica di `ActiveControllerCount` resta la stessa (deve essere esattamente 1 leader attivo).
    Come rilevo le partizioni offline in Kafka?
    `kafka.controller:type=KafkaController,name=OfflinePartitionsCount`: deve essere 0. Qualsiasi valore diverso da zero = dati non disponibili sia per lettura sia per scrittura. Combinato con `UncleanLeaderElectionsPerSec > 0` = il cluster ha perso dati promuovendo una replica fuori sincronia. Elenchi le partizioni interessate tramite `kafka-topics.sh --describe --unavailable-partitions`.
    Come monitoro un cluster Kafka su Kubernetes (Strimzi)?
    L'operatore Strimzi abilita JMX su ciascun broker di default sulla porta `:9999`. Installi Xitogent su un nodo K8s con accesso di rete ai pod broker, oppure lo distribuisca come DaemonSet che si collega all'endpoint JMX di ogni pod tramite il DNS dei Service. Tenga d'occhio gli eventi di rolling update guidati dall'operatore (visibili come restringimenti dell'ISR) e vincoli la finestra di allerta in modo che gli update di routine non paginino l'on-call. Anche l'utilizzo del disco per pod rispetto alla soglia di tiered storage conta qui.
    Monitoraggio Kafka vs Redpanda: cosa cambia?
    Redpanda è wire-compatibile con l'API Kafka ed espone metriche equivalenti, ma direttamente tramite Prometheus (niente JMX: Redpanda è C++, non JVM). Stessa semantica delle metriche (UnderReplicatedPartitions, ConsumerLag, ecc.) ma trasporto diverso. Xitogent funziona con entrambi: percorso JMX per Apache Kafka / Confluent / Strimzi, percorso Prometheus per Redpanda. Il set di avvisi sulla salute del cluster è identico.
    Quali versioni di Kafka sono supportate?
    Kafka 3.x (la 3.8 ha aggiunto la GA del tiered storage tramite KIP-405), Kafka 4.0 (KRaft obbligatorio, niente ZooKeeper), Kafka 4.1 (protocollo di rebalance consumer di nuova generazione KIP-848 con coordinator lato server). Le versioni 2.x più vecchie funzionano ma non hanno KRaft e tiered storage. Confluent Platform 7.x / 8.x e Redpanda sono compatibili tramite l'API Kafka condivisa.

    Inizia a monitorare Apache Kafka oggi

    Configurazione in meno di 60 secondi. Non è richiesta alcuna carta di credito. Statistiche complete fin dal primo giorno.

    Inizia la prova gratuita

    Continua a esplorare

    Correlati Integrazioni