Sistemas de datos
    Actualizado mayo de 2026
    Apache Kafka logo

    Apache Kafka Seguimiento

    Supervisa el estado de los brokers de Apache Kafka, el retraso de las particiones, los grupos de consumidores y el rendimiento en tiempo real sin necesidad de configuración.

    Empieza tu prueba gratuitaVer documentos

    ¿Por qué realizar un seguimiento? Apache Kafka?

    Apache Kafka es la columna vertebral de los flujos de datos en tiempo real y la transmisión de eventos. La supervisión de Kafka garantiza el buen funcionamiento de los clústeres de brokers, un retraso mínimo en los consumidores, una distribución óptima de las particiones y una entrega fiable de los mensajes.

    Detección automática mediante Xitogent
    Seguimiento de salud de brokers e ISR
    Monitorización de lag de consumer groups
    Métricas de distribución de particiones
    Tasas de throughput de mensajes
    Uso de disco por broker
    Métricas a nivel de topic
    Intervalos de recolección de 1 minuto
    Umbrales de alerta personalizables para cada métrica
    Intervalos de recolección de métricas de 1 minuto de forma predeterminada
    ¿Qué es el monitoreo de Kafka?

    Monitoreo de Kafka, explicado

    El monitoreo de Kafka detecta particiones subreplicadas, particiones offline, picos de lag en grupos de consumidores, contracciones de ISR, fallos del controlador y presión de disco antes de que provoquen pérdida de datos, fallos en microservicios descendentes o caídas completas del broker. Para pipelines CDC, sistemas de event-sourcing, eventing entre microservicios y cualquier clúster Kafka de producción, la visibilidad por broker + por grupo de consumidores es lo que separa una alerta de 60 segundos sobre un consumidor rezagado de encontrar un backlog de 50 millones de mensajes al final del día. Xitoring autodescubre sus brokers, lee MBeans JMX + offsets de consumidores y enruta las alertas a Slack, PagerDuty, Telegram o su guardia existente.

    Métricas

    Lo que monitorizamos

    Número de brokers

    Brokers activos en el clúster.

    Lag de consumidores

    Mensajes pendientes por cada consumer group.

    Mensajes entrantes/s

    Tasa de ingestión de mensajes.

    Bytes entrantes/salientes

    Throughput de red por broker.

    Particiones subreplicadas

    Particiones por debajo del factor de replicación.

    Reducciones ISR

    Eventos de reducción de réplicas en sincronización.

    UncleanLeaderElectionsPerSec

    Tasa de réplicas fuera de sincronía que son promovidas a líder (con pérdida de datos). Debería ser 0 — distinto de cero significa `unclean.leader.election.enable=true` Y que ocurrió un evento de fallo real.

    MessagesInPerSec / BytesIn / BytesOut

    Rendimiento por broker y por topic. Caídas súbitas con conteo de productores estable = problema de ingesta; picos súbitos = tormenta de reintentos o productor desbocado.

    Latencia de solicitudes (p99)

    p99 del tiempo del handler de solicitudes Produce, Fetch y Metadata desde `kafka.network:type=RequestMetrics`. Detecta sobrecarga del broker antes de que cause timeouts en los clientes.

    LeaderCount por broker

    Líderes de partición por broker. Distribución desigual (un broker con el 60%+ de los líderes) = clúster desbalanceado, corrija con `kafka-reassign-partitions.sh` u otra herramienta.

    Tamaño del log por topic

    Tamaño agregado del log en disco por topic desde `kafka.log:type=Log,name=Size`. Impulsa las alertas de espacio en disco e informa las políticas de almacenamiento por niveles en Kafka 3.8+.

    RemoteLogManager (almacenamiento por niveles)

    Métricas de almacenamiento por niveles de Kafka 3.8+: bytes subidos al nivel remoto, segmentos en remoto vs local, latencia de fetch desde remoto. Detecta problemas de conectividad / IAM con S3 que rompen las lecturas por niveles.

    Desencadenantes y alertas

    Configurables condiciones de activación de alertas

    Configura alertas personalizadas en tu panel de control para recibir una notificación en cuanto las métricas de «Apache Kafka» superen los umbrales que hayas definido.

    Apache Kafka panel de control de la configuración de los desencadenantes de supervisión

    Lag de consumidores

    crítico

    Se dispara cuando un consumidor se queda atrás.

    Particiones subreplicadas

    crítico

    Alerta ante problemas de replicación.

    Broker caído

    crítico

    Se activa cuando un broker abandona el clúster.

    Uso de disco

    advertencia

    Se dispara cuando el disco del broker se está llenando.

    01

    Importancia de la monitorización de Kafka

    Kafka procesa billones de mensajes al día. El lag de consumidores, los fallos de brokers y el desequilibrio de particiones pueden provocar fallos en las pipelines de datos.

    • Detecte el lag de consumidores antes de la pérdida de datos
    • Monitorice el ISR para la durabilidad de los datos
    • Realice un seguimiento de la salud de los brokers entre clústeres
    • Garantice el equilibrio de las particiones
    Monitorización de Kafka
    Analítica de particiones
    02

    Por qué elegir Xitoring

    Monitorización Kafka de nivel empresarial.

    • Configuración zero-config
    • Nodos globales
    • Panel unificado
    • Alertas multicanal
    • Retención histórica
    Vista general
    Alertas
    Casos de uso

    Escenarios habituales de monitoreo de Kafka comunes

    Dónde suele ejecutarse Kafka hoy en día, y qué podría salir mal si nadie está vigilando.

    La columna vertebral de mensajería que conecta sus aplicaciones

    Cuando Kafka transporta los mensajes que mueven datos entre sus aplicaciones, cualquier ralentización significa que una aplicación se está quedando atrás discretamente, y las consecuencias (actualizaciones retrasadas, datos obsoletos, flujos de trabajo rotos) solo aparecen más tarde. Detectamos el retraso en el momento en que comienza para que nunca se convierta en un problema visible para el cliente.

    Kafka ejecutándose dentro de Kubernetes

    Cuando Kafka se ejecuta en Kubernetes, la plataforma lo mueve constantemente, y un reinicio rutinario puede debilitar brevemente la red de seguridad que mantiene sus datos protegidos. Vigilamos cada reinicio y reequilibrio para que una actualización normal no pueda dejar el sistema discretamente a un solo fallo de la pérdida de datos.

    Kafka autogestionado para datos de alto volumen

    Las empresas que ejecutan su propio Kafka a escala necesitan que sea sólido como una roca; generalmente transporta los datos más valiosos que tienen. Vigilamos las señales que lo mantienen saludable para que el equipo pueda concentrarse en construir productos en lugar de apagar incendios en la capa de mensajería.

    Antes de empezar

    Requisitos previos para Apache Kafka

    Asegúrate de tener todo esto en su sitio — la mayoría de las instalaciones tardan 60 segundos una vez listo.

    • Brokers Kafka con JMX habilitado (puerto predeterminado 9999)
    • Conectividad de red desde Xitogent hacia el puerto JMX de cada broker
    • Credenciales de autenticación JMX si la seguridad está configurada
    Guía de configuración

    Empieza con minutos

    1

    Instalar Xitogent en cada broker

    Instala el agente de monitorización ligero Xitogent en cada broker de Kafka que quieras supervisar.

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

    Habilitar JMX en cada broker

    Kafka expone las métricas de broker mediante JMX. Define `KAFKA_JMX_OPTS` para habilitar un listener JMX (típicamente puerto 9999) en cada broker, recarga el servicio y confirma que el host del agente puede conectarse al puerto JMX.

    sudo xitogent integrate
    3

    Habilitar la integración de Kafka

    Usa el panel de Xitoring o la CLI para habilitar la integración de Kafka. Xitogent descubre automáticamente IDs de brokers, topics y consumer groups en el clúster.

    4

    Configurar umbrales de alerta (opcional)

    Define umbrales personalizados para consumer lag, particiones sub-replicadas o eventos Broker Down para detectar problemas de replicación y contrapresión antes de que los consumers se retrasen.

    5

    Verifica que funciona

    Ejecuta este comando en el servidor para confirmar que Xitogent ha detectado la integración. En unos 30 segundos comenzarán a llegar métricas nuevas a tu panel.

    sudo xitogent status
    Comparar

    ¿Estás considerando alternativas?

    Mira cómo se compara Xitoring frente a las alternativas para la supervisión de Apache Kafka: precios planos, integraciones más profundas y un solo agente que cubre todo tu stack.

    Ver todas las comparaciones

    Con frecuencia preguntas formuladas

    ¿Versiones de Kafka?
    Se admiten las versiones 2.x y 3.x de Kafka.
    ¿ZooKeeper o KRaft?
    Se admiten ambos modos.
    ¿Qué son las particiones subreplicadas y cómo las arreglo?
    Las particiones subreplicadas tienen menos ISRs (réplicas en sincronía) que el factor de replicación — normalmente porque un broker está caído, rezagado o reiniciándose. Ejecute `kafka-topics.sh --describe --under-replicated-partitions` para listarlas. Repare el broker subyacente y el ISR se pondrá al día automáticamente. Si un broker se pierde permanentemente, use `kafka-reassign-partitions.sh` para mover réplicas a los brokers supervivientes. UnderReplicatedPartitions > 0 sostenido = avise a la guardia.
    ¿Cómo monitoreo las métricas JMX del broker Kafka con Prometheus?
    Patrón estándar: despliegue prometheus como agente Java JVM en cada broker (`-javaagent:jmx_prometheus_javaagent.jar=8080:kafka-config.yml`), Prometheus hace scraping del endpoint `/metrics` del exportador. El `kafka-config.yml` autoriza el mapeo MBean → métrica. Xitogent lee JMX directamente sin el exportador, pero es compatible con entornos que ya lo ejecutan para dashboards de Grafana.
    ¿Qué es el modo KRaft y cómo cambia el monitoreo sin ZooKeeper?
    KRaft (Kafka Raft) reemplaza ZooKeeper con un quorum interno de controlador basado en Raft (por defecto desde Kafka 3.3, única opción en 4.0). El monitoreo cambia: sin métricas del ensemble de ZK, en su lugar vigile el controller-quorum (3 o 5 brokers actúan como controladores), los MBeans `kafka.controller:type=KafkaController` y `kafka.server:type=raft-metrics`. La semántica de `ActiveControllerCount` es la misma (debe ser exactamente 1 líder activo).
    ¿Cómo detecto particiones offline en Kafka?
    `kafka.controller:type=KafkaController,name=OfflinePartitionsCount` — debe ser 0. Cualquier valor distinto de cero = datos no disponibles tanto para lectura como escritura. Combinado con `UncleanLeaderElectionsPerSec > 0` = el clúster perdió datos al promover una réplica fuera de sincronía. Liste las particiones afectadas vía `kafka-topics.sh --describe --unavailable-partitions`.
    ¿Cómo monitoreo un clúster Kafka en Kubernetes (Strimzi)?
    El operador Strimzi habilita JMX en cada broker por defecto en el puerto `:9999`. Instale Xitogent en un nodo K8s con acceso de red a los pods del broker, o despliéguelo como un DaemonSet que se conecte al endpoint JMX de cada pod vía el DNS de Service. Vigile los eventos de actualización progresiva impulsados por el operador (visibles como contracciones de ISR) y acote la ventana de alerta para que las actualizaciones rutinarias no despierten a la guardia. El uso de disco por pod frente al umbral de almacenamiento por niveles también importa aquí.
    Monitoreo de Kafka vs Redpanda — ¿qué cambia?
    Redpanda es compatible a nivel de hilo con la API de Kafka y expone métricas equivalentes, pero vía Prometheus directamente (sin JMX — Redpanda es C++, no JVM). Misma semántica de métricas (UnderReplicatedPartitions, ConsumerLag, etc.) pero distinto transporte. Xitogent funciona con ambos — ruta JMX para Apache Kafka / Confluent / Strimzi, ruta Prometheus para Redpanda. El conjunto de alertas de salud del clúster es idéntico.
    ¿Qué versiones de Kafka son compatibles?
    Kafka 3.x (3.8 añadió almacenamiento por niveles en GA vía KIP-405), Kafka 4.0 (KRaft obligatorio, sin ZooKeeper), Kafka 4.1 (KIP-848, protocolo de rebalanceo de consumidores de próxima generación con coordinador en el servidor). La 2.x antigua funciona pero carece de KRaft y de almacenamiento por niveles. Confluent Platform 7.x / 8.x y Redpanda son compatibles vía la API compartida de Kafka.

    Empieza a seguir a Apache Kafka hoy

    Se configura en menos de 60 segundos. No se necesita tarjeta de crédito. Estadísticas completas desde el primer día.

    Empieza tu prueba gratuita

    Sigue explorando

    Relacionado Integraciones