La suppression d'un groupe dans ApsaraMQ for Kafka n'efface pas les décalages du consommateur (consumer offsets) stockés sur le serveur. Le système d'alerte surveillant ces décalages, les alertes d'accumulation de messages persistent jusqu'à leur effacement.
Ce phénomène s'explique par deux raisons :
Les décalages persistent après la suppression. Sur les versions serveur antérieures à 2.2.0 (basées sur Apache Kafka 0.10.2), l'API Kafka ne prend pas en charge la suppression des décalages du consommateur. La suppression d'un groupe le retire uniquement de la console. Les données de décalage sous-jacentes demeurent sur le serveur.
Les threads consommateurs sont toujours actifs. Même après la suppression d'un groupe, les threads consommateurs peuvent continuer à s'exécuter s'ils n'ont pas été explicitement arrêtés. Ces threads continuent de valider les décalages, ce qui déclenche des alertes d'accumulation.
Avant de commencer
Arrêtez tous les threads consommateurs du groupe avant d'appliquer l'une des solutions suivantes. Un thread consommateur est actif s'il s'abonne aux messages via la méthode subscribe. Tant qu'un thread valide les décalages, les alertes persistent, quelles que soient les autres actions entreprises.
Solution
Réinitialiser les décalages du consommateur
Cette approche fonctionne sur toutes les versions serveur et constitue le moyen le plus rapide d'interrompre les alertes.
Assurez-vous que le groupe existe dans la console. Si vous l'avez déjà supprimé, recréez-le.
Déconnectez tous les threads consommateurs.
Dans la console ApsaraMQ for Kafka, réinitialisez le décalage du consommateur à 0 pour les partitions dont vous souhaitez arrêter le suivi de l'accumulation. Pour obtenir la procédure détaillée, consultez la rubrique Réinitialiser les décalages du consommateur.
Après la réinitialisation, le système d'alerte cesse de suivre l'accumulation pour ces partitions.
Supprimer directement le groupe (version serveur 2.2.0 ou ultérieure)
Si votre instance exécute la version serveur 2.2.0 ou une version ultérieure et que le groupe ne comporte aucun thread consommateur actif, vous pouvez supprimer directement le groupe. Le serveur supprime alors à la fois le groupe et ses décalages du consommateur.
Si les alertes persistent après la suppression, vérifiez qu'aucun thread consommateur ne continue de valider les décalages.
Attendre l'expiration des décalages (versions serveur antérieures à 2.2.0)
Sur les anciennes versions serveur, les décalages du consommateur sont automatiquement effacés à l'issue de la période de rétention, à condition qu'aucun thread consommateur ne les mette à jour. Pour consulter ou ajuster cette période de rétention, reportez-vous à la rubrique Modifier les configurations des messages.
Mettre à niveau la version serveur (versions serveur antérieures à 2.2.0)
Si le groupe ne contient aucun thread consommateur actif, mettez à niveau la version serveur vers la version 2.2.0 ou une version ultérieure. Après la mise à niveau, recréez le groupe puis supprimez-le afin d'effacer les décalages. Pour connaître la procédure de mise à niveau, consultez la rubrique Mettre à niveau les versions des instances.
Désactiver les alertes d'accumulation de messages
Si aucune des solutions précédentes ne résout le problème, désactivez la règle d'alerte relative à l'accumulation de messages dans CloudMonitor. Pour plus de détails, consultez la rubrique CloudMonitor.
Sur les versions serveur 2.2.0 et ultérieures, les décalages du consommateur ne sont pas supprimés tant que le groupe compte au moins un thread consommateur actif, même si les décalages dépassent la période de rétention définie. Pour en savoir plus, consultez la rubrique Pourquoi les décalages du consommateur ne sont-ils pas supprimés après leur expiration ?.