Iniciación a las métricas del cliente Kafka
Con Kafka, la supervisión suele implicar diversas métricas relacionadas con temas, particiones, intermediarios y grupos de consumidores. Las métricas estándar de Kafka incluyen información sobre el rendimiento, la latencia, la réplica y el uso de disco. Consulte la documentación deKafka y las herramientas de supervisión relevantes para comprender las métricas específicas disponibles para su versión de Kafka y cómo interpretarlas de forma eficaz.
¿Por qué es importante supervisar clientes Kafka ?
La supervisión de la instancia de Event Streams es crucial para garantizar una funcionalidad óptima y el estado general del conducto de datos. La supervisión de los clientes de Kafka ayuda a identificar los primeros signos de anomalía de la aplicación, como por ejemplo un alto uso de recursos, consumidores rezagados y cuellos de botella. La identificación temprana de estas señales de aviso permite una respuesta proactiva a posibles problemas que minimizan el tiempo de inactividad y evitan cualquier interrupción de las operaciones de negocio.
Los clientes de Kafka (productores y consumidores) tienen su propio conjunto de métricas para supervisar su rendimiento y estado. Además, el servicio Event Streams da soporte a un amplio conjunto de métricas generadas por el servidor. Para obtener más información, consulte Supervisión de métricas de servicio de Event Streams utilizando IBM Cloud Monitoring.
Métricas de cliente a supervisar
Métricas de productor
| Métrica | Descripción |
|---|---|
| tasa de errores de registro | Esta métrica mide el número promedio por segundo de registros enviados que han resultado en errores. Un record-error-rate alto o un aumento en record-error-rate puede indicar una pérdida en los datos o datos
que no se están procesando como se esperaba. Todos estos efectos pueden comprometer la integridad de los datos que está procesando y almacenando en Kafka. La supervisión de esta métrica ayuda a garantizar que los datos enviados por
los productores se registren de forma precisa y fiable en los temas de Kafka. |
| solicitud-latencia-prom | Es la latencia promedio para cada solicitud de producción en ms. Un aumento de la latencia afecta al rendimiento y puede indicar un problema. La medición de la métrica request-latency-avg puede ayudar a identificar cuellos
de botella en la instancia. Para muchas aplicaciones, la baja latencia es crucial para garantizar una experiencia de usuario de alta calidad y un pico en request-latency-avg puede indicar que está alcanzando los límites
de la instancia suministrada. Puede solucionar el problema cambiando los valores del productor, por ejemplo, procesando por lotes o escalando el plan para optimizar el rendimiento. |
| velocidad de bytes | El número promedio de bytes enviados por segundo para un tema es una medida del rendimiento. Si transmite datos de forma regular, un descenso en el rendimiento puede indicar una anomalía en la instancia de Kafka. El plan de empresa Event Streams se inicia a partir de una división de uno a uno de 150 MB por segundo entre la entrada y la salida y es importante saber cuánto de eso está consumiendo para una planificación de capacidad efectiva. No supere los dos tercios del rendimiento máximo, para tener en cuenta el posible impacto de las acciones operativas, como las actualizaciones internas o las modalidades de anomalía (por ejemplo, la pérdida de una zona de disponibilidad). |
Métricas de consumidor
| Métrica | Descripción |
|---|---|
| capch-rate fetch-size-avg | El número de solicitudes de captación por segundo (fetch-rate) y el número promedio de bytes captados por solicitud (fetch-size-avg) son indicadores clave del rendimiento de los consumidores de Kafka. Un fetch-rate alto puede indicar ineficiencia especialmente en un pequeño número de mensajes, porque significa que no se reciben datos suficientes o posiblemente no se reciben datos cada vez. fetch-rate y fetch-size-avg se ven afectados por tres valores: fetch.min.bytes, fetch.max.bytes y fetch.max.wait.ms. Ajuste estos valores para lograr la latencia global deseada, al tiempo que minimiza el número de solicitudes
de captación y potencialmente la carga en la CPU del intermediario. La supervisión y optimización de ambas métricas garantiza que está procesando los datos de forma eficiente para las cargas de trabajo actuales y futuras. |
| promedio de latencia de confirmación | Esta medida mide el tiempo promedio entre el envío de un registro confirmado y la recepción de la respuesta de confirmación. De forma similar a request-latency-avg como métrica de productor, un commit-latency-avg estable significa que las confirmaciones de desplazamiento se producen de forma puntual. Una latencia de confirmación alta puede indicar problemas en el consumidor que impiden que confirme los desplazamientos rápidamente, lo que afecta
directamente a la fiabilidad del proceso de datos. Puede dar lugar a un proceso duplicado de mensajes si un consumidor tiene que reiniciar y volver a procesar los mensajes desde un desplazamiento no confirmado anteriormente. Una latencia
de confirmación alta también significa pasar más tiempo en operaciones administrativas que el proceso de mensajes real. Este problema puede provocar retrasos en los mensajes que están a la espera de ser procesados, especialmente en
entornos de gran volumen. |
| tasa de bytes consumidos | Esta es una medida de captación de consumidor que mide el número promedio de bytes consumidos por segundo. De forma similar a byte-rate como métrica de productor, debe ser una métrica estable y esperada. Un cambio repentino
en la tendencia esperada de bytes-consumed-rate puede representar un problema con las aplicaciones. Una tasa baja podría ser una señal de eficiencia en captaciones de datos o recursos suministrados en exceso. Una tasa
más alta podría desbordar la capacidad de proceso de los consumidores y, por lo tanto, requerir escalado, crear más consumidores para equilibrar la carga o cambiar las configuraciones de los consumidores, como por ejemplo los tamaños
de captación. |
| reequilibrar-velocidad-por-hora | El número de rebalances de grupo en los que ha participado por hora. El reequilibrio se produce cada vez que hay un consumidor nuevo o cuando un consumidor abandona el grupo y provoca un retraso en el proceso. Esto sucede porque las
particiones se vuelven a asignar, lo que hace que los consumidores de Kafka sean menos eficientes si hay muchos rebalances por hora. Una tasa de reequilibrio más alta por hora podría deberse a configuraciones incorrectas que conduzcan
a un comportamiento inestable del consumidor. Esta acción de reequilibrio podría provocar un aumento de la latencia y podría hacer que las aplicaciones se bloquearan. Asegúrese de que los grupos de consumidores son estables realizando
un seguimiento de un rebalance-rate-per-hour bajo y estable. |