Journaux d’assistance

En plus d’utiliser le nœud support afin de récupérer vos informations d’assistance, vous pouvez récupérer les journaux Docker, les journaux AWS et les ID des requêtes HTTP pour résoudre les problèmes.

Sommaire du document :

• Récupération des journaux (localement)
• Informations des journaux de plantage (sur site)
• Récupération des journaux Kubernetes
• Récupération des journaux (AWS)
• Collecte des ID de requête HTTP

Consultez Contacter l’assistance pour savoir comment ouvrir un ticket auprès de l'assistance directe.

Récupération des journaux Docker

Utilisation de WADebug (recommandée)

Vous pouvez utiliser l’outil WADebug pour collecter et importer automatiquement les journaux. La réponse de la commande comporte un run_id que vous pouvez transmettre à l’assistance directe pour accélérer les investigations. Il suffit d’exécuter la commande suivante :

  wadebug logs --send

Remarque : en mode Haute disponibilité/Multiconnect, dans lequel les conteneurs sont installés sur un ou plusieurs hôtes, vous devez vous connecter à chaque hôte, installer WADebug et exécuter la commande ci-dessus. La réponse de chaque exécution réussie de la commande comporte un run_id que vous pouvez transmettre à l’assistance directe pour accélérer les investigations.

Utilisation de Docker

Si vous ne pouvez pas utiliser l’outil WADebug, vous pouvez utiliser la commande docker logs pour récupérer les journaux de chaque conteneur individuellement. Par exemple, pour récupérer les journaux du conteneur waweb, exécutez la commande suivante :

docker logs <container id of waweb> >> waweb.log

Vous pouvez utiliser les différentes options de la commande docker logs pour limiter la taille des fichiers journaux. Par exemple, pour obtenir uniquement les 1 000 dernières lignes des journaux du conteneur waweb, exécutez la commande suivante :

docker logs <container id of waweb> --tail 1000 >> waweb.log

Pour obtenir uniquement les journaux du conteneur waweb compris dans une plage horaire spécifique, exécutez la commande avec les options --since et --until, comme dans cet exemple :

docker logs <container id of waweb> --since 2020-01-20T20:00:00Z --until 2020-01-21T08:00:00Z >> waweb.log

Exécutez la commande pour tous les conteneurs WhatsApp et envoyez ces fichiers à WhatsApp pour analyse et débogage. Consultez la documentation docker logs officielle pour plus d’options.

Remarque : tous les journaux de conteneur utilisent le fuseau horaire UTC+0 (GMT). Vous devez transmettre les horodatages GMT aux paramètres --since et --until.

Utilisation de Docker Compose

Pour obtenir les journaux de tous les conteneurs WhatsApp, exécutez la commande suivante :

WA_API_VERSION=new-whatsapp-version docker-compose logs > debug_output.txt

Remarque : cette commande peut générer des fichiers journaux très volumineux. Consultez la section « Utilisation de Docker » pour découvrir les options permettant de récupérer des journaux plus petits ou pertinents.

Vous pouvez ensuite envoyer ces fichiers à WhatsApp pour analyse et débogage.

Journaux de plantage

Nous avons implémenté un nouveau système de consignation des plantages dans la version 2.53, qui enregistre les fichiers de vidage dès qu’un plantage se produit. Ces fichiers (parfois appelés crash dumps), sont stockés dans le répertoire logs/ où ils sont conservés pendant 30 jours. Les fichiers sont stockés uniquement en local sur les machines et peuvent être récupérés de la même manière que les fichiers journaux. Les fichiers de vidage peuvent contenir des données issues de la mémoire associées au thread qui a planté.

Récupération des journaux Kubernetes

Utilisation de kubectl

Pour obtenir les journaux d’un service déployé spécifique, comme la Webapp, exécutez la commande suivante dans la configuration de Kubernetes :

kubectl logs deployments/whatsapp-web-deployment > whatsapp-web-deployment.txt

Vous pouvez ensuite envoyer le fichier à WhatsApp pour analyse et débogage.

Récupération des journaux AWS

Pour capturer les journaux sur une installation AWS, procédez comme suit :

Choisissez l’option No pour Rollback on Failure afin de vous assurer que les journaux ne seront pas effacés en cas de défaillance

Cela doit être défini lors de l’étape de création/mise à jour de la pile, comme indiqué ci-dessous :

Récupérez les journaux et évènements de création de la pile CloudFormation dans la console CloudWatch

Connectez-vous à votre instance EC2 (si elle a été créée avec succès)

Suivez le guide AWS qui explique comment accéder à une instance EC2 via SSH. Notez que, lors de la création/mise à jour de la pile de l’API WhatsApp Business, vous pouvez choisir d’utiliser un VPC privé ou public. Pour un VPC privé, consultez la section Connexion sécurisée à des instances Linux s’exécutant dans un VPC Amazon privé.

Récupération des journaux

Une fois que vous avez accès au conteneur, veuillez capturer les journaux suivants et les joindre à un ticket d’assistance directe.

1. sudo docker logs ecs-agent > ecs-agent.log
2. Compressez et récupérez /var/log de toutes les instances EC2 créées par la pile.
3. Installez WADebug sur toutes les instances EC2 et exécutez les commandeswadebug logs pour récupérer tous les journaux de conteneur.
4. Si vous n’avez pas pu utiliser WADebug à l’étape 3, exécutez les commandes ci-dessous pour récupérer les journaux manuellement :
   • Exécutez docker ps -a pour obtenir la liste de tous les conteneurs en cours d’exécution et partagez le résultat
   • Exécutez docker logs <docker container id of the core app> >> wacore.log et partagez les journaux
   • Exécutez docker logs <docker container id of the web app> >> waweb.log et partagez les journaux
   • Exécutez docker cp <docker container id of the web app>:/var/log/whatsapp/web.log ./web.log et partagez les journaux
   • Exécutez docker cp <docker container id of the web app>:/var/log/lighttpd/error.log ./error.log et partagez les journaux

Historique de l’activité

Si l’instance EC2 n’est pas créée, alors l’historique de l’activité du groupe de mise à l’échelle automatique approprié est nécessaire. Il est disponible sous console EC2 -> Auto Scaling -> Auto Scaling Groups (Mise à l’échelle automatique -> Groupes de mise à l’échelle automatique). Sélectionnez le groupe approprié pour la pile présentant un problème, puis cliquez sur l’onglet Activity History (Historique de l’activité).

Collecte des ID de requête HTTP

Depuis la v2.21.3, l’API WhatsApp Business génère des ID de requête uniques pour chaque requête HTTP entrante qu’elle reçoit. Ces ID de requête permettent de localiser les journaux liés à une requête particulière afin d’accélérer la résolution des erreurs. Si vous souhaitez signaler un bug, veuillez inclure les valeurs des en-têtes de requête X-Request-ID et X-Internal-Request-IDS dans votre ticket pour nous aider à localiser et à reproduire votre problème.