Lorsqu’un site WordPress tombe en panne un vendredi après-midi, deux problèmes distincts se posent : réparer le site et déterminer qui en est responsable.
Le deuxième problème prend presque toujours plus de temps. Un développeur pointe du doigt la campagne qui vient d’être mise en ligne. Le responsable marketing pointe du doigt le serveur. L’agence reçoit les appels des deux parties et ne dispose d’aucune donnée propre sur laquelle s’appuyer. Le temps que tout le monde s’accorde sur l’endroit où chercher, la panne a déjà coûté de l’argent, tout comme la dispute.
La cause profonde n’est pas le désaccord entre les équipes. C’est le fait que chaque équipe travaille à partir d’une partie différente des données. Le développeur voit le code. Le responsable marketing voit le trafic. L’agence voit la file d’attente des tickets de support. Personne ne voit la même chose au même moment, donc personne ne peut écarter aucune hypothèse.
L’approche de Kinsta consiste à mettre toutes les équipes sur un pied d’égalité en matière de diagnostic. Les données utilisées par les ingénieurs du support de Kinsta pour analyser un problème, telles que les codes de réponse, les performances PHP, les taux de mise en cache et les journaux de requêtes, sont les mêmes que celles mises à la disposition de tous les utilisateurs de MyKinsta disposant d’un accès aux analyses. Lorsque tout le monde interprète les mêmes signaux, un site en panne devient un problème que l’équipe diagnostique ensemble plutôt qu’un sujet de discorde.
Cela modifie également la manière dont les équipes interagissent avec le support. Ce guide présente les outils de diagnostic disponibles dans MyKinsta, ce que chacun d’entre eux affiche, quand les utiliser et comment les intégrer dans un flux de travail collaboratif plutôt que dans une session de débogage en solo.
Pourquoi les problèmes de performances se transforment en problèmes de responsabilité
Un site WordPress moderne confie rarement l’entière responsabilité à une seule personne. Les développeurs gèrent le code. Les spécialistes du marketing mènent les campagnes. Les agences ou les indépendants s’occupent de la relation avec l’hébergeur. Chaque équipe fait son travail ; le problème est que leurs champs de visibilité ne se recoupent pas.
Lorsqu’un site tombe en panne, ce manque de visibilité transforme discrètement un problème technique en un problème personnel :
- Les développeurs inspectent le code, mais pas le serveur. Leur champ de vision s’arrête à la couche applicative ; une cause côté serveur leur reste donc invisible.
- Les spécialistes du marketing voient le trafic, mais pas la base de données. Un pic lié à une campagne semble être le déclencheur évident, car c’est la seule variable qu’ils peuvent mesurer.
- Les agences traitent la réclamation mais ne disposent d’aucune donnée. Elles deviennent un relais entre les parties plutôt qu’une source de réponses.
En l’absence de point de référence commun, chaque partie suppose que la cause incombe à quelqu’un d’autre. De nombreuses plateformes d’hébergement renforcent discrètement ce schéma en conservant les données de diagnostic au sein de l’équipe d’assistance. Vous ouvrez un ticket et attendez que quelqu’un d’autre consulte les journaux auxquels vous n’avez pas accès.
Kinsta adopte l’approche inverse. Voyons maintenant quels outils utiliser en priorité, et comment les exploiter dans le cadre d’un workflow collaboratif, et non individuel.
Ce que le tableau de bord analytique MyKinsta affiche lorsqu’un problème survient
Lorsqu’un site présente un dysfonctionnement, la première tâche consiste à déterminer de quel type de problème il s’agit. Les sites lents, hors service ou surchargés nécessitent chacun une réponse différente. Se tromper de diagnostic, par exemple en traitant un problème de mise en cache comme un problème de serveur, ou un pic d’erreurs comme un problème de trafic, fait perdre du temps à tout le monde.
C’est dans la section « Analyses » de MyKinsta que ce diagnostic commence.
La section « Analyses » de MyKinsta contient des données au niveau de l’entreprise. Pour un site individuel, rendez-vous dans Sites > nom du site > Analyses. Quoi qu’il en soit, les mêmes rapports sont accessibles à tous les utilisateurs disposant d’un accès aux analyses.
Vérifiez si le site renvoie réellement des erreurs
Avant toute chose, déterminez si le site est réellement en panne ou simplement lent. Ces deux situations ont des causes et des solutions différentes, et c’est en les confondant que les discussions sur les responsabilités commencent.
L’onglet « Réponse » répond à cette question. Son graphique central, la répartition des codes de réponse, montre la répartition des codes d’état HTTP renvoyés par votre site au cours de la période sélectionnée.
Ainsi, une concentration de codes « 5xx » indique un problème au niveau du serveur ou de l’application, tandis que les codes « 4xx » signalent des problèmes d’accès aux ressources. Deux autres graphiques vous permettent d’approfondir l’analyse :
- La ventilation des erreurs 500 distingue les erreurs 500 génériques des erreurs 502 (« Bad Gateway ») ou 503 (« Service indisponible »), qui renvoient à des causes différentes.
- La ventilation des erreurs 400 sépare les codes côté client, en distinguant un afflux de 404 des autres réponses signalant des problèmes d’authentification, d’autorisation ou de limitation de débit.
Comme tous les utilisateurs ayant accès aux analyses consultent la même ventilation, vous pouvez vous attaquer directement à la défaillance spécifique plutôt que de tergiverser.
Distinguer un site lent d’un site défaillant
Un site qui se charge en six secondes et un autre renvoyant des erreurs 500 donneront la même impression à un visiteur frustré, mais leurs causes sont totalement différentes. C’est dans l’onglet « Performances » que vous pouvez les distinguer.
Plusieurs rapports présentés ici méritent d’être consultés lors de toute analyse de site lent :
- Le temps de réponse moyen PHP/MySQL indique le temps nécessaire à l’application pour traiter et interroger chaque requête non mise en cache. Un pic soudain est généralement le premier signe d’une dégradation des performances plutôt que d’un problème d’infrastructure.
- Le débit PHP indique le nombre de requêtes exécutées au cours de la période. Si un ralentissement coïncide avec un pic de débit plutôt qu’avec une modification du code, la cause probable est la charge, et non un bogue.
- L’utilisation d’AJAX met en évidence les pics d’activité dans le fichier admin-ajax.php, une source courante et souvent négligée de consommation des ressources du backend, causée par des extensions et des utilisateurs connectés exécutant des tâches en arrière-plan.
- La liste des « temps d’aller les plus longs » répertorie les chemins individuels les plus lents, ce qui vous permet d’identifier directement la page ou le point de terminaison qui fait grimper la moyenne du site, plutôt que de vous livrer à des conjectures.
Ensemble, ces éléments vous indiquent si la prochaine étape consiste à optimiser l’application ou à signaler une panne.
Vérifier la proportion du site mise en cache
Un site peut sembler lent pour des raisons sans rapport avec le code ou l’infrastructure : une trop faible partie de celui-ci est servie à partir du cache. Lorsque le taux de mise en cache diminue, le serveur traite des requêtes qu’il ne devrait pas avoir à traiter, ce qui augmente les temps de réponse. C’est l’une des causes les plus courantes des discussions du type « est-ce la faute de l’hébergeur ? », alors que ce n’est presque jamais le cas.
La section « Cache » indique comment les requêtes sont traitées à travers les couches de mise en cache de Kinsta.
Chaque requête se résout selon l’un des trois états suivants :
HITsignifie que Kinsta traite la requête à partir du cache, ce qui est souhaitable pour la majeure partie du trafic.BYPASSsignifie qu’une règle ou un conflit empêche la requête d’être mise en cache.MISSsignifie que le contenu n’est pas encore mis en cache, mais qu’il le sera après la première requête.
Le graphique de cache d’un site en bon état de fonctionnement repose largement sur les HIT. Lorsque le taux de contournement (BYPASS) augmente, le rapport « Top server cache bypasses » répertorie les chemins d’accès spécifiques qui contournent le cache.
Certains contournements ne posent pas de problème (comme la page de connexion WordPress, qui n’est jamais mise en cache). Cependant, la présence d’une page pouvant être mise en cache dans cette liste indique un conflit entre plugins ou un problème lié aux règles de mise en cache. Consulter ces rapports tout en observant une page lente vous permet de vérifier si celle-ci est mise en cache, plutôt que de supposer que l’hébergeur est à l’origine du problème.
Identifiez ce qui consomme des ressources
Si un site ne renvoie pas d’erreurs mais consomme plus de bande passante ou de capacité qu’il ne le devrait, vous en trouverez la source dans le rapport « Top des requêtes ». Les problèmes liés aux ressources sont les plus difficiles à cerner : un dépassement de bande passante ou un ralentissement sous charge ne s’accompagne généralement d’aucun code d’erreur.
Trois rapports vous permettent d’identifier précisément la source du problème :
- Le rapport Bande passante du serveur indique quelles URL extraient le plus de données directement depuis votre serveur d’origine.
- La bande passante totale additionne les données servies par le CDN et le cache périphérique, ce qui vous permet de visualiser le poids total de chaque requête.
- La section Vues affiche les ressources les plus sollicitées, quelle que soit leur taille, ce qui permet de mettre en évidence un point de terminaison soumis à une charge constante plutôt qu’un simple fichier volumineux.
Ensemble, ils permettent de déterminer si un pic de demande est dû à un fichier multimédia trop volumineux, à un point de terminaison hors de contrôle ou à un robot d’indexation accédant au même chemin des milliers de fois. À partir de là, la solution consiste généralement à optimiser la ressource, à l’acheminer via un CDN ou à traiter le problème au niveau du point de terminaison.
Si le pic est dû au trafic de robots d’indexation ou de robots, la protection anti-robots de Kinsta vous permet d’identifier, de classer et de bloquer le trafic non humain directement depuis MyKinsta, sans avoir à utiliser d’extension ni à ouvrir de ticket de support.
Comment l’APM remonte à la source d’un problème de performance
Les rapports d’analyse vous indiquent ce qui se passe sur un site. L’outil APM de Kinsta vous explique pourquoi. Là où l’analyse vous montre que le temps de réponse PHP a connu un pic à 14 h, l’APM vous indique quelle fonction d’extension, quelle requête de base de données ou quel appel d’API externe en est à l’origine.
L’APM est inclus dans tous les plans Kinsta et s’exécute directement dans MyKinsta.
Exécutez l’APM sous forme de session, et non en continu
Contrairement au tableau de bord Analytics, qui enregistre en continu en arrière-plan, l’agent APM alourdit la charge sur le processeur et la mémoire de votre serveur pendant qu’il collecte des données. Kinsta recommande de ne l’exécuter que lorsque vous diagnostiquez activement un problème.
Pour démarrer une session, rendez-vous dans Sites > nom du site > APM, cliquez sur Activer APM, puis sélectionnez une fenêtre de surveillance : 2, 4, 12 ou 24 heures. APM se désactive automatiquement à la fin de cette fenêtre.
Cela signifie que votre procédure est simple :
- Lancez l’APM lorsque vous soupçonnez un problème ou que vous pouvez le reproduire, afin que la charge supplémentaire n’affecte pas votre site en fonctionnement normal.
- Choisissez une fenêtre couvrant la période concernée par le problème, puis reproduisez le problème ou attendez qu’il se reproduise afin que l’outil le capture à l’aide de données en temps réel.
- Consultez les résultats une fois les données accumulées, puis désactivez l’APM lorsque vous avez terminé.
Consulter les résultats d’APM
APM organise les données collectées dans quatre onglets : Transactions, WordPress, Base de données et Externe.
Commencez par l’onglet Transactions pour identifier les requêtes les plus lentes. En cliquant sur une transaction, vous ouvrez une chronologie de tous les processus impliqués dans cette requête et mettez en évidence les segments les plus lourds. Cela vous permet de déterminer s’il faut concentrer vos efforts d’optimisation sur une requête de base de données lente, une fonction spécifique d’un plugin ou une API tierce.
L’onglet Externe est particulièrement utile pour écarter la responsabilité de l’hébergeur. Si le ralentissement d’une transaction provient d’un appel à une API externe, les données APM l’indiquent clairement. C’est ce qui fait la différence entre un ticket de support indiquant « le site est lent » et un autre précisant « le ralentissement provient de l’API de notre fournisseur de messagerie, et non du serveur ».
Comment la visionneuse de journaux et le journal d’activité permettent de reconstituer une chronologie
La résolution d’un incident repose généralement sur la connaissance des évènements et de leur ordre chronologique. Deux éléments de MyKinsta vous aident à reconstituer la chronologie : la visionneuse de journaux enregistre les actions du site et le journal d’activité enregistre les actions des utilisateurs.
La visionneuse de journaux vous montre ce que le site signale, et non ses performances. Trois fichiers sont disponibles sur l’écran Journaux pour tout site dans MyKinsta :
error.logenregistre les erreurs et les avertissements PHP ; c’est le premier endroit où chercher la cause d’une page qui ne fonctionne pas.kinsta-cache-perf.logenregistre les performances du cache et indique si les pages sont servies à partir du cache ou si celui-ci est contourné.access.logenregistre chaque requête HTTP qui parvient au site ; c’est là que vous pouvez suivre les tendances de trafic et les erreurs 404 récurrentes.
La visionneuse intégrée affiche jusqu’à 20.000 lignes et dispose d’un champ de recherche permettant de filtrer par n’importe quelle chaîne de caractères. Les journaux peuvent également être téléchargés via le Gestionnaire de fichiers de MyKinsta si vous avez besoin de les traiter dans un outil externe.
Le journal d’activité : ce que les utilisateurs ont fait
Le journal d’activité consigne toutes les actions effectuées dans MyKinsta pour un site par n’importe quel utilisateur, par ordre chronologique.
Vous trouverez les journaux d’activité sous Sites > nom du site > Activité des utilisateurs. Chaque entrée vous permet de voir l’action décrite en langage clair, l’utilisateur, un horodatage et une icône d’état. Ici, une coche verte indique une réussite et un point d’exclamation rouge signale un échec.
Associé à d’autres journaux, cet outil vous aide à diagnostiquer les problèmes. Par exemple, à partir d’un fichier « error.log » renseigné, vous pouvez ouvrir le journal d’activité, le filtrer pour afficher la même fenêtre et identifier toutes les actions associées.
Comment la surveillance de la disponibilité favorise une prise de conscience commune
Les outils ci-dessus sont réactifs. La surveillance de la disponibilité rend la détection proactive : au lieu d’apprendre l’existence d’un problème à la suite d’une réclamation d’un client, vous et Kinsta en êtes informés simultanément.
Kinsta surveille chaque site de la plateforme environ 480 fois par jour. Lorsque les notifications de surveillance sont activées dans Réglages de l’utilisateur > Notifications, vous recevez un e-mail en fonction des domaines nécessitant une attention particulière :
- Les Erreurs de site signalent un problème détecté sur le site lui-même.
- Les Erreurs SSL signalent un problème de certificat ou de configuration avant qu’il ne dissuade les visiteurs.
- Les Expirations de domaine signalent un domaine dont la validité arrive à expiration avant qu’il ne soit désactivé.
Les e-mails sont envoyés après trois vérifications infructueuses consécutives, et non dès la première, ce qui permet de filtrer les incidents passagers qui, sinon, vous inonderaient de fausses alertes.
SIX15 Solutions gère plus de 30 sites clients via ce système de surveillance, dont l’intérêt réside moins dans la vérification elle-même que dans la fréquence à laquelle les problèmes sont résolus avant même que le client ne s’en aperçoive.
J’héberge actuellement plus de 30 sites web de clients dans le cadre de mon plan Agence, allant de petits sites marketing à des sites d’adhésion à part entière comptant des milliers d’utilisateurs, sans aucun problème ni temps d’indisponibilité.
Cependant, toutes les alertes ne signalent pas nécessairement une défaillance. Les alertes de limite de plan vous avertissent lorsque vous atteignez les limites d’utilisation de votre forfait, ce qui constitue un système d’alerte précoce efficace. Cela vous permet de comprendre, grâce à vos analyses, pourquoi vous atteignez une limite, par exemple en raison d’une campagne générant plus de trafic que prévu ou de l’activité de robots d’indexation ou de robots.
Le partage des données met fin aux discussions sur les responsabilités
Un site en panne fait perdre le plus de temps à déterminer les responsabilités et les obligations plutôt qu’à le réparer. Les outils d’analyse de MyKinsta indiquent si un site est lent, hors service ou surchargé. Grâce à l’outil APM, à la visionneuse de journaux, au journal d’activité, à la surveillance de la disponibilité et à bien d’autres fonctionnalités, vous pouvez vous assurer que tout le monde soit informé d’un problème et se mette au travail sans passer par la file d’attente des tickets.
L’objectif est de considérer ces informations comme un flux de travail partagé. Chaque membre de l’équipe disposant d’un accès approprié aux analyses, vous pouvez vous mettre d’accord sur les rapports à utiliser avant même que quiconque n’ouvre un ticket. De cette manière, la discussion reste axée sur le diagnostic au lieu de dégénérer en dispute.
Si vous gérez des sites pour lesquels plusieurs équipes se partagent les responsabilités, l’hébergement WordPress infogéré de Kinsta permet à chacune de ces équipes de participer activement au processus de diagnostic. Si vous gérez des sites clients à grande échelle, le Programme de partenariat pour les agences mérite d’être exploré pour les outils d’accès partagé et de cogestion qu’il propose.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
