Pourquoi mon instance ne transmet-elle pas de données de surveillance ?
Les clusters ApsaraMQ for Kafka déployés avant novembre 2018 ne transmettent pas de données de surveillance ni d'alertes. La console affiche les contrôles de surveillance, mais le cluster sous-jacent n'envoie aucune donnée au système de surveillance.
Pour résoudre ce problème, mettez à niveau votre instance. Après la mise à niveau, le cluster commence à transmettre les données de surveillance et d'alerte. Pour connaître la procédure, consultez Mettre à niveau les versions des instances.
Pourquoi l'état de l'alerte indique-t-il « No data » ?
La cause la plus probable est une version mineure obsolète. Les anciennes versions mineures peuvent ne pas transmettre certaines métriques à CloudMonitor, ce qui empêche l'évaluation des règles d'alerte.
Si la version mineure est déjà à jour et que l'état Status affiche toujours No data , contactez le support technique d'Alibaba Cloud.
Vérifier et mettre à jour la version mineure
Connectez-vous à la console ApsaraMQ for Kafka.
Dans la section Resource Distribution de la page Overview, sélectionnez la région où réside votre instance.
Sur la page Instances, cliquez sur le nom de l'instance.
Sur la page Instance Details, cliquez sur l'onglet Instance Information.
Dans la section Basic Information, vérifiez si une mise à jour Minor Version Update est disponible à côté du champ Minor Version.
Si une mise à jour est disponible, cliquez sur Minor Version Update.
-
Dans le panneau qui s'affiche :
Lisez la section Read Before Upgrade.
Saisissez votre nom dans le champ Emergency Contact.
Saisissez votre numéro de téléphone dans le champ Emergency Contact Number.
Indiquez l'heure de début de la mise à niveau dans le champ Started At.
Cliquez sur OK.
Une fois la mise à jour de la version mineure terminée, la colonne Status du panneau Alert Rules Associated with Resource passe de No data à un état valide tel que OK ou Alert.
Pourquoi un utilisateur RAM ne peut-il pas afficher les données de surveillance ?
L'utilisateur RAM ne dispose pas des autorisations CloudMonitor requises. Attachez la stratégie système AliyunCloudMonitorReadOnlyAccess à l'utilisateur RAM via la console RAM.
Connectez-vous à la console RAM avec votre compte Alibaba Cloud.
Attachez la stratégie
AliyunCloudMonitorReadOnlyAccessà l'utilisateur RAM cible.
Une fois la stratégie attachée, l'utilisateur RAM peut afficher les données de surveillance. Pour obtenir la procédure détaillée, consultez Accorder des autorisations aux utilisateurs RAM.
Puis-je me connecter à une instance ApsaraMQ for Kafka ?
Non. ApsaraMQ for Kafka est un service entièrement géré. L'équipe ApsaraMQ for Kafka exploite et maintient l'infrastructure sous-jacente pour votre compte ; l'accès direct à l'instance n'est donc ni requis ni pris en charge.
Pour surveiller l'état de santé du cluster, utilisez la fonctionnalité monitoring and alerting dans la console. Elle fournit les informations nécessaires sur le cluster sans nécessiter d'accès au niveau de l'instance.
Comment surveiller Apache Kafka open source ?
Pour la surveillance d'Apache Kafka open source, consultez les ressources suivantes :
Pourquoi les alertes d'accumulation de messages persistent-elles après la suppression d'un groupe ?
La suppression d'un groupe ne supprime pas les offsets des consommateurs stockés sur le serveur. Le système d'alerte surveille ces offsets ; les alertes continuent donc tant que les offsets existent.
Ce phénomène s'explique par deux raisons :
Les offsets persistent après la suppression. Dans les versions côté serveur antérieures à la 2.2.0 (basées sur Apache Kafka 0.10.2), l'API Kafka ne prend pas en charge la suppression des offsets des consommateurs. La suppression d'un groupe le retire uniquement de la console. Les données d'offset sous-jacentes restent sur le serveur.
Les threads de consommation sont toujours actifs. Même après la suppression d'un groupe, les threads de consommation peuvent continuer à s'exécuter s'ils n'ont pas été explicitement arrêtés. Ces threads continuent de valider les offsets, ce qui déclenche des alertes d'accumulation.
Avant de commencer
Arrêtez tous les threads de consommation du groupe avant d'appliquer l'une des solutions suivantes. Un thread de consommation actif est un thread qui s'abonne aux messages en utilisant la méthode subscribe. Si un thread continue de valider des offsets, les alertes persistent quelles que soient les autres actions entreprises.
Réinitialiser les offsets des consommateurs (recommandé)
Cette approche fonctionne sur toutes les versions côté serveur et constitue le moyen le plus rapide d'arrêter 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 de consommation.
Dans la console ApsaraMQ for Kafka, réinitialisez l'offset du consommateur à 0 pour les partitions dont vous souhaitez cesser de suivre l'accumulation de messages. Pour connaître la procédure, consultez Réinitialiser les offsets des consommateurs.
Le système d'alerte cesse de suivre l'accumulation pour ces partitions après la réinitialisation.
Supprimer directement le groupe (version côté serveur 2.2.0 ou ultérieure)
Si votre instance exécute la version côté serveur 2.2.0 ou ultérieure et que le groupe ne comporte aucun thread de consommation actif, supprimez directement le groupe. Le serveur supprime à la fois le groupe et ses offsets de consommateurs.
Si les alertes persistent après la suppression, vérifiez qu'aucun thread de consommation ne continue de valider des offsets.
Attendre l'expiration des offsets (versions côté serveur antérieures à 2.2.0)
Sur les anciennes versions côté serveur, les offsets des consommateurs sont automatiquement effacés après l'expiration de la période de rétention configurée, à condition qu'aucun thread de consommation ne les mette à jour. Pour vérifier ou ajuster la période de rétention, consultez Modifier les configurations des messages.
Mettre à niveau la version côté serveur (versions côté serveur antérieures à 2.2.0)
Si le groupe ne comporte aucun thread de consommation actif, mettez à niveau la version côté serveur vers la 2.2.0 ou une version ultérieure. Après la mise à niveau, recréez le groupe puis supprimez-le pour retirer les offsets. Pour connaître la procédure, consultez 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 pour l'accumulation de messages dans CloudMonitor. Pour plus de détails, consultez CloudMonitor.
Dans les versions côté serveur 2.2.0 et ultérieures, les offsets des consommateurs ne sont pas supprimés tant que le groupe comporte au moins un thread de consommation actif, même si les offsets dépassent la période de rétention des offsets des consommateurs. Pour plus d'informations, consultez Pourquoi les offsets des consommateurs ne sont-ils pas supprimés après leur expiration ?
Rubriques connexes
Pourquoi l'alerte affiche-t-elle un nombre d'accumulation différent de celui de la console ?
Le système d'alerte et la console calculent l'accumulation de messages différemment. Un léger écart est normal et n'indique pas de problème.
Les deux utilisent la même formule par partition :
Accumulated messages = Maximum offset - Consumer offsetLe total correspond à la somme sur toutes les partitions. L'écart provient du moment auquel chaque méthode récupère les offsets.
Méthode de calcul de l'accumulation pour chaque système
Console (page Group Details)
La page Group Details récupère l'offset du consommateur et l'offset maximal pour chaque partition via des appels de procédure distante (RPC) distincts et consécutifs. Comme l'intervalle de temps entre ces deux requêtes est faible, le résultat reflète fidèlement l'accumulation réelle à cet instant.
Système d'alerte
Le système d'alerte surveille simultanément tous les groupes de consommateurs et tous les sujets d'une instance. Pour réduire la charge, il regroupe les requêtes d'offset : une requête RPC récupère les offsets des consommateurs pour tous les groupes de consommateurs, puis une autre récupère les offsets maximaux pour toutes les partitions de tous les sujets abonnés. Cela réduit le nombre total de requêtes RPC de m x n x number of brokers à seulement number of brokers, où m représente le nombre de groupes de consommateurs et n le nombre de sujets.
Cette optimisation implique un décalage temporel. Les producteurs continuent d'envoyer des messages entre les deux requêtes groupées, de sorte que les offsets maximaux augmentent tandis que les offsets des consommateurs restent fixes. Cela gonfle l'accumulation calculée.
Exemple : Supposons qu'une partition ait un offset de consommateur de 1 000 et un offset maximal de 1 050 lors de l'exécution de la première requête groupée. Au moment où la seconde requête groupée récupère l'offset maximal 200 ms plus tard, les producteurs ont écrit 30 messages supplémentaires, portant l'offset maximal à 1 080. L'alerte signale 80 messages accumulés (1 080 - 1 000), tandis que la console indiquerait environ 50 (1 050 - 1 000).
Quand les messages expirés entraînent des écarts plus importants
Si le taux de consommation est très lent et l'utilisation du disque élevée, l'instance peut supprimer des messages avant que les consommateurs ne les traitent. Dans cette situation, les offsets des consommateurs pour certaines partitions deviennent inférieurs à l'offset minimal de la partition.
ApsaraMQ for Kafka et Apache Kafka open source gèrent différemment les partitions contenant des messages expirés :
| Comportement | Apache Kafka | ApsaraMQ for Kafka |
|---|---|---|
| Calcul des alertes | Ignore les partitions où l'offset du consommateur < offset minimal | Inclut ces partitions dans le total des alertes |
| Affichage dans la console | Sans objet | Exclut ces partitions du total de la page Group Details |
Étant donné que la console exclut ces partitions anormales alors que le système d'alerte les inclut, la valeur de l'alerte est supérieure à celle affichée par la console. Les captures d'écran suivantes illustrent ce comportement.
La console et l'alerte affichent des totaux différents :
Le total de la console exclut les sujets anormaux :
Le total de la console exclut les partitions où l'offset du consommateur est inférieur à l'offset minimal :
Quelle valeur faut-il privilégier ?
Pour une précision instantanée, utilisez la page Group Details de la console. Elle récupère les offsets par partition avec un décalage temporel minimal.
Pour une surveillance des tendances sur de nombreux groupes de consommateurs, utilisez la valeur d'alerte. Elle est optimisée pour l'échelle, non pour la précision.
Un léger écart entre les deux valeurs est normal. N'effectuez d'investigation que si l'écart est constamment important ou croissant.
Supprimer les alertes d'accumulation indésirables
Ignorer les alertes pour des sujets spécifiques : Réinitialisez les offsets des consommateurs à 0 pour le groupe de consommateurs dans la console ApsaraMQ for Kafka. Le système d'alerte cessera de signaler l'accumulation pour ces sujets.
Désactiver complètement les alertes d'accumulation : Ouvrez un ticket pour désactiver temporairement la fonctionnalité d'alerte d'accumulation de messages.
Foire aux questions sur les métriques
Quelles métriques dois-je surveiller ?
Concentrez-vous sur les métriques suivantes en fonction de votre type d'instance.
Instances réservées
| Métrique | Ce qu'elle surveille | Importance |
|---|---|---|
instance_disk_capacity(%) |
Utilisation du disque sur l'instance | Une utilisation élevée du disque peut entraîner des échecs de production de messages. Surveillez cette métrique pour éviter la saturation du stockage. |
InstanceInternetRxUtilizationByNode(%) |
Utilisation de la bande passante Internet entrante par nœud | Des valeurs élevées soutenues indiquent qu'un nœud approche sa limite de bande passante, ce qui peut causer des retards de messages. |
InstanceInternetTxUtilizationByNode(%) |
Utilisation de la bande passante Internet sortante par nœud | Des valeurs élevées soutenues indiquent qu'un nœud approche sa limite de bande passante, ce qui peut ralentir le débit des consommateurs. |
Proportion of Production Traffic in Instance Type(%) |
Débit des producteurs par rapport à la limite de spécification de l'instance | Des valeurs proches de 100 % signifient que le débit de production atteint le plafond de la spécification de l'instance. |
Proportion of Consumption Traffic in Instance Type(%) |
Débit des consommateurs par rapport à la limite de spécification de l'instance | Des valeurs proches de 100 % signifient que le débit de consommation atteint le plafond de la spécification de l'instance. |
Proportion of Partitions in Instance Type(%) |
Nombre de partitions par rapport à la limite de spécification de l'instance | Des valeurs proches de 100 % signifient que vous devez mettre à niveau la spécification de l'instance ou réduire le nombre de partitions. |
Instances Serverless
| Métrique | Ce qu'elle surveille | Importance |
|---|---|---|
InstanceMessageInputRatioV3(%) |
Taux d'entrée des messages en pourcentage de la capacité | Indique à quel point la production de messages à l'échelle de l'instance est proche de la limite de capacité. |
InstanceMessageOutputRatioV3(%) |
Taux de sortie des messages en pourcentage de la capacité | Indique à quel point la consommation de messages à l'échelle de l'instance est proche de la limite de capacité. |
InstanceMaxNodeInputRatioV3(%) |
Taux d'entrée maximal sur le nœud le plus sollicité | Identifie les nœuds critiques. Surveillez cette métrique pour détecter une répartition inégale de la charge entre les nœuds. |
InstanceMaxNodeOutputRatioV3(%) |
Taux de sortie maximal sur le nœud le plus sollicité | Identifie les nœuds critiques. Surveillez cette métrique pour détecter une répartition inégale de la charge entre les nœuds. |
Pourquoi certaines valeurs de métriques sont-elles imprécises ?
Trois causes courantes :
Faible volume de trafic. Le système calcule chaque métrique selon une formule spécifique. Lorsque le trafic est faible, de petites fluctuations produisent des écarts disproportionnés dans le résultat.
Version du client obsolète. Les anciennes bibliothèques clientes Kafka omettent des paramètres dont dépend le système de surveillance, ce qui fausse les valeurs rapportées. Mettez à jour vers la dernière version du client pour corriger ce problème.
Compression des données. Les producteurs compressent les données pour répondre à des exigences spécifiques de transmission ou de stockage. Cela peut entraîner des écarts dans les données de surveillance.
Pourquoi la sortie de messages est-elle nulle alors que la sortie de requêtes est supérieure à zéro ?
Ce comportement est normal, il ne s'agit pas d'une erreur. Il se produit lorsque les consommateurs sont actifs mais qu'aucun nouveau message n'a été publié sur le broker.
Les consommateurs Kafka interrogent continuellement le broker pour obtenir de nouveaux messages, même lorsqu'aucun n'est disponible. Chaque interrogation est enregistrée comme une requête de consommation, de sorte que InstanceReqsOutput et TopicReqsOutput s'incrémentent à chaque tentative. Comme aucun message n'est effectivement livré, InstanceMessageOutput et TopicMessageOutput restent à zéro.
Exemple : Supposons qu'aucun producteur ne publie de messages tandis qu'un groupe de consommateurs interroge le broker 50 fois. TopicReqsOutput affiche 50, mais TopicMessageOutput affiche 0. Dès qu'un producteur recommence à publier, les deux métriques commencent à s'incrémenter conjointement.
