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 vérifier si la consommation suit le rythme de 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 exécuté 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é n'est pas nécessairement alarmant. Concentrez-vous sur la tendance : l'écart est-il stable, croissant ou dû à des offsets non validés ?
Diagnostiquer l'accumulation
Pour vérifier si l'accumulation est normale, examinez 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, consultez les valeurs Last Consumed At, Accumulated Messages et Consumer Offset.
Ces valeurs sont actualisées toutes les minutes. Cliquez sur Details pour afficher l'offset du consommateur pour chaque partition.
Utilisez le tableau décisionnel 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 constant. | 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 à un débit inférieur à celui de la 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 | Probable faux positif. Si le système en aval utilise le mode de consommation assign, les offsets sont gérés manuellement. Les messages peuvent déjà être consommés, mais apparaissent comme accumulés car les offsets n'ont pas été validés. |
Validez les offsets manuellement 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 probable des consommateurs. L'instance a déclenché une limitation du débit de consommation. Le client n'est pas totalement bloqué : il peut toujours extraire des messages, mais à un taux restreint, ce qui entraîne 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 les spécifications 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 d'autres topics de la même instance | Impact indirect possible lié aux lectures à froid. L'accumulation sur un seul topic n'affecte généralement pas directement les autres topics de la même instance. Toutefois, si les messages accumulés ont été vidés sur disque, leur récupération déclenche des E/S disque plutôt que des 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, commencez par réduire l'accumulation sur le topic concerné. |
Une valeur élevée pour 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 débit 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 derrière la production, profilez la logique de traitement des messages dans votre application. Recherchez des appels E/S lents, des écritures en base de données ou des opérations bloquantes lors de la phase de traitement.
Augmenter le débit 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'aura aucun effet : les consommateurs supplémentaires resteront inactifs.
Augmenter le nombre de threads de consommation : utilisez la consommation multithread au sein de chaque instance de consommateur. Pour plus de détails sur l'implémentation, consultez la section « Augmenter le débit de consommation » dans Bonnes pratiques pour les consommateurs.
Dans la plupart des cas, une accumulation anormale de messages est causée par une consommation lente ou par 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ééquilibres
Si des messages s'accumulent et que l'état 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ééquilibres fréquents sont généralement causés par des connexions et déconnexions répétées des consommateurs à un rythme élevé. Pour plus d'informations, consultez Pourquoi des rééquilibres se produisent-ils fréquemment sur mon client consommateur ?
Dépanner les 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 à la 0.10.2, effectuez une mise à 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 dû à un goulot d'étranglement des ressources côté serveur.