L'accumulation de messages se produit lorsque l'offset validé (committed offset) d'un groupe de consommateurs est inférieur au dernier offset produit par le broker (high-water mark). La différence entre ces deux offsets correspond au nombre de messages accumulés. Une augmentation de ce nombre n'indique pas systématiquement un problème : l'essentiel est de savoir si la consommation suit le rythme de la production. Utilisez ce guide pour déterminer si l'accumulation est normale et résoudre les cas anormaux.
Fonctionnement de la consommation de messages
Avant de diagnostiquer une accumulation, comprenez le cycle de consommation en deux phases sur chaque client :
Extraction (Pull) : Le client récupère les messages depuis le broker.
Traitement : Le client exécute la logique métier sur chaque message, puis valide l'offset du consommateur auprès du broker.
Le nombre de messages accumulés équivaut au high-water mark du broker moins l'offset validé du groupe de consommateurs. Un chiffre élevé ne signale pas nécessairement un problème. Concentrez-vous sur la tendance : l'écart est-il stable, en croissance ou dû à des offsets non validés ?
Diagnostic de l'accumulation
Pour vérifier si l'accumulation est normale, inspectez les métriques du groupe de consommateurs dans la console ApsaraMQ for Kafka :
Connectez-vous à la console ApsaraMQ for Kafka.
Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance.
Dans le volet de navigation de gauche, cliquez sur Instances.
Sur la page Instances, cliquez sur le nom de l'instance cible.
Sur la page Instance Details, cliquez sur Groups dans le volet de navigation de gauche.
Sur la page Groups, repérez le groupe cible et choisissez More > Consumer Status dans la colonne Actions.
Sur la page Consumer Status, vérifiez les valeurs de Last Consumed At, Accumulated Messages et Consumer Offset.
Ces valeurs sont actualisées toutes les minutes. Cliquez sur Consumption Details pour afficher l'offset du consommateur pour chaque partition.
Utilisez le tableau de décision suivant pour interpréter les métriques :
|
Symptôme |
Diagnostic |
Action |
|
Last Consumed At est proche de l'heure actuelle et Accumulated Messages fluctue dans une plage stable |
Normal : le client extrait et traite les messages à un rythme régulier. |
Aucune action requise. |
|
Accumulated Messages augmente continuellement et Consumer Offset reste inchangé |
Anormal : le thread du consommateur est bloqué. Le client a cessé de traiter les messages et de valider les offsets. |
Consultez la section Résoudre une accumulation anormale. |
|
Accumulated Messages augmente continuellement, mais Consumer Offset progresse |
Anormal : la consommation est trop lente. Le client traite les messages, mais le taux de traitement est inférieur au taux de production. Le goulot d'étranglement se situe dans la phase de traitement (phase 2), et non dans la phase d'extraction. |
Consultez la section Résoudre une accumulation anormale. |
|
Les messages semblent accumulés dans les partitions, mais le traitement en aval fonctionne normalement |
Faux positif probable. Si le système en aval utilise le mode de consommation |
Validez manuellement les offsets pour effacer l'accumulation signalée. |
|
Accumulated Messages augmente et Consumer Offset progresse lentement, mais la surveillance de la bande passante des consommateurs au niveau de l'instance indique que le débit a atteint la limite de taux |
Limitation de débit des consommateurs probable. L'instance a déclenché une limitation du débit des consommateurs. Le client n'est pas complètement bloqué : il peut toujours extraire des messages, mais à un taux restreint, ce qui provoque une accumulation progressive. |
Vérifiez les métriques de surveillance de la bande passante des consommateurs au niveau de l'instance. Si la limitation est confirmée, envisagez de mettre à niveau la spécification de l'instance ou de réduire le volume d'extraction du consommateur. |
|
Accumulated Messages augmente considérablement pour un topic et la consommation ralentit sur les autres topics de la même instance |
Impact indirect possible dû aux lectures à froid (cold reads). L'accumulation sur un seul topic n'affecte normalement pas directement les autres topics de la même instance. Toutefois, si les messages accumulés ont été vidés sur le disque, leur récupération déclenche des E/S disque au lieu de lectures en mémoire (lecture à froid). Des IOPS ou un débit de lecture disque élevés peuvent dégrader les performances globales de l'instance. |
Vérifiez les métriques de surveillance des E/S disque et du débit réseau au niveau de l'instance. Si les IOPS de lecture disque ou le trafic sont anormalement élevés, priorisez la réduction de l'accumulation sur le topic concerné. |
Une valeur élevée de Accumulated Messages ne signifie pas toujours qu'il y a un problème. Le nombre affiché dépend du taux de production et de la fréquence de validation des offsets. Par exemple, si un topic reçoit 10 000 messages par seconde et que les offsets sont validés une fois par seconde, le nombre accumulé fluctue normalement autour de 10 000.
Résoudre une accumulation anormale
Après avoir confirmé une accumulation anormale, identifiez le goulot d'étranglement et augmentez le taux de consommation.
Identifier le goulot d'étranglement
Déterminez si le thread du consommateur est bloqué ou simplement lent :
Thread bloqué : Si Consumer Offset ne progresse pas, le thread du consommateur est probablement bloqué. Utilisez
jstack(pour les applications Java) pour capturer un dump de threads et identifier le point de blocage. Pour plus d'informations, consultez jstack - Stack Trace.Traitement lent : Si Consumer Offset progresse mais reste en retard par rapport à la production, profilez la logique de traitement des messages dans votre application. Recherchez les appels d'E/S lents, les écritures en base de données ou les opérations bloquantes lors de la phase de traitement.
Augmenter le taux de consommation
Utilisez l'une ou les deux approches suivantes :
Ajouter des consommateurs : Ajoutez davantage d'instances de consommateurs au sein du même groupe de consommateurs, soit sous forme de threads supplémentaires dans un processus existant, soit en tant que processus distincts. Chaque consommateur gère une ou plusieurs partitions. Si le nombre de consommateurs est déjà égal ou supérieur au nombre de partitions, l'ajout de consommateurs supplémentaires n'a aucun effet : les consommateurs supplémentaires restent inactifs.
Augmenter les threads de consommation : Utilisez la consommation multithread au sein de chaque instance de consommateur. Pour les détails d'implémentation, consultez la section « Increase consumption rate » dans Bonnes pratiques pour les consommateurs.
Dans la plupart des cas, une accumulation anormale de messages est causée par une consommation lente ou un thread de consommation bloqué. Évitez de définir des durées longues pour les paramètres associés dans la logique de consommation.
Vérifier les rééquilibrages
Si des messages s'accumulent et que le statut du consommateur semble anormal dans la console, le groupe de consommateurs est peut-être en cours de rééquilibrage. Pendant un rééquilibrage, aucun message n'est consommé.
Des rééquilibrages fréquents sont généralement causés par des connexions et déconnexions rapides des consommateurs. Pour plus d'informations, consultez Pourquoi des rééquilibrages se produisent-ils fréquemment sur mon client consommateur ?
Dépannage des erreurs read tcp i/o timeout
Q : La mise à l'échelle verticale de l'instance ApsaraMQ for Kafka peut-elle résoudre les erreurs read tcp i/o timeout qui provoquent une accumulation de messages ?
R : La mise à l'échelle verticale ne permet généralement pas de résoudre directement les erreurs read tcp i/o timeout. Cette erreur est plus souvent liée à des problèmes de connectivité réseau ou de configuration du client qu'à des contraintes de ressources côté serveur. Avant d'envisager une montée en puissance, suivez ces étapes de dépannage :
Vérifiez que la connexion réseau entre le client et le broker est stable. Recherchez toute perte de paquets, latence élevée ou problème de connectivité intermittent.
Vérifiez la version du client. Si la version du client est antérieure à 0.10.1.0, mettez à niveau vers une version prise en charge.
Ajustez les paramètres
max.poll.interval.msetsession.timeout.ms. Si ces valeurs sont trop courtes par rapport au temps nécessaire pour traiter chaque lot d'extraction (poll), le client peut expirer et déclencher un rééquilibrage involontaire, ce qui interrompt la consommation et augmente l'accumulation. Définissez ces valeurs sur une durée adaptée à votre temps réel de traitement des messages.Dans la console ApsaraMQ for Kafka, vérifiez la page Consumer Status pour confirmer que le nombre d'accumulations et les variations d'offset correspondent aux attentes. Envisagez une mise à l'échelle uniquement si vous avez confirmé que le délai d'expiration est causé par un goulot d'étranglement des ressources côté serveur.