ApsaraMQ for RabbitMQ:Logs

Prérequis

• Une instance ApsaraMQ for RabbitMQ est créée. Pour plus d'informations, consultez la rubrique Gérer les instances.

• Le service Simple Log Service est activé et un projet ainsi qu'un Logstore sont créés. Pour plus d'informations, consultez la rubrique Présentation de la gestion des ressources.

• Créez le rôle lié au service AliyunServiceRoleForAmqpLogDelivery et accordez-lui les autorisations requises lorsque vous y êtes invité dans la console. Ce rôle permet de transférer les journaux vers votre service Simple Log Service.

Facturation

• ApsaraMQ for RabbitMQ

  L'utilisation de la fonctionnalité message log management est gratuite.

• Simple Log Service

  Une fois que ApsaraMQ for RabbitMQ a transféré les journaux vers Simple Log Service, des frais vous sont facturés pour le stockage, le trafic et les requêtes. Pour plus d'informations, consultez la rubrique Éléments facturables en mode paiement à l'utilisation.

Format des journaux

Procédure

Pour transférer les journaux de votre instance ApsaraMQ for RabbitMQ vers Simple Log Service, configurez une destination.

1. Connectez-vous à la console ApsaraMQ for RabbitMQ. Dans le volet de navigation de gauche, cliquez sur Instances.

2. Dans la barre de navigation supérieure de la page Instances, sélectionnez la région où se trouve l'instance que vous souhaitez gérer. Ensuite, dans la liste des instances, cliquez sur le nom de l'instance à gérer.

3. Dans le volet de navigation de gauche, cliquez sur Log Management.

4. Sur la carte My Resources, cliquez sur Authorize Now.

   Si vous avez déjà accordé à ApsaraMQ for RabbitMQ les autorisations d'accès à Simple Log Service, ignorez cette étape.

5. Sur la page Log Management, sélectionnez le projet et le Logstore que vous avez créés dans les listes déroulantes Project Name et Logstore, puis cliquez sur Enable.

6. Connectez-vous à la console Simple Log Service. Activez et configurez les index de champs pour vos journaux. Pour plus d'informations, consultez la rubrique Créer des index.

7. Ajoutez manuellement le champ __tag__:__receive_time__ et définissez son alias sur timestamp.

Tutoriels

• Requêtes courantes pour le dépannage

• Comment générer des métriques à la seconde près

• Compter les opérations d'envoi/réception de messages par file d'attente pour identifier les files d'attente à coût élevé

  Lorsque la console ApsaraMQ for RabbitMQ ne fournit pas de ventilation de la facturation au niveau des files d'attente, utilisez les journaux d'opérations dans Simple Log Service pour compter indépendamment les opérations de messages par file d'attente et localiser les files d'attente à forte consommation, sans dépendre de l'extraction des données backend.

  Dans Simple Log Service, interrogez les journaux d'opérations de votre instance ApsaraMQ for RabbitMQ et exécutez l'instruction de requête suivante pour agréger le nombre d'opérations SendMessage, PushMessage et BasicGet par file d'attente dans une plage de temps spécifiée, triées par nombre d'opérations par ordre décroissant :

  Action: SendMessage OR Action: PushMessage OR Action: BasicGet | SELECT Queue, Action, COUNT(*) AS operation_count GROUP BY Queue, Action ORDER BY operation_count DESC LIMIT 100

  Action	Description
  SendMessage	Un producteur envoie un message à ApsaraMQ for RabbitMQ.
  PushMessage	Le broker pousse un message à un consommateur.
  BasicGet	Un client consommateur extrait un message.

  Les résultats indiquent quelles files d'attente ont le débit de messages le plus élevé. Utilisez ces résultats pour identifier la source des coûts élevés et prioriser l'optimisation sans attendre l'extraction des données backend.

FAQ

Q : Pourquoi existe-t-il un décalage temporel entre l'horodatage du journal client et l'heure de réussite de la livraison du serveur dans ApsaraMQ for RabbitMQ ?

R : Pour résoudre cet écart, suivez les étapes suivantes :

1. Vérifiez d'abord les journaux côté serveur. Interrogez les journaux d'opérations dans Simple Log Service pour vérifier que le serveur a livré le message avec succès et sans délai. Filtrez par Action: PushMessage OR Action: DeleteMessage et confirmez que la valeur du champ Code est 200. Si les journaux côté serveur sont normaux, le serveur n'est pas à l'origine du décalage temporel.

2. Examinez l'environnement client. Si les journaux côté serveur ne montrent aucun problème, l'écart est généralement causé par le côté client. Vérifiez les conditions suivantes :

   • Latence réseau ou perte de paquets : Des problèmes réseau intermittents entre le client et le service ApsaraMQ for RabbitMQ peuvent retarder l'accusé de réception du message côté client.

   • Utilisation élevée du CPU : Un CPU fortement sollicité peut retarder l'exécution des méthodes d'envoi de messages (par exemple, convertAndSend), ce qui entraîne un décalage de l'horodatage enregistré par le client par rapport à l'heure réelle de livraison du serveur.

   • Pauses Full GC fréquentes : Les événements JVM Full GC suspendent tous les threads de l'application, ce qui peut augmenter considérablement le temps entre l'appel d'une méthode d'envoi et la livraison effective du message. Cela amène le journal client à enregistrer un horodatage ultérieur à l'heure de livraison du serveur.

Q : Comment analyser la cause d'un problème après avoir reçu un journal d'alarme ou une notification d'alerte d'ApsaraMQ for RabbitMQ ?

R : Lorsque vous recevez un journal d'alarme ou une notification d'alerte, suivez ces étapes pour identifier la cause racine :

1. Localisez le lien de la console dans le journal d'alarme. Les journaux d'alarme incluent une URL qui vous dirige vers la page de surveillance ou de gestion pertinente dans la console cloud. Trouvez cette URL dans le contenu du journal d'alarme.

2. Ouvrez la page Task Details. Cliquez sur l'URL dans le journal d'alarme pour accéder directement à la page Task Details ou à la page de surveillance du cluster. Cette page fournit le contexte de l'alarme, les métriques associées et la chronologie des événements pour vous aider à diagnostiquer le problème sous-jacent.

3. Mettez en corrélation avec les journaux d'opérations. Recoupez l'horodatage de l'événement d'alarme avec les journaux d'opérations dans Simple Log Service pour identifier les opérations de messages corrélées (telles que les échecs de connexion, les rejets de messages ou le routage vers les files d'attente de lettres mortes) qui se sont produites au même moment et ont pu contribuer à l'alarme.