Cette rubrique explique pourquoi l'alerte d'accumulation de messages et l'accumulation affichée dans la console peuvent différer.
Symptômes
Vous pouvez constater une divergence entre l'alerte d'accumulation de messages et l'accumulation affichée dans la console.
Par exemple, sur l'onglet Prometheus monitoring de la page des détails du groupe de consommateurs, la carte Total Message Accumulation en haut affiche une valeur de 36. Toutefois, le graphique linéaire Prometheus ci-dessous indique que l'accumulation de messages a soudainement atteint un pic d'environ 300 à un moment précis, avant de se stabiliser. Les deux valeurs diffèrent considérablement.
Causes possibles
Cause 1
L'accumulation de messages pour une partition est calculée comme suit : partition maximum offset - partition consumer offset. L'accumulation totale de messages correspond à la somme des accumulations de messages sur toutes les partitions.
Prenons l'exemple d'une instance disposant de m groupes de consommateurs et de n topics, où chaque groupe de consommateurs s'abonne à tous les topics. L'accumulation de messages pour un groupe de consommateurs peut être calculée de deux manières :
-
Méthode de requête standard
Cette méthode envoie une requête RPC pour obtenir les offsets des consommateurs du groupe de consommateurs, ainsi qu'une autre requête RPC pour récupérer les offsets maximums des partitions des topics abonnés. Cette approche génère au moins
m * n * number of broker nodesrequêtes RPC, ce qui impacte significativement l'efficacité de la surveillance. -
Méthode de requête par lot
Cette méthode récupère d'abord tous les offsets des consommateurs pour l'ensemble des groupes de consommateurs en une seule fois. Ensuite, une autre requête par lot permet d'obtenir les offsets maximums pour toutes les partitions abonnées. Cette approche réduit le nombre de requêtes RPC de
m * n * number of broker nodesau simple nombre de nœuds broker. Cependant, en raison de la nature du traitement par lots, un délai survient entre la récupération des offsets des consommateurs et celle des offsets maximums. Pendant ce délai, l'offset maximum d'une partition peut continuer à augmenter à mesure que de nouveaux messages sont produits. Ce décalage temporel entraîne un calcul imprécis de l'accumulation de messages.
La valeur Total Message Accumulation affichée sur la page Group Details de la console est obtenue via des requêtes RPC distinctes pour récupérer l'offset du consommateur et l'offset maximum de la partition. Comme l'écart temporel entre ces deux requêtes RPC est faible, la divergence par rapport à l'accumulation réelle de messages reste minime. En revanche, l'accumulation de messages utilisée pour la surveillance est récupérée à l'aide de requêtes par lots. Cette méthode crée un décalage entre le moment où l'offset du consommateur est récupéré et celui où l'offset maximum de la partition l'est, ce qui provoque inévitablement une divergence dans le calcul de l'accumulation. C'est pourquoi la valeur de l'alerte d'accumulation de messages peut ne pas correspondre à celle affichée dans la console.
Cause 2
Lorsque la consommation est lente et que l'utilisation du disque est élevée, l'instance peut supprimer des messages avant qu'ils ne soient consommés. Cela peut entraîner un offset de consommateur inférieur à l'offset minimum d'une partition. Apache Kafka open source et Message Queue for Apache Kafka gèrent cette situation différemment :
-
Apache Kafka open source
Par défaut, il ignore cette accumulation de messages lors du calcul des totaux.
-
Message Queue for Apache Kafka
Afin de vous aider à détecter plus rapidement les offsets de consommateurs anormaux dans les partitions, la politique d'alerte de surveillance les signale sous forme d'alertes d'accumulation de messages, vous permettant ainsi de les traiter selon vos besoins.
Pour vous aider à distinguer les partitions anormales des partitions normales dans la console, Message Queue for Apache Kafka exclut l'accumulation de messages des partitions anormales du total Total Message Accumulation affiché sur la page Group Details. Par conséquent, l'accumulation de messages signalée par le système de surveillance est bien supérieure à celle affichée dans la console. Cela engendre une divergence entre l'alerte d'accumulation de messages et l'accumulation visible dans la console.
Si vous décidez d'ignorer cette alerte, vous pouvez réinitialiser l'offset du consommateur à 0 dans la console. Après cette réinitialisation, Message Queue for Apache Kafka ne déclenchera plus d'alertes d'accumulation de messages pour le topic correspondant au sein de ce groupe de consommateurs. Pour plus d'informations, consultez la rubrique Réinitialiser les offsets des consommateurs.
Si vous devez désactiver temporairement cette fonctionnalité, veuillez soumettre un ticket.
Les exemples suivants illustrent ce comportement :
-
Le total d'accumulation de messages dans la console ne correspond pas au total indiqué dans l'alerte.
Sur la page des détails du groupe de consommateurs Kafka, sélectionnez l'onglet Prometheus monitoring. Le champ Total Message Accumulation en haut affiche 13 568, tandis que le graphique linéaire Total Message Accumulation ci-dessous montre que l'accumulation est restée stable au cours des 30 dernières minutes.
-
Le total d'accumulation de messages dans la console exclut l'accumulation anormale.
Sur la page des détails du groupe de consommateurs, le champ Total Message Accumulation s'affiche dans une carte en haut de la page. Dans l'onglet Consumption Status, un tableau présente l'accumulation pour chaque topic dans la colonne Accumulated Messages.
-
Les détails de consommation d'un topic révèlent des partitions présentant une accumulation anormale, où l'offset du consommateur est inférieur à l'offset minimum.
Par exemple, la partition 0 affiche un Consumer Offset de 1, alors que son Min Offset est de 97 413 417 052. La valeur Accumulated Messages apparaît sous la forme
--et n'est pas incluse dans le total.