ApsaraMQ for RabbitMQ:FAQ

Interrogation avec la stratégie AliyunAMQPReadOnlyAccess

La stratégie AliyunAMQPReadOnlyAccess accorde uniquement les autorisations amqp:Get* et amqp:List*. Pour accéder aux messages d'une file d'attente, ajoutez l'autorisation personnalisée amqp:BasicGet. Pour plus d'informations, consultez la section Référence des stratégies personnalisées ApsaraMQ for RabbitMQ.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "amqp:BasicGet"
            ],
            "Resource": [
                "acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
            ],
            "Effect": "Allow"
        }
    ]
}

Accumulation de messages après la purge d'une file d'attente

Par défaut, l'opération de purge ne supprime pas les messages différés.

Mécanisme QoS

En cas de délais d'expiration ou de blocages, définissez la QoS ou le nombre de prélecture (Prefetch Count) sur 1. Cette configuration empêche le client de mettre en cache un trop grand nombre de messages susceptibles d'expirer simultanément.

Distribution des messages dans la file des lettres mortes

Un message sans valeur TTL est envoyé vers la file des lettres mortes uniquement s'il fait l'objet d'un accusé de réception négatif (NACK) ou si son nombre de tentatives atteint la limite maximale.

Définition d'un ID de message

Pour plus d'informations, consultez la section Comment définir un ID de message.

Diminution du nombre de messages dans les files des lettres mortes

ApsaraMQ for RabbitMQ conserve les messages pendant une durée maximale de 3 jours. Si un message n'est pas consommé dans ce délai, il est automatiquement supprimé de la file des lettres mortes, ce qui entraîne une diminution du nombre de messages. Pour plus d'informations, consultez la section Limites.

Durée de conservation des messages

ApsaraMQ for RabbitMQ conserve tous les messages pendant une durée maximale de 3 jours, qu'ils aient été consommés ou non. Pour plus d'informations, consultez la section Limites.

Segments réseau RabbitMQ

Les segments réseau des instances ApsaraMQ for RabbitMQ ne sont pas fixes ; il est donc impossible d'obtenir ces informations à l'avance.

Problèmes de suppression automatique des files d'attente

Si un consommateur ne s'est pas abonné avec succès à une file d'attente, l'appel de la méthode channel.close ne déclenche pas la suppression automatique de la file. La logique de suppression automatique n'entre en vigueur qu'après qu'un consommateur se soit abonné avec succès via la méthode channel.basicConsume.

Frais de stockage

ApsaraMQ for RabbitMQ conserve les messages pendant 3 jours. Les frais de stockage sont calculés en fonction du volume de stockage occupé par les corps des messages. Vous ne pouvez pas libérer cet espace de stockage manuellement ; il n'est libéré qu'à l'expiration des messages.

Étant donné que la purge ne supprime pas les messages, elle ne réduit pas l'utilisation de votre espace de stockage.

Purge d'une file d'attente

La purge d'une file d'attente réinitialise le décalage du consommateur, ce qui amène les consommateurs à ignorer les messages non consommés. L'opération ne supprime pas les messages, qui restent accessibles.

Facteurs déterminant le taux de sortie d'une file d'attente

Le taux de distribution des messages d'une file d'attente dépend du volume de messages, du nombre de consommateurs et de leurs paramètres QoS.

Considérations relatives aux files d'attente exclusives

Lorsque vous utilisez le framework Spring en mode CONNECTION, créez l'échange, la file d'attente et les liaisons au préalable dans la console. Le mode CONNECTION ne déclare ni ne crée automatiquement ces ressources.

Facturation des nouvelles tentatives de message

Vous n'êtes facturé qu'une seule fois pour la livraison initiale. Les tentatives suivantes de remise en file d'attente et de consommation n'entraînent pas de frais supplémentaires.

La remise en file d'attente se produit lorsqu'un consommateur échoue à traiter un message et que celui-ci est renvoyé vers une file d'attente serveur. Le serveur utilise une file d'attente de nouvelle tentative dédiée pour redistribuer le message au consommateur à intervalles spécifiques.

Métrique pour la limite TPS

La limite TPS correspond à la métrique Taux maximal de requêtes API par instance dans Cloud Monitor.

Dépassement de la limite de connexions

Bien que la limite de connexions soit documentée comme une limite au niveau de l'instance, elle est appliquée au niveau du nœud backend. Par conséquent, le nombre total de connexions pour une instance peut légèrement dépasser la limite indiquée.

Les configurations des instances d'abonnement ne peuvent pas être ajustées dynamiquement. Nous vous recommandons de planifier soigneusement vos ressources lors de la création d'une instance afin d'éviter de dépasser les limites de ressources et de provoquer des interruptions de service.

Accumulation de messages avec des taux équilibrés

Même si les taux de production et de consommation sont équilibrés, des retards dans l'accusé de réception (ACK) de certains messages peuvent amener les outils de surveillance à signaler une accumulation temporaire de messages à un moment d'échantillonnage donné. Le niveau d'accumulation revient généralement à la normale lors du cycle d'échantillonnage suivant.

Chute soudaine du taux de consommation des pods

Vérifiez les performances du pod. Une utilisation élevée du CPU peut empêcher le client d'envoyer rapidement des accusés de réception (ACK). Si le serveur ne reçoit pas d'ACK, il ne peut pas pousser de nouveaux messages et doit attendre un délai d'expiration avant de réessayer. Cela entraîne une baisse du taux de consommation.

Par exemple, si la QoS est définie sur 1, le consommateur ne peut avoir qu'un seul message non acquitté à la fois. Le serveur doit attendre que le consommateur traite le message et envoie un ACK avant de pouvoir pousser le message suivant. En l'absence d'ACK, le serveur doit attendre un délai d'expiration avant de réessayer.

Utilisation de la clé maître par défaut

Oui.

Erreur : « The channelMax limit is reached »

Le serveur limite le nombre de canaux par connexion, et non le nombre total de canaux sur l'ensemble des connexions.

Cette erreur est enregistrée par le SDK chaque fois que la méthode createChannel renvoie la valeur null.

Après la mise à niveau d'une instance, redémarrez vos clients. Dans le cas contraire, les connexions existantes continueront d'utiliser la limite de canaux antérieure à la mise à niveau, ce qui maintiendra l'erreur.

Par exemple, si une instance est achetée avec une valeur Channel Max de 100, le client et le serveur négocient cette limite lors de l'établissement d'une connexion. Si vous mettez ensuite l'instance à niveau pour prendre en charge 2 000 ou 2 500 canaux, les connexions établies avant la mise à niveau restent soumises à la limite initiale de 100 canaux et continueront de déclencher l'erreur.

Processus de négociation des paramètres de canal

Impact de la mise à niveau des TPS

Non. La mise à niveau de la limite TPS dans la console n'interrompt ni ne déconnecte les connexions existantes.

Nouvelles connexions provoquant l'arrêt des canaux

Normalement, non. Toutefois, l'insuffisance des ressources client, telles que la bande passante réseau, la mémoire ou la capacité JVM, peut entraîner l'interruption d'autres connexions ou canaux. Examinez l'utilisation des ressources du client pour détecter toute contention ou pénurie susceptible de provoquer ces interruptions.

Disparition des consommateurs de file d'attente

Vérifiez en premier lieu la logique applicative du client et l'état des ressources au moment de l'incident. Recherchez des problèmes tels que des processus suspendus ou des pénuries de ressources ayant pu interrompre l'application. Si le client fonctionne correctement, vérifiez ensuite si le serveur distribue les messages comme prévu.

La purge de la file d'attente ne prend pas effet

La purge d'une file d'attente n'efface pas les messages non acquittés (unacked). Il s'agit de messages qui ont été livrés à un client mais n'ont pas encore été acquittés. Le nombre de messages non acquittés est mis à jour automatiquement après l'expiration des messages.

Calcul des TPS à partir des journaux client

Utilisez la requête SQL suivante :

 * and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000

Exemple de résultat :

Journaux vides après modification du Logstore

Dans le nouveau Logstore, cliquez sur Enable Indexing. Attendez environ une minute, puis actualisez la page pour afficher les journaux.

Procédure :

1) Cliquez sur Enable Indexing.

2) Cliquez sur OK.

Causes des déconnexions RabbitMQ

Si un client envoie un faible nombre d'ACK valides, le serveur redistribue les messages de manière répétée car il ne reçoit pas d'accusés de réception. Cela peut entraîner une accumulation persistante de messages.

Cette accumulation de messages côté client peut empêcher la connexion d'envoyer des paquets de maintien de liaison (heartbeat). Cela déclenche finalement une erreur Connection ALL_IDLE et une déconnexion. Vous devez d'abord enquêter sur les raisons pour lesquelles le client n'envoie pas d'ACK valides.

Paramètres TTL

Le TTL maximal est de 3 jours ; tout paramètre supérieur à 3 jours est inefficace. Si le TTL est inefficace, les messages expirés ne sont pas déplacés vers la file des lettres mortes et peuvent provoquer d'autres comportements inattendus.

1) Si aucun TTL n'est défini, tous les messages de la file d'attente sont des messages normaux. La métrique readyMessage dans la surveillance reflète le nombre réel de messages accumulés.

2) Si un TTL est défini, la métrique readyMessage représente le nombre de messages actifs :

a) Si le TTL fonctionne correctement, le nombre de messages actifs est calculé dynamiquement en fonction du TTL. La métrique readyMessage reflète précisément ce nombre.

b) Si le TTL est défini mais n'est pas effectif, le nombre de messages actifs est toujours de 0. La métrique readyMessage indique également 0 et ne reflète pas l'accumulation réelle de messages.

Erreur : « java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768 »

Cette erreur indique que l'en-tête du message a dépassé la limite de taille de trame. La limite par défaut pour un en-tête de message est de 32 Ko et ne peut pas être modifiée sur le serveur.

Pour éviter cette erreur, déplacez les données volumineuses de l'en-tête du message vers le corps du message.

Recherche de messages après la purge d'une file d'attente

La fonction de recherche de messages interroge les données de journalisation, et non la file d'attente active. Étant donné que les journaux sont conservés plus longtemps, vous pouvez trouver des traces de messages même après leur purge de la file d'attente.

Erreur de dissociation d'abonnement

Cause :

Une file d'attente exclusive n'est visible que par la connexion qui l'a déclarée en premier. Par conséquent, elle ne peut être supprimée que par cette connexion spécifique et non depuis la console.

Pour plus d'informations, consultez la section Files d'attente exclusives.

Solution :

1) Si vous n'avez plus besoin de la file d'attente exclusive, déconnectez la connexion correspondante. La file d'attente et ses liaisons seront automatiquement supprimées.

2) Si vous ne trouvez pas l'ID de la connexion qui a créé la file d'attente, supprimez la file d'attente exclusive en redémarrant le client.

Erreur : « VPC flow is not allowed to login in »

Cause :

Le serveur détecte que les identifiants utilisés ne sont pas des identifiants statiques générés depuis la console. Il interprète la demande à tort comme un trafic d'authentification open source et rejette la connexion.

Solution :

Après avoir confirmé la connectivité depuis votre VPC, assurez-vous d'utiliser les identifiants statiques générés dans la console. En cas de doute, nous vous recommandons de régénérer les identifiants.

La création d'instance prend plus de 30 minutes

Étapes de dépannage :

• Vérifiez que le VPC spécifié lors de la création de l'instance existe, appartient à votre compte (UID) et est à l'état Available.

• Vérifiez que le vSwitch spécifié lors de la création de l'instance répond aux exigences. Vous pouvez vous reporter au paramètre VswitchIds de l'API CreateInstance.

Cause :

Ce problème survient généralement lorsque la configuration du VPC ou du vSwitch change pendant le processus de création de l'instance. Par exemple, si le VPC est supprimé après la validation initiale de la requête, la création asynchrone de l'instance échoue.

Solution :

Si les paramètres de création ont changé pendant le processus (par exemple, si le VPC ou le vSwitch a été supprimé), libérez l'instance ApsaraMQ for RabbitMQ et créez-en une nouvelle.

Accès au réseau privé inter-régions

La solution standard pour l'accès au réseau privé inter-régions consiste à utiliser une combinaison de PrivateLink et de Cloud Enterprise Network (CEN).

Notez que cette solution engendre des frais PrivateLink. Pour plus d'informations, consultez la section Points de terminaison PrivateLink.

Erreur lors de la création du point de terminaison PrivateLink : paramètre VPC

Cause :

L'ID du VPC n'existe pas ou le VPC n'est pas à l'état Available.

Solution :

Vérifiez que le Virtual Private Cloud (VPC) sélectionné existe et est à l'état « Available ». Vous pouvez consulter l'état du VPC dans la console VPC.

Erreur lors de la création du point de terminaison PrivateLink : paramètre VSwitch

Cause :

Le vSwitch sélectionné ne remplit pas une ou plusieurs des conditions suivantes :

• Vous devez sélectionner des vSwitches dans au moins deux zones différentes (cela ne s'applique pas à certaines régions à zone unique).

• Le vSwitch doit appartenir au VPC sélectionné.

• Le vSwitch doit être à l'état Available.

• Le vSwitch doit disposer d'au moins 20 adresses IP disponibles.

• La zone où réside le vSwitch doit prendre en charge la création de NLB.

Solution :

• Vérifiez le nombre de vSwitches : pour les régions à zone unique (telles que Nanjing, Fuzhou, Wuhan-Local, Asie du Sud-Est 6, Asie du Sud-Est 7, NE 2 et MEA 1), sélectionnez au moins un vSwitch. Pour les autres régions, sélectionnez des vSwitches dans au moins deux zones différentes.

• Assurez-vous que le vSwitch appartient au VPC sélectionné et est à l'état Available.

• Assurez-vous que le vSwitch dispose d'au moins 20 adresses IP disponibles.

• Assurez-vous que la zone où réside le vSwitch prend en charge la création de NLB.

Erreur lors de la création du point de terminaison PrivateLink : paramètre SecurityGroup

Cause :

Le groupe de sécurité sélectionné ne remplit pas une ou plusieurs des conditions suivantes :

• Le groupe de sécurité doit comporter une règle entrante autorisant le trafic TCP sur les ports de destination 5672 et 5671.

• Les groupes de sécurité gérés ne sont pas pris en charge.

• Le groupe de sécurité doit appartenir au VPC sélectionné.

• Le nombre de groupes de sécurité ne doit pas dépasser le quota de votre compte.

Solution :

• Assurez-vous que le groupe de sécurité comporte une règle entrante autorisant le trafic TCP sur les ports de destination 5672 et 5671.

• Assurez-vous de ne pas avoir sélectionné un groupe de sécurité géré.

• Assurez-vous que le groupe de sécurité appartient au VPC sélectionné.

Erreur : Service PrivateLink non activé

Cause :

Le service PrivateLink n'est pas activé pour votre compte.

Solution :

Activez le service PrivateLink, puis essayez à nouveau de créer le point de terminaison PrivateLink. Pour plus d'informations, consultez la section Qu'est-ce que PrivateLink ?.

Quelles sont les causes d'une IOException ou d'une erreur de connexion sur le client ?

Les éléments suivants peuvent provoquer une IOException ou une erreur de connexion :