Guides

Gérer les alertes de surveillance

Ce document fournit des descriptions et indique les actions à entreprendre liées aux alertes définies dans les tableaux de bord de surveillance. Si vous ne parvenez pas à régler un problème, vous pouvez soumettre un ticket d’assistance directe en y joignant les captures d’écran des tableaux de bord et les journaux appropriés.

Alertes sur le tableau de bord de l’entreprise cliente

Alerte critique sur l’échec de l’API

Description

Le taux de réussite de l’API contacts ou de l’API messages est faible.

Actions à entreprendre

  1. Identifiez les codes d’erreur de l’API dans les panneaux Requests/sec (Requêtes par seconde) de l’API contacts ou messages.
  2. Consultez la documentation sur les codes d’erreur.
  3. Vérifiez dans les panneaux CoreApp Requests/sec (Requêtes de Coreapp par seconde) et DB Queries/sec (Requêtes de base de données par seconde) s’il s’agit d’échecs liés au Coreapp ou à la base de données.
  4. Pour plus d’informations, consultez le tableau de bord CoreApp Overview (Vue d’ensemble du CoreApp) (associer la variable Node au Coreapp qui pose problème) et le tableau de bord MySQL Overview (Vue d’ensemble de MySQL).

Alerte sur l’absence de statistiques

Description

Données de surveillance manquantes

Actions à entreprendre

  1. Accédez au point de terminaison des cibles Prometheus (c’est-à-dire http://your-monitoring-hostname:9090/targets) pour vérifier que l’état des statistiques webstats et appstats est UP.
  2. Si Prometheus ne peut pas se connecter au Webapp, exécutez WADebug pour résoudre les erreurs.
  3. Si les conteneurs Webapp et Coreapp s’exécutent, vérifiez que WA_WEB_ENDPOINT, WA_WEB_USERNAME et WA_WEB_PASSWORD sont valides dans le fichier .env.

Alertes du tableau de bord Coreapp Overview

Alerte sur l’échec du rappel

Description

Le taux de réussite de l’envoi de rappels à l’URL de webhook indiquée dans les paramètres de l’application est faible.

Actions à entreprendre

  1. Identifiez les codes d’erreur de réponse aux rappels dans le panneau Callback Requests/sec (Requêtes de rappel/seconde).
  2. Recherchez network error avec Grep dans les journaux du Coreapp afin de voir les messages d’erreur.
  3. En fonction des codes d’erreur et des messages :
    • Vérifiez si le Coreapp peut atteindre votre webhook.
    • Vérifiez que votre webhook renvoie toujours une réponse HTTPS 200 OK après avoir traité les notifications.
    • Vérifiez si votre webhook met longtemps à répondre.

Alerte sur le nombre élevé de messages sortants en attente

Description

La file d’attente des messages sortants est presque saturée ; les requêtes d’API échoueront bientôt avec le message System overloaded error (1016).

Actions à entreprendre

  1. Vérifiez s’il y a une augmentation de trafic inhabituelle sur la ligne Outgoing Messages (Messages sortants) du panneau. Si le trafic inhabituel augmente, essayez de réduire la charge du trafic jusqu’à ce que l’alerte disparaisse.
  2. Vérifiez si votre base de données a basculé récemment dans une autre région. L’API WhatsApp Business risque de ne pas faire face à la charge en raison de la latence interrégionale.
  3. Si les messages sortants s’accumulent au fil du temps, merci de nous signaler le bug.
  4. Si un seul client de l’API WhatsApp Business ne parvient pas à répondre à vos besoins en matière de charge, configurez Multiconnect afin de pouvoir traiter des charges beaucoup plus importantes.

Remarque : dans de rares cas, le tableau de bord affiche une utilisation à plus de 100 % de la file d’attente de messages sortants, due à l’implémentation sous-jacente de la file d’attente. Les actions à entreprendre restent les mêmes.

Alerte sur le nombre élevé de rappels en attente

Description

La file d’attente des rappels est presque saturée ; les requêtes d’API échoueront bientôt avec le message System overloaded error (1016).

Actions à entreprendre

  1. Vérifiez dans le panneau Callback Error Rate (Taux d’erreurs de rappel) que les rappels sont traités correctement.
  2. Réduisez le temps de traitement du rappel pour votre webhook.
  3. Configurez max_concurrent_requests dans les paramètres de l’application pour augmenter le nombre de requêtes de rappel simultanées (par défaut, la valeur est 6).

Alerte sur le taux d’erreur des transactions de la base de données

Description

Le taux d’erreur des opérations de transaction de la base de données (transaction, commit, rollback) est élevé.

Actions à entreprendre

  1. Identifiez la base de données et l’opération problématiques dans le panneau DB Transactions/sec (Transactions de base de données par seconde).
  2. Recherchez QSqlError avec Grep dans les journaux du Coreapp afin de voir le code et le message d’erreur SQL.
  3. En fonction du code et du message d’erreur :
    1. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
    2. Si l’erreur indique un problème de schéma ou une requête SQL erronée, envoyez un ticket d’assistance directe pour investigation.

Alerte sur le taux d’erreur des requêtes de lecture dans la base de données

Description

Le taux d’erreur des opérations de lecture dans la base de données (select, prepare) est élevé.

Actions à entreprendre

  1. Identifiez la base de données et l’opération problématiques dans le panneau DB Read Queries/sec (Requêtes de lecture dans la base de données par seconde).
  2. Recherchez QSqlError avec Grep dans les journaux du Coreapp afin de voir le code et le message d’erreur SQL.
  3. En fonction du code et du message d’erreur :
    1. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
    2. Si l’erreur indique un problème de schéma ou une requête SQL erronée, envoyez un ticket d’assistance directe pour investigation.

Alerte sur le taux d’erreur des requêtes d’écriture dans la base de données

Description

Le taux d’erreur des opérations d’écriture dans la base de données (insert, update, delete, etc.) est élevé.

Actions à entreprendre

  1. Identifiez la base de données et l’opération problématiques dans le panneau DB Write Queries/sec (Requêtes d’écriture dans la base de données par seconde).
  2. Recherchez QSqlError avec Grep dans les journaux du Coreapp afin de voir le code et le message d’erreur SQL.
  3. En fonction du code et du message d’erreur :
    1. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
    2. Si l’erreur indique un problème de schéma ou une requête SQL erronée, envoyez un ticket d’assistance directe pour investigation.

Alerte de latence moyenne (ms) des transactions de base de données

Description

La latence moyenne des opérations de transaction de la base de données (transaction, commit, rollback) est élevée.

Actions à entreprendre

Nous recommandons une latence de base de données inférieure à 15 ms pour profiter d’un débit de messages élevé.

  1. Identifiez la base de données lente dans le panneau Average DB Transaction Latency(ms) (Latence moyenne des transactions de base de données (ms)).
  2. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
  3. Utilisez mysqlslap ou pgbench pour mesurer la latence XACT avec des clients simultanés.
  4. Suivez les recommandations de débit élevé pour configurer votre base de données de façon similaire.

Problèmes courants

  • L’instance de la base de données manque de puissance de calcul (CPU), de mémoire, d’espace disque, d’IOPS ou de connexions.
  • L'instance de la base de données s’exécute sur disque magnétique, et non sur SSD.
  • L'instance de la base de données se trouve dans une région différente de votre Coreapp et les transferts de données sur le réseau ont une latence élevée.

Alerte de latence moyenne (ms) des requêtes de lecture dans la base de données

Description

La latence moyenne des opérations de lecture dans la base de données (select, prepare) est élevée.

Actions à entreprendre

Nous recommandons une latence de base de données inférieure à 15 ms pour profiter d’un débit de messages élevé.

  1. Identifiez la base de données lente dans le panneau Average DB Read Query Latency(ms) (Latence moyenne des requêtes de lecture dans la base de données (ms)).
  2. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
  3. Utilisez mysqlslap ou pgbench pour mesurer la latence de lecture avec des clients simultanés.
  4. Suivez les recommandations de débit élevé pour configurer votre base de données de façon similaire.

Problèmes courants

  • L’instance de la base de données manque de puissance de calcul (CPU), de mémoire ou de connexions.
  • L'instance de la base de données se trouve dans une région différente de votre Coreapp et les transferts de données sur le réseau ont une latence élevée.

Alerte de latence moyenne (ms) des requêtes d’écriture dans la base de données

Description

La latence moyenne des opérations d’écriture dans la base de données (insert, update, delete, etc.) est élevée.

Actions à entreprendre

Nous recommandons une latence de base de données inférieure à 15 ms pour profiter d’un débit de messages élevé.

  1. Identifiez la base de données lente dans le panneau Average DB Write Query Latency(ms) (Latence moyenne des requêtes d’écriture dans la base de données (ms)).
  2. Assurez-vous que votre base de données s’exécute correctement en consultant le tableau de bord MySQL Overview (Vue d’ensemble de MySQL) ou le tableau de bord de votre propre base de données.
  3. Utilisez mysqlslap ou pgbench pour mesurer la latence d’écriture avec des clients simultanés.
  4. Suivez les recommandations de débit élevé pour configurer votre base de données de façon similaire.

Problèmes courants

  • L’instance de la base de données manque de puissance de calcul (CPU), de mémoire, d’espace disque, d’IOPS ou de connexions.
  • L'instance de la base de données s’exécute sur disque magnétique, et non sur SSD.
  • L'instance de la base de données se trouve dans une région différente de votre Coreapp et les transferts de données sur le réseau ont une latence élevée.

Alerte de latence moyenne (ms) des requêtes de retour

Description

La latence moyenne des requêtes de retour adressées à l’URL de webhook indiquée dans les paramètres de l’application est élevée.

Actions à entreprendre

Nous recommandons une latence de retour inférieure à 80 ms pour profiter d’un débit élevé.

  1. Effectuez un test de référence avec votre serveur de webhook et procédez à un profilage pour identifier les goulots d’étranglement.
  2. Réalisez les opérations non critiques de manière asynchrone et renvoyez une réponse HTTPS 200 OK immédiatement.
  3. Augmentez le nombre des serveurs de webhooks derrière votre équilibreur de charges, s’ils n’ont pas suffisamment de ressources système.

Alerte de requêtes de connexion au serveur

Description

Le Coreapp perd constamment la connexion aux serveurs WhatsApp. Les connexions instables ont un impact sur les performances des messages du Coreapp et provoquent des échecs au niveau des API.

Actions à entreprendre

  1. Recherchez « Stream error » avec Grep dans les journaux du Coreapp pour voir l’erreur et le message de connexion perdue, ainsi que la fréquence des pertes de connexion.
  2. Si la connexion est perdue périodiquement pendant plusieurs heures, un redémarrage du Coreapp peut atténuer ces problèmes.
  3. Maintenez les journaux et soumettez un ticket d’assistance directe pour investigation.

Alerte de messages déchiffrés par seconde

Description

Le Coreapp ne parvient pas à déchiffrer assez vite les messages entrants provenant du serveur WhatsApp, et cela déclenche la perte de la connexion.

Actions à entreprendre

  1. Assurez-vous que la base de données s’exécute correctement en vérifiant le panneau DB Read/Write/Transaction Latency (Latence de lecture/écriture/transaction de base de données). Nous recommandons une latence de base de données inférieure à 15 ms pour profiter d’un débit élevé. Effectuez les actions à entreprendre de la section Alerte de latence moyenne des requêtes d’écriture dans la base de données (ms) ci-dessus pour résoudre les problèmes de base de données.
  2. Vérifiez si votre instance du Coreapp manque de puissance de calcul (CPU). Si tel est le cas, passez à une instance plus performante.
  3. Maintenez les journaux et soumettez un ticket d’assistance directe pour plafonner les messages entrants du côté du serveur WhatsApp.

Alertes du tableau de bord de présentation de la machine

Alerte sur l’utilisation intensive de l’UC

Description

L’utilisation de l’UC d’une machine est trop intensive

Actions à entreprendre

  1. Consultez le panneau CPU Detailed Util % (Détails de l’utilisation du processeur %) pour connaître la répartition de l’utilisation du processeur.
  2. Exécutez atop ou top sur la machine pour identifier les processus qui sollicitent le plus le processeur. Il peut également être utile de consulter le tableau de bord Container Overview (Vue d’ensemble du conteneur) pour voir les métriques d’utilisation du processeur au niveau du conteneur en associant la variable Machine à la machine qui pose problème.
  3. Si le Webapp, le Coreapp ou la base de données consomme la plus grande partie de l’UC, procurez-vous une machine plus puissante pour les héberger. En mode Haute disponibilité/Multiconnexion, si les conteneurs du Webapp et du Coreapp s’exécutent sur la même machine, essayez d’en déplacer un sur une machine distincte.

Alerte sur l’utilisation intensive du disque

Description

L’utilisation du disque d’un appareil est trop intensive

Actions à entreprendre

  1. Exécutez les commandes du et df sur l’appareil pour analyser l’utilisation du disque. Il peut également être utile de consulter le tableau de bord Container Overview (Vue d’ensemble du conteneur) pour voir les métriques d’utilisation du disque au niveau du conteneur en associant la variable Machine à la machine qui pose problème.
  2. Supprimez les données inutiles qui consomment de l’espace sur l’appareil ; s’il contient des fichiers multimédia ou des journaux, configurez une tâche cron pour nettoyer régulièrement les anciennes données.

Alerte sur l’utilisation intensive de la mémoire

Description

L’utilisation de la mémoire d’une machine est trop intensive

Actions à entreprendre

  1. Consultez le panneau Memory Details (Informations détaillées sur la mémoire) pour voir la répartition de l’utilisation de la mémoire.
  2. Exécutez atop ou top sur la machine pour identifier les processus qui sollicitent le plus la mémoire. Il peut également être utile de consulter le tableau de bord Container Overview (Vue d’ensemble du conteneur) pour voir les métriques d’utilisation de la mémoire au niveau du conteneur en associant la variable Machine à la machine qui pose problème.
  3. Si le Webapp, le Coreapp ou la base de données consomme la plus grande partie de la mémoire, procurez-vous une machine plus puissante pour les héberger.
  4. Si l’utilisation de la mémoire Coreapp augmente lentement au fil du temps, c’est probablement dû à une fuite de mémoire ; merci de nous signaler le bug. Redémarrez le Coreapp pour minimiser les problèmes de mémoire.

Alerte sur le trop grand nombre de fichiers ouverts

Description

La machine va bientôt dépasser la limite en descripteurs de fichiers

Actions à entreprendre

  1. Consultez le panneau File Descriptor (Descripteur de fichier) pour connaître le nombre limite de fichiers ouverts simultanément.
  2. Spécifiez une valeur supérieure (fs.file-max = 600000, par exemple) dans le fichier /etc/sysctl.conf pour augmenter cette limite.
  3. Exécutez sysctl -p pour appliquer les modifications.

Alertes du tableau de bord de présentation de MySQL

Alerte sur le trop grand nombre de connexions à la base de données

Description

Le pool de connexion à la base de données est élevé ; les nouvelles requêtes risquent d’échouer avec le message d’erreur Too many connections.

Actions à entreprendre

  1. Consultez le panneau Connections (Connexions) pour voir la limite de connexion actuelle.
  2. Augmentez la valeur des variables système MySQL max_connections (par défaut : 151) dans my.cnf et redémarrez le serveur MySQL. Pour plus d’informations, consultez la documentation sur les variables système du serveur MySQL.
  3. Avec AWS RDS, vous devez migrer vers une instance RDS de plus grande taille. Pour obtenir les instructions correspondantes, reportez-vous à la section sur le dimensionnement de l’instance RDS dans les détails sur le déploiement d’AWS.

Alertes du tableau de bord de présentation de Webapp

Alerte sur le nombre de connexions élevé en attente au serveur HTTP

Description

La file d’attente des connexions au serveur HTTP interne Webapp est presque saturée

Actions à entreprendre

  1. Vérifiez la présence d’un trafic inhabituel sur l’API ou d’une latence élevée des requêtes d’API dans le tableau de bord Business Client (Entreprise cliente).
  2. Pour plus d’informations, vérifiez les journaux du Webapp.
  3. Regardez si le taux d’utilisation de l’UC de Webapp est élevé et, si tel est le cas, trouvez une machine plus puissante pour le Webapp.