Systèmes de données
    Mis à jour le mai 2026
    Apache Kafka logo

    Apache Kafka Suivi

    Surveillez en temps réel l'état des brokers Apache Kafka, le décalage des partitions, les groupes de consommateurs et le débit, sans aucune configuration.

    Commencer l'essai gratuitConsulter les documents

    Pourquoi surveiller ? Apache Kafka?

    Apache Kafka est la colonne vertébrale des pipelines de données en temps réel et du streaming d'événements. La surveillance de Kafka garantit le bon fonctionnement des clusters de brokers, un décalage minimal chez les consommateurs, une répartition optimale des partitions et une transmission fiable des messages.

    Détection automatique via Xitogent
    Suivi de la santé des brokers et de l'ISR
    Surveillance du lag des consumer groups
    Métriques de distribution des partitions
    Taux de débit des messages
    Utilisation disque par broker
    Métriques au niveau topic
    Intervalles de collecte d'1 minute
    Seuils d'alerte personnalisables pour chaque métrique
    Intervalles de collecte des métriques d'une minute par défaut
    Qu'est-ce que le monitoring Kafka ?

    Le monitoring Kafka, expliqué

    Le monitoring Kafka détecte les partitions sous-répliquées, les partitions hors ligne, les pics de lag des consumer groups, les rétrécissements d'ISR, les défaillances de controller et la pression disque avant qu'ils ne provoquent une perte de données, des défaillances de microservices en aval ou des pannes complètes de broker. Pour les pipelines CDC, les systèmes d'event sourcing, l'eventing microservices et tout cluster Kafka en production, la visibilité par broker + par consumer group fait la différence entre une alerte à 60 secondes sur un consommateur en retard et la découverte d'un arriéré de 50 millions de messages en fin de journée. Xitoring découvre automatiquement vos brokers, lit les MBeans JMX + les offsets des consommateurs, et achemine les alertes vers Slack, PagerDuty, Telegram ou votre astreinte existante.

    Indicateurs

    Ce que nous surveillons

    Nombre de brokers

    Brokers actifs dans le cluster.

    Lag des consommateurs

    Messages en retard pour chaque consumer group.

    Messages entrants/sec

    Taux d'ingestion des messages.

    Octets entrants/sortants

    Débit réseau par broker.

    Partitions sous-répliquées

    Partitions sous le facteur de réplication.

    Réductions ISR

    Événements de réduction de répliques en synchronisation.

    UncleanLeaderElectionsPerSec

    Taux de réplicas hors synchronisation promus en leaders (avec perte de données). Doit être 0 — une valeur non nulle signifie `unclean.leader.election.enable=true` ET qu'un événement de défaillance réel s'est produit.

    MessagesInPerSec / BytesIn / BytesOut

    Débit par broker et par topic. Des chutes soudaines avec un nombre de producteurs stable = problème d'ingestion ; des pics soudains = tempête de retries ou producteur emballé.

    Latence de requête (p99)

    p99 du temps de traitement des requêtes Produce, Fetch, Metadata depuis `kafka.network:type=RequestMetrics`. Capte la surcharge du broker avant qu'elle ne cause des timeouts côté clients.

    LeaderCount par broker

    Leaders de partitions par broker. Distribution inégale (un broker détenant 60 %+ des leaders) = cluster déséquilibré, à corriger avec `kafka-reassign-partitions.sh` ou.

    Taille de log par topic

    Taille agrégée des logs sur disque par topic depuis `kafka.log:type=Log,name=Size`. Pilote les alertes d'espace disque et informe les politiques de tiered storage en Kafka 3.8+.

    RemoteLogManager (tiered storage)

    Métriques de tiered storage Kafka 3.8+ : octets uploadés vers le niveau distant, segments en distant vs local, latence de fetch depuis le distant. Détecte les problèmes de connectivité S3 / IAM qui cassent les fetches du niveau distant.

    Déclencheurs et alertes

    Configurables déclencheurs d'alerte

    Configurez des déclencheurs personnalisés dans votre tableau de bord pour être averti dès que les indicateurs d{name}s dépassent les seuils que vous avez définis.

    Apache Kafka tableau de bord de configuration des déclencheurs de surveillance

    Lag des consommateurs

    crucial

    Se déclenche lorsqu'un consommateur prend du retard.

    Partitions sous-répliquées

    crucial

    Alerte sur les problèmes de réplication.

    Broker hors ligne

    crucial

    Se déclenche lorsqu'un broker quitte le cluster.

    Utilisation disque

    avertissement

    Se déclenche lorsque le disque du broker se remplit.

    01

    Importance de la surveillance Kafka

    Kafka traite des billions de messages quotidiennement. Le lag des consommateurs, les pannes de brokers et le déséquilibre des partitions peuvent provoquer des défaillances de pipeline de données.

    • Détectez le lag des consommateurs avant la perte de données
    • Surveillez l'ISR pour la durabilité des données
    • Suivez la santé des brokers entre les clusters
    • Garantissez l'équilibre des partitions
    Surveillance Kafka
    Analytique des partitions
    02

    Pourquoi choisir Xitoring

    Surveillance Kafka de qualité entreprise.

    • Configuration zéro-config
    • Nœuds mondiaux
    • Tableau de bord unifié
    • Alertes multicanaux
    • Conservation historique
    Vue d'ensemble
    Alertes
    Cas d'usage

    Scénarios courants de monitoring Kafka

    Où Kafka fonctionne généralement aujourd'hui — et ce qui pourrait mal tourner si personne ne surveille.

    La dorsale de messagerie connectant vos applications

    Lorsque Kafka transporte les messages qui déplacent les données entre vos applications, tout ralentissement signifie qu'une application prend discrètement du retard — et les conséquences (mises à jour retardées, données obsolètes, flux de travail interrompus) n'apparaissent que plus tard. Nous détectons le décalage dès qu'il commence afin qu'il ne devienne jamais un problème visible pour le client.

    Kafka fonctionnant dans Kubernetes

    Lorsque Kafka fonctionne dans Kubernetes, la plateforme le déplace constamment — et un redémarrage de routine peut brièvement affaiblir le filet de sécurité qui protège vos données. Nous surveillons chaque redémarrage et rééquilibrage afin qu'une mise à jour normale ne puisse pas laisser discrètement le système à une seule défaillance de la perte de données.

    Kafka autogéré pour les données à grand volume

    Les entreprises qui gèrent leur propre Kafka à grande échelle ont besoin qu'il soit d'une solidité à toute épreuve — il transporte généralement les données les plus précieuses qu'elles possèdent. Nous surveillons les signaux qui le maintiennent en bonne santé afin que l'équipe puisse se concentrer sur la création de produits au lieu de gérer les problèmes de la couche de messagerie.

    Avant de commencer

    Prérequis pour Apache Kafka

    Assurez-vous d'avoir tout cela en place — la plupart des installations sont une affaire de 60 secondes une fois ces conditions réunies.

    • Brokers Kafka avec JMX activé (port par défaut 9999)
    • Accessibilité réseau de Xitogent vers le port JMX de chaque broker
    • Identifiants d'authentification JMX si la sécurité est configurée
    Guide d'installation

    Commencez par procès-verbal

    1

    Installer Xitogent sur chaque broker

    Installez l'agent de monitoring léger Xitogent sur chaque broker Kafka que vous souhaitez surveiller.

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

    Activer JMX sur chaque broker

    Kafka expose les métriques des brokers via JMX. Définissez `KAFKA_JMX_OPTS` pour activer un listener JMX (typiquement port 9999) sur chaque broker, rechargez le service et confirmez que l'hôte de l'agent peut se connecter au port JMX.

    sudo xitogent integrate
    3

    Activer l'intégration Kafka

    Utilisez le tableau de bord Xitoring ou la CLI pour activer l'intégration Kafka. Xitogent découvre automatiquement les IDs de brokers, topics et consumer groups dans le cluster.

    4

    Configurer les seuils d'alerte (facultatif)

    Définissez des seuils personnalisés pour le consumer lag, les partitions sous-répliquées ou les événements Broker Down afin de détecter les problèmes de réplication et de back-pressure avant que les consumers ne prennent du retard.

    5

    Vérifier que tout fonctionne

    Exécutez cette commande sur le serveur pour confirmer que Xitogent a bien détecté l'intégration. De nouvelles métriques apparaîtront sur votre tableau de bord dans environ 30 secondes.

    sudo xitogent status
    Comparer

    Vous envisagez des alternatives ?

    Découvrez comment Xitoring se positionne face aux alternatives pour la surveillance de Apache Kafka — tarifs forfaitaires, intégrations plus poussées et un seul agent pour couvrir tout votre stack.

    Voir toutes les comparaisons

    Souvent a posé des questions

    Les versions de Kafka ?
    Les versions 2.x et 3.x de Kafka sont prises en charge.
    ZooKeeper ou KRaft ?
    Les deux modes sont pris en charge.
    Que sont les partitions sous-répliquées et comment les corriger ?
    Les partitions sous-répliquées ont moins d'ISR (in-sync replicas) que le facteur de réplication — généralement parce qu'un broker est mort, en retard ou en cours de redémarrage. Exécutez `kafka-topics.sh --describe --under-replicated-partitions` pour les lister. Corrigez le broker sous-jacent, puis l'ISR rattrape automatiquement. Si un broker est perdu de façon permanente, utilisez `kafka-reassign-partitions.sh` pour déplacer les réplicas vers les brokers survivants. UnderReplicatedPartitions > 0 soutenu = alerter l'astreinte.
    Comment monitorer les métriques JMX des brokers Kafka avec Prometheus ?
    Modèle standard : déployez prometheus comme agent Java JVM dans chaque broker (`-javaagent:jmx_prometheus_javaagent.jar=8080:kafka-config.yml`), Prometheus scrape l'endpoint `/metrics` de l'exportateur. Le `kafka-config.yml` whitelist le mapping MBean → métrique. Xitogent lit JMX directement sans exportateur, mais est compatible avec les environnements qui en exécutent déjà un pour les dashboards Grafana.
    Qu'est-ce que le mode KRaft et comment le monitoring change-t-il sans ZooKeeper ?
    KRaft (Kafka Raft) remplace ZooKeeper par un quorum de controllers interne basé sur Raft (par défaut depuis Kafka 3.3, seule option en 4.0). Le monitoring change : pas de métriques d'ensemble ZK, à la place surveillez le quorum de controllers (3 ou 5 brokers font office de controllers), les MBeans `kafka.controller:type=KafkaController` et `kafka.server:type=raft-metrics`. La sémantique de `ActiveControllerCount` est la même (doit être exactement 1 leader actif).
    Comment détecter les partitions Kafka hors ligne ?
    `kafka.controller:type=KafkaController,name=OfflinePartitionsCount` — doit être 0. Toute valeur non nulle = données indisponibles à la fois en lecture et en écriture. Combiné avec `UncleanLeaderElectionsPerSec > 0` = le cluster a perdu des données en promouvant un réplica hors synchronisation. Listez les partitions affectées via `kafka-topics.sh --describe --unavailable-partitions`.
    Comment monitorer un cluster Kafka sur Kubernetes (Strimzi) ?
    L'opérateur Strimzi active JMX sur chaque broker par défaut sur le port `:9999`. Installez Xitogent sur un nœud K8s avec accès réseau aux pods de brokers, ou déployez-le comme DaemonSet qui se connecte à l'endpoint JMX de chaque pod via le DNS du Service. Surveillez les événements de mises à jour roulantes pilotées par l'opérateur (visibles sous forme de rétrécissements d'ISR) et bornez la fenêtre d'alerte pour que les mises à jour de routine n'alertent pas l'astreinte. L'usage disque par pod par rapport au seuil de tiered storage compte aussi ici.
    Monitoring Kafka vs Redpanda — quelle est la différence ?
    Redpanda est compatible au niveau du fil avec l'API Kafka et expose des métriques équivalentes, mais directement via Prometheus (sans JMX — Redpanda est en C++, pas en JVM). Mêmes sémantiques de métriques (UnderReplicatedPartitions, ConsumerLag, etc.) mais transport différent. Xitogent fonctionne avec les deux — chemin JMX pour Apache Kafka / Confluent / Strimzi, chemin Prometheus pour Redpanda. L'ensemble d'alertes de santé cluster est identique.
    Quelles versions de Kafka sont prises en charge ?
    Kafka 3.x (3.8 ajoute le tiered storage GA via KIP-405), Kafka 4.0 (KRaft obligatoire, sans ZooKeeper), Kafka 4.1 (protocole de rebalance consommateur nouvelle génération KIP-848 avec coordinateur côté serveur). Les anciennes versions 2.x fonctionnent mais sans KRaft ni tiered storage. Confluent Platform 7.x / 8.x et Redpanda sont compatibles via l'API Kafka partagée.

    Commencer à surveiller Apache Kafka aujourd'hui

    Configuration en moins de 60 secondes. Aucune carte bancaire requise. Statistiques complètes dès le premier jour.

    Commencer l'essai gratuit

    Continuez à explorer

    Connexes Intégrations