Journaux du serveur
Vous pouvez consulter les fichiers journaux dans MyKinsta et télécharger des journaux supplémentaires via SFTP. Les fichiers journaux ne peuvent pas être supprimés manuellement et sont conservés pendant 4 jours maximum. Ces fichiers sont précieux pour résoudre les erreurs et identifier d’autres problèmes sur votre site.
Si vous disposez d’un forfait Single 1,25 Mo ou supérieur, WP 60 ou supérieur, ou d’un forfait Agency, vous pouvez contacter notre équipe d’assistance pour ajouter un Splunk Forwarder à votre site. Cet outil indexe vos journaux et les envoie à Splunk, une plateforme tierce conçue pour faciliter la surveillance, la recherche, l’analyse et la visualisation des données des journaux. Pour utiliser Splunk, vous devez disposer d’un compte Splunk avec accès à la plateforme Splunk Cloud.
Voir les journaux dans MyKinsta
Trois types de fichiers journaux sont disponibles dans MyKinsta : error.log, kinsta-cache-perf.log, et access.log.
Dans MyKinsta, allez dans Sites et sélectionnez le site pour lequel vous souhaitez consulter les journaux. Cliquez sur l’onglet Journaux pour ouvrir la page de visualisation des journaux. Utilisez le champ de recherche pour trouver du texte dans le fichier actuel.
error.log
Ce fichier enregistre les erreurs et avertissements PHP générés par votre site WordPress. Il peut inclure :
Erreurs PHP fatales
Avertissements et notifications
Problèmes de compatibilité des extensions/thèmes
Erreurs de limite de mémoire ou de délai d’expiration
Problèmes au niveau du serveur liés à l’exécution de PHP
Utilisez-le pour déboguer les pages cassées, les écrans blancs de la mort et les problèmes d’extensions ou de thèmes.
kinsta-cache-perf.log
Ce fichier enregistre les détails des performances du cache spécifiques à la couche de mise en cache de Kinsta. Il affiche généralement :
Quand une page a été servie à partir du cache ou contournée
Évènements Cache HIT / MISS / BYPASS
Informations sur l’actualisation/la purge du cache
Temps de réponse et mesures associées
Détails sur les raisons pour lesquelles la mise en cache a eu lieu ou non (cookies, réglages de requête, requêtes POST, etc.)
Utilisez-le pour diagnostiquer le comportement de la mise en cache, améliorer les performances ou vérifier si les pages sont correctement mises en cache.
access.log
Il s’agit du journal d’accès au serveur web, qui enregistre toutes les requêtes HTTP effectuées sur votre site. Il comprend :
Adresses IP des visiteurs
URL demandées et chaînes de requête
Codes d’état HTTP (200, 301, 404, 500, etc.)
Horodatages
Méthodes de requête (GET, POST, etc.)
Tailles des réponses et temps de traitement
Utilisez-le pour les audits de sécurité, la surveillance du trafic, la localisation des erreurs 404 et l’analyse des modèles d’accès au site.
Rechercher et filtrer les journaux
Si vous recherchez une entrée de journal spécifique, commencez par filtrer les journaux par période. Ajoutez ensuite une chaîne de recherche pour affiner les résultats. Tout le texte correspondant est mis en évidence, ce qui vous permet d’identifier facilement chaque entrée pertinente.
Télécharger les journaux avec SFTP
En plus des fichiers error.log, kinsta-cache-perf.log, et access.log, vous pouvez également télécharger vos fichiers cache-purge.log et mail.log en utilisant SFTP.
- Connectez-vous à votre site avec SFTP.
- Rendez-vous dans le répertoire logs.
- Dans ce répertoire, vous trouverez vos fichiers journaux. Vous pouvez en télécharger un ou tous.
- Une fois que vous avez téléchargé le(s) fichier(s) log, vous pouvez les ouvrir avec votre éditeur de texte préféré ou les importer dans une application de visualisation de log si vous préférez.
Descriptions des fichiers journaux
Pour chaque fichier journal, le fichier sans date à la fin du nom contient les données de la journée en cours. Les journaux historiques depuis les jours précédents sont nommés avec la date du jour suivant. Par exemple, un fichier access.log nommé access.log-2022-07-25-1658707208 contient les journaux depuis juste après minuit le 24 juillet 2022, jusqu’à juste avant minuit le 25 juillet 2022.
- access.log : Ce fichier est un journal des requêtes Nginx pour la journée en cours.
- error.log : Les erreurs spécifiques, y compris les erreurs PHP, sont enregistrées ici.
- kinsta-cache-perf.log : L’état de l’en-tête du cache (hit, miss, ou bypass) pour les requêtes est enregistré ici.
- cache-purge.log : Ce fichier contient un journal des requêtes aux URL de purge de cache (y compris les URL de purge de cache configurées dans l’extension MU de Kinsta).
- mail.log : Un enregistrement du nombre d’e-mails envoyés depuis votre site chaque heure. Chaque ligne ressemblera à quelque chose comme ceci
[22/Sep/2021:21:56:01 +0000] "H" 1 "no_action"- Le format est
[time] "H" [count] "no_action" “H”et“no_action”sont des constantes qui peuvent être ignorées.
- Le format est
Formats des fichiers journaux
access.log
Chaque ligne ressemblera à quelque chose comme ceci :
kinstahelptesting.kinsta.cloud 98.43.13.94 [22/Sep/2021:21:26:10 +0000] GET "/wp-admin/" HTTP/1.0 302 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0" 98.43.13.94 "/wp-admin/index.php" - - 472 0.562 0.560Format
$http_host_cleaned $remote_addr_kinsta $time_local $request_method $request_uri $server_protocol $status $http_referer $http_user_agent $http_x_kinsta_edge_incomingip $uri $log_x_pull $gzip_ratio $bytes_sent $request_time $upstream_response_timeDescriptions des colonnes
$http_host_cleaned: Nom d’hôte demandé par le client.$remote_addr_kinsta: IP du client qui se connecte.$time_local: Horodatage basé sur UTC pour la transaction.$request_method: Méthode HTTP utilisée (GET/POST/PUT/DELETE) lors de l’accès à la ressource du site.$request_uri: Chemin d’accès complet/raw du site (URI) demandé au site après le domaine.$server_protocol: Protocole utilisé pour accéder au site (HTTP/HTTPS).$status: Code de réponse du site (2xx,3xx,4xx,5xx, etc.).$http_referer: Toute redirection ou balise URL dirigeant la requête vers le site/URI.$http_user_agent: Le type de navigateur ou de processus logiciel du client qui fait la demande.$http_x_kinsta_edge_incomingip: Généralement le même que$remote_addr_kinstaindiquant l’IP du client.$uri: Version nettoyée de$request_uri.$log_x_pull: Informations enregistrées indiquant si la requête a utilisé notre implémentation précédente du CDN de Kinsta (propulsé par KeyCDN). Cette colonne pourrait être supprimée dans un futur proche.$kinsta_compression_ratio: Taux de compression utilisé sur la requête.$bytes_sent: Taille de la requête envoyée.$request_time: Temps total passé sur la requête.$upstream_response_time: Temps nécessaire à PHP pour traiter la requête.
error.log
Chaque ligne ressemblera à quelque chose comme ceci :
2019/06/17 15:29:57 [error] 55810#55810: *360896 FastCGI sent in stderr: "PHP message: PHP Parse error: syntax error, unexpected end of file in /www/kinstahelptesting_610/public/wp-content/plugins/code-snippets/php/admin-menus/class-edit-menu.php(213):eval()'d code on line 10" while reading response header from upstream, client: 126.100.65.37, server: kinstaexample.com, request: "POST /wp-admin/admin.php? page=edit-snippet&id=6 HTTP/1.0", upstream: "fastcgi://unix:/var/run/php7.3-fpm-kinstahelptesting.sock:", host: "kinstaexample.com", referrer: "https://kinstaexample.com/wp-admin/admin.php?page=edit-snippet&id=6Remarque : Certaines erreurs peuvent être suivies d’une trace de pile, qui fournit plus de détails sur une erreur et est utile lors du débogage des erreurs.
Format
UTC timestamp, severity level, error code, error ID, stderr message, client IP, site domain, HTTP/S request type, URI, protocol, upstream process handling request, interal host/port details, referrer URLDescriptions des colonnes
UTC timestamp: Horodatage basé sur UTC pour l’erreur.severity level: Gravité de l’erreur (erreur, avertissement, etc.).error code: ID du processus et du thread.error ID: ID de la connexion.stderr message: Message d’erreur standard.client IP: L’adresse IP qui a fait la requête.site domain: Domaine du site où l’erreur s’est produite.HTTP/S request type: La méthode HTTP utilisée (GET/POST/PUT/DELETE).URI: URL demandée.protocol: Protocole utilisé pour la requête.upstream process handling request: Processus sur le serveur qui a traité la requête.interal host/port details: Nom d’hôte utilisé en interne par le serveur.referrer URL: L’URL d’où provient la requête.
kinsta-cache-perf.log
Chaque ligne ressemblera à quelque chose comme ceci :
Format
$time_local $sent_http_x_kinsta_cache $cache_zone $remote_addr_kinsta $request_method $request_uri $server_protocol $log_cookie $upstream_response_timeDescriptions des colonnes
$time_local: Horodatage UTC de la requête$sent_http_x_kinsta_cache: Statut de la requête de cache (MISS/BYPASS/HIT)$cache_zone: Zone de cache interne désignée pour l’élément mis en cache$remote_addr_kinsta: IP du client distant$request_method: Méthode HTTP/S utilisée pour la requête (GET/PUT/POST/DELETE)$request_uri: Chemin de ressource (URI) de la requête après l’URL$server_protocol: Protocole HTTP vs HTTPS$log_cookie: Cookie associé à l’élément mis en cache$upstream_response_time: Temps nécessaire au CDN en amont pour traiter la requête
cache-purge.log
Chaque ligne ressemblera à quelque chose comme ceci :
Format
$time_local $remote_addr_kinsta $request $upstream_response_timeDescriptions des colonnes
$time_local: Horodatage UTC de la requête$remote_addr_kinsta: IP interne de l’outil demandant la purge du cache$request: Type de requête qui sera POST pour toute purge initiée$upstream_response_time: Temps pour terminer l’action de purge
mail.log
Chaque ligne ressemblera à quelque chose comme ceci :
[22/Sep/2021:21:56:01 +0000] "H" 1 "no_action"Format
[time] "H" [count] "no_action"Descriptions des colonnes
time: Horodatage basé sur UTC"H": Constante qui peut être ignorée.count: Nombre d’e-mails envoyés depuis votre serveur."no_action": Constante qui peut être ignorée.