ApsaraMQ for RabbitMQ:Requêtes courantes pour le dépannage

Prérequis

Vous avez activé la fonctionnalité de gestion des journaux et configuré les index.

Requêtes courantes

• Trouver les adresses IP des producteurs par exchange

• Trouver les adresses IP des consommateurs par file d'attente

• Suivre un message

• Analyser les taux de consommation des files d'attente

• Interroger les messages rejetés

Cette rubrique répertorie les requêtes courantes dans Simple Log Service (SLS). Pour obtenir les étapes détaillées et une description du format des journaux, consultez la section gestion des journaux.

Trouver les adresses IP des producteurs par exchange

Exécutez la requête suivante pour lister les adresses IP des producteurs.

* and Action : SendMessage and Code : 200 | 
select 
  split_part(ResourceName,',',2) as exchange_name, 
  split_part(ResourceName, ',', 3) as routing_key, 
  RemoteAddress as ip_port, 
  count(*) as total_send_num 
group by 
  exchange_name, routing_key, ip_port 
order by 
  total_send_num DESC 
limit 1000000 

Trouver les adresses IP des consommateurs par file d'attente

Exécutez la requête suivante pour lister les adresses IP des consommateurs.

* and Action : PushMessage and Code : 200 | 
select 
  InstanceId as instance_id,
  VHost as virtual_host, 
  Queue as queue_name, 
  RemoteAddress as ip_port, 
  count(*) as push_total_num 
group by 
  instance_id,virtual_host, ip_port, queue_name 
order by 
  push_total_num DESC
limit 10000000

Suivre un message

Exécutez une requête dans la zone de recherche pour suivre un message.

• Suivre un message par ID de message

  InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and ResourceName:msgId=27127757-44dc-4373-afc5-f8ea12f****

  La requête renvoie deux entrées de journal : l'une avec une action SendMessage (Code : 200) et l'autre avec une action PushMessage (Code : 200). Cela indique que le message a été envoyé et transmis avec succès.

  Lorsqu'un client s'abonne en utilisant BasicConsume, vous pouvez suivre le message depuis son envoi jusqu'à sa livraison par le serveur. L'action SendMessage correspond à un appel BasicPublish du client, et l'action PushMessage correspond à la transmission du message par le serveur au client. Si le client récupère le message en utilisant BasicGet, l'Action est BasicGet au lieu de PushMessage.

  Remarque

  • Si les résultats du journal ne contiennent qu'une seule entrée SendMessage mais plusieurs entrées PushMessage or BasicGet, il est possible que le client n'ait pas confirmé le message en appelant BasicAck dans le délai imparti pour la consumption timeout après la première occurrence de PushMessage or BasicGet. Le serveur considère alors que la consommation a échoué et renvoie le message. Pour plus d'informations sur le délai de consommation, consultez la section description des paramètres de la politique de nouvelle tentative de l'instance.

  • Si les résultats du journal contiennent des journaux SendDlqMessage en plus des journaux SendMessage et PushMessage, un journal SendDlqMessage indique que le message actuel a été déplacé vers la file d'attente des messages rejetés.

• Vérifier si un message a été consommé

  InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and Queue:cycleCheckQueue**** and ConnectionId:00163efffe08281f-00004e11-0009732f-799c0af9bc4e4913-96b3**** and  ChannelId:1 and (ResourceName:deliveryTag=90 or Property:deliveryTag=90) and RemoteAddress:"/192.168.XX.XX:XXXX"            

  Obtenez les valeurs de ConnectionId, ChannelId, deliveryTag et RemoteAddress à partir des journaux PushMessage. RemoteAddress correspond à l'adresse IP du client. ConnectionId est l'identifiant unique de la connexion. ChannelId est l'identifiant unique du canal. Le paramètre deliveryTag est l'identifiant unique attribué par le serveur au message. Une entrée de journal DeleteMessage indique que le message a été consommé avec succès par le client.

  La requête renvoie trois entrées de journal. Les valeurs Action incluent DeleteMessage et BasicAck, et le Code pour chacune est 200. Cela indique que le message a été consommé avec succès.

  Remarque

  Si un client définit autoAck=false lors de l'appel à BasicConsume, il doit appeler BasicAck pour confirmer la consommation du message. Le serveur supprime ensuite le message. L'appel à BasicAck doit être effectué dans le délai de consommation qui commence à l'horodatage PushMessage. Si ce délai est dépassé, le serveur considère que la consommation a échoué et renvoie le message au client. Pour plus d'informations, consultez la section description des paramètres de la politique de nouvelle tentative de l'instance.

  • Si le client a appelé BasicAck, mais qu'une requête sur l'état de consommation du message ne renvoie aucune entrée de journal DeleteMessage, la consommation a échoué. Vérifiez la différence de temps entre les entrées PushMessage et BasicAck. Si la différence est supérieure au délai de consommation, l'appel à BasicAck n'est pas valide.

  • Si vous trouvez uniquement des entrées PushMessage et DeleteMessage sans aucune entrée BasicAck, il est possible que le client ait utilisé BasicAck(deliveryTag, multiple=true) pour acquitter tous les messages précédents jusqu'au deliveryTag spécifié en un seul appel.

Analyser les taux de consommation des files d'attente

Exécutez la requête suivante pour vérifier la distribution des actions SendMessage, PushMessage or BasicGet, BasicAck et DeleteMessage. Si les pourcentages de ces quatre actions sont approximativement égaux, les taux de production et de consommation sont équilibrés, avec peu ou pas d'accumulation de messages.

InstanceId:amqp-cn-i7m29o3s**** and Vhost:cycle**** and Queue: cycleCheckQueue**** and (SendMessage or PushMessage or BasicAck  or DeleteMessage)

Dans le panneau Quick Analysis situé sur le côté gauche de la page des résultats de la requête, consultez la distribution du champ Action. Par exemple, la distribution peut être la suivante : BasicAck 25 %, DeleteMessage 25 %, PushMessage 25 % et SendMessage 24 %.

Si vous observez l'un des modèles suivants dans les journaux, analysez la cause probable :

• Aucune entrée DeleteMessage dans les résultats du journal : cela peut se produire si le client a défini autoAck=true lors de l'appel à BasicConsume ou BasicGet. Il est également possible que toutes les requêtes BasicAck du client aient dépassé le délai de consommation, rendant les appels non valides. Pour plus d'informations sur le délai de consommation, consultez la section description des paramètres de la politique de nouvelle tentative de l'instance.

• Le pourcentage d'entrées PushMessage est bien inférieur à celui des entrées SendMessage : cela peut indiquer un nombre insuffisant d'abonnés. Nous vous recommandons d'ajouter davantage de connexions et de créer de nouveaux consommateurs.

• Les pourcentages d'entrées SendMessage et PushMessage sont similaires, mais le pourcentage d'entrées DeleteMessage est bien inférieur : cela peut être dû au fait que de nombreuses requêtes BasicAck ont dépassé le délai de consommation et sont devenues invalides. Pour plus d'informations sur le délai de consommation, consultez la section description des paramètres de la politique de nouvelle tentative de l'instance.

• Les pourcentages d'entrées SendMessage, PushMessage et DeleteMessage sont approximativement identiques, mais le pourcentage d'entrées BasicAck est bien inférieur : vérifiez si votre code utilise BasicAck(multiple=true).

Interroger les messages rejetés

Dans la zone de recherche des journaux, saisissez une requête pour récupérer les messages concernés.

• Message routé vers une file d'attente des messages rejetés en raison de l'expiration du TTL du message

  InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=02a162ba-f842-440f-bfd4-2595dd19****

  La requête renvoie deux entrées de journal. Le champ Code des deux est 200, ce qui indique que les opérations sur les messages ont réussi.

  Une entrée SendMessage correspond à votre appel BasicPublish pour envoyer le message. Une entrée SendDlqMessage indique que le message a été envoyé vers la file d'attente des messages rejetés correspondante après l'expiration de son TTL.

  Remarque

  Cette entrée de journal est générée uniquement si vous avez configuré une file d'attente des messages rejetés.

• Message routé vers une file d'attente des messages rejetés en raison de l'expiration du TTL de la file d'attente

  1. Définissez les propriétés de file d'attente des messages rejetés et le TTL pour la file d'attente.

     Map<String, Object> argument = new HashMap<>();
     argument.put("x-dead-letter-exchange", [exchangeName]);
     argument.put("x-dead-letter-routing-key", [routingKey]);
     argument.put("x-message-ttl", [ttl]);
     channel.queueDeclare([queueName], true, false, false, argument);

  2. Saisissez la requête suivante dans la zone de recherche des journaux pour récupérer les entrées SendMessage et SendDlqMessage.

     InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a****

     La requête renvoie deux entrées de journal : une action SendDlqMessage pour la file d'attente a et une action SendMessage pour la file d'attente b. Le Code des deux est 200. Dans le panneau Quick Analysis sur la gauche, la distribution du champ Action affiche 50 % SendMessage et 50 % SendDlqMessage.

• Appeler BasicReject ou BasicNack avec requeue=false

  InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and (ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a**** or ResourceName:deliveryTag=1)

  Une entrée de journal PushMessage indique que le serveur a transmis un message au client. Après avoir reçu le message, le client appelle BasicReject(requeue=false). L'entrée de journal SendDlqMessage correspondante indique que le message a été routé vers la file d'attente des messages rejetés.