Initiation aux métriques du client Kafka

Avec Kafka, la surveillance implique généralement divers indicateurs liés aux rubriques, aux partitions, aux courtiers et aux groupes de consommateurs. Les métriques Kafka standard incluent des informations sur le débit, le temps d'attente, la réplication et l'utilisation du disque. Reportez-vous à la documentationKafka et aux outils de surveillance appropriés pour comprendre les métriques spécifiques disponibles pour votre version de Kafka et savoir comment les interpréter efficacement.

Pourquoi est-il important de surveiller les clients Kafka ?

La surveillance de votre instance Event Streams est essentielle pour garantir des fonctionnalités optimales et la santé globale de votre pipeline de données. La surveillance de vos clients Kafka permet d'identifier les premiers signes d'échec d'application, tels qu'une utilisation élevée des ressources, des consommateurs en retard et des goulots d'étranglement. L'identification précoce de ces signes d'avertissement permet une réponse proactive aux problèmes potentiels qui réduisent les temps d'indisponibilité et empêchent toute interruption des opérations métier.

Les clients Kafka (producteurs et consommateurs) disposent de leur propre ensemble de métriques pour surveiller leurs performances et leur santé. En outre, le service Event Streams prend en charge un ensemble riche de métriques produites par le serveur. Pour plus d'informations, voir Surveillance des métriques de service Event Streams à l'aide de IBM Cloud Monitoring.

Métriques client à surveiller

Métriques du producteur

Indicateurs de production
Métrique Description
taux d'erreur d'enregistrement Cette métrique mesure le nombre moyen par seconde d'enregistrements envoyés qui ont généré des erreurs. Une valeur élevée de record-error-rate ou une augmentation de record-error-rate peut indiquer une perte de données ou des données qui ne sont pas traitées comme prévu. Tous ces effets peuvent compromettre l'intégrité des données que vous traitez et stockez dans Kafka. La surveillance de cet indicateur permet de s'assurer que les données envoyées par les producteurs sont enregistrées de manière précise et fiable dans vos rubriques Kafka.
demande-latence-moy Il s'agit du temps d'attente moyen de chaque demande de production en ms. Une augmentation du temps d'attente a un impact sur les performances et peut signaler un problème. La mesure de la métrique request-latency-avg peut aider à identifier les goulots d'étranglement dans votre instance. Pour de nombreuses applications, un faible temps d'attente est essentiel pour garantir une expérience utilisateur de haute qualité et un pic dans request-latency-avg peut indiquer que vous atteignez les limites de votre instance mise à disposition. Vous pouvez résoudre le problème en modifiant les paramètres de votre producteur, par exemple, en mettant en lots ou en mettant à l'échelle votre plan pour optimiser les performances.
débit d'octets Le nombre moyen d'octets envoyés par seconde pour une rubrique est une mesure de votre débit. Si vous diffusez régulièrement des données en flux, une baisse du débit peut indiquer une anomalie dans votre instance Kafka. Le plan Enterprise Event Streams démarre à partir d'une division de 150 Mo par seconde un à un entre les entrées et les sorties et il est important de connaître la quantité que vous consommez pour une planification efficace de la capacité. Ne passez pas au-dessus des deux tiers du débit maximal, pour tenir compte de l'impact possible des actions opérationnelles, telles que les mises à jour internes ou les modes de panne (par exemple, la perte d'une zone de disponibilité).

Indicateurs de consommateur

Indicateurs de consommation
Métrique Description
fetch-rate fetch-size-moy. Le nombre de demandes d'extraction par seconde (fetch-rate) et le nombre moyen d'octets extraits par demande (fetch-size-avg) sont des indicateurs clés de la performance de vos consommateurs Kafka. Un fetch-rate élevé peut signaler une inefficacité, en particulier sur un petit nombre de messages, car cela signifie que les données sont insuffisantes ou qu'aucune donnée n'est reçue à chaque fois. Les paramètres fetch-rate et fetch-size-avg sont affectés par trois paramètres: fetch.min.bytes, fetch.max.bytes et fetch.max.wait.ms. Optimisez ces paramètres pour obtenir le temps d'attente global souhaité, tout en réduisant le nombre de demandes d'extraction et éventuellement la charge sur l'unité centrale du courtier. La surveillance et l'optimisation des deux métriques garantissent un traitement efficace des données pour les charges de travail actuelles et futures.
commit-latency-moy Cette métrique mesure la durée moyenne entre l'envoi d'un enregistrement validé et la réception de la réponse de validation. A l'instar de request-latency-avg en tant que métrique de producteur, un commit-latency-avg stable signifie que vos validations de décalage se produisent en temps opportun. Un temps d'attente de validation élevé peut indiquer des problèmes dans le consommateur qui l'empêchent de valider rapidement les décalages, ce qui a un impact direct sur la fiabilité du traitement des données. Cela peut entraîner un traitement en double des messages si un consommateur doit redémarrer et retraiter les messages à partir d'un décalage non validé précédemment. Un temps d'attente de validation élevé signifie également que les opérations d'administration passent plus de temps que le traitement réel des messages. Ce problème peut entraîner des arriérés de messages en attente de traitement, en particulier dans les environnements à volume élevé.
débit-octets-consommés Il s'agit d'une métrique d'extraction de consommateur qui mesure le nombre moyen d'octets consommés par seconde. Similaire à byte-rate en tant qu'indicateur de producteur, il doit s'agir d'un indicateur stable et attendu. Un changement soudain de la tendance attendue de bytes-consumed-rate peut représenter un problème avec vos applications. Un faible débit peut être un signal d'efficacité dans les extractions de données ou les ressources surdimensionnées. Un débit plus élevé peut submerger la capacité de traitement des consommateurs et donc nécessiter une mise à l'échelle, en créant davantage de consommateurs pour équilibrer la charge, ou en modifiant les configurations des consommateurs, telles que les tailles d'extraction.
rééquilibrage-taux-par-heure Nombre de rééquilibrage de groupe pris en compte par heure. Le rééquilibrage se produit chaque fois qu'il y a un nouveau consommateur ou lorsqu'un consommateur quitte le groupe et provoque un retard dans le traitement. Cela se produit car les partitions sont réaffectées, ce qui rend les consommateurs Kafka moins efficaces s'il y a beaucoup de rééquilibrage par heure. Un taux de rééquilibrage plus élevé par heure peut être causé par des erreurs de configuration conduisant à un comportement de consommateur instable. Cette action de rééquilibrage peut entraîner une augmentation du temps d'attente et entraîner une panne des applications. Assurez-vous que vos groupes de consommateurs sont stables en suivant un rebalance-rate-per-hour faible et stable.