Lire les logs et diagnostiquer une application en production

Objectif

Un journal permet de transformer un message vague — page blanche, erreur 500, redémarrage ou délai d’attente — en hypothèse vérifiable. Ce guide présente une méthode prudente pour collecter le contexte, corréler les événements et identifier les limites de l’offre sans confondre un problème applicatif avec une indisponibilité de service.

Pour un projet applicatif, reliez cette procédure à un serveur VPS et au guide pour déployer une application depuis Git.

Laravel organise ses journaux en canaux configurés dans config/logging.php, avec notamment single, daily, errorlog, syslog et stack [1]. Les détails effectivement accessibles — fichiers, console, rotation, rétention, téléchargement ou agrégation — dépendent de NovaHoster et de votre forfait.

Prérequis

Vous devez connaître le domaine concerné, l’heure approximative du problème, le commit déployé, l’environnement et l’action qui reproduit l’erreur. Préparez un moyen de tester avec un compte non administrateur et retirez les données personnelles ou secrets avant de partager un extrait de journal.

Confirmez dans l’Espace client si vous avez accès aux logs web, PHP, Node.js, build et système, ainsi qu’à leur durée de rétention. L’absence d’un journal dans l’interface ne signifie pas nécessairement qu’il n’existe pas ; elle peut refléter une limite d’accès ou d’offre.

Procédure

1. Décrire le symptôme. Notez l’URL, la méthode HTTP, le code retourné, le navigateur ou client utilisé, l’heure et la fréquence. Distinguez une erreur constante d’une erreur intermittente : la première oriente souvent vers configuration ou code, la seconde vers timeout, quota, dépendance externe ou processus.

1. Identifier le déploiement. Relevez le commit, la branche et les changements récents. Si l’erreur a commencé juste après une mise en ligne, comparez avec la dernière version fonctionnelle. Un retour arrière peut confirmer une régression, mais ne doit pas être réalisé sans considérer les migrations et les données.

1. Consulter les journaux disponibles. Commencez par le journal correspondant au chemin : build pour une installation échouée, serveur web pour un 404/502, PHP ou Laravel pour une exception, processus Node.js pour un crash, base de données pour une connexion refusée. Utilisez la fonction prévue par l’interface ; l’accès SSH, la console, l’export ou le suivi en temps réel sont à confirmer selon l’offre.

1. Filtrer par fenêtre temporelle. Cherchez l’heure du test, le code d’erreur, le chemin et un identifiant de requête s’il existe. Ne copiez pas tout le fichier. Un extrait comprenant quelques lignes avant et après l’erreur suffit généralement, après anonymisation.

1. Analyser Laravel. Recherchez storage/logs, le canal actif et le niveau configuré. Laravel propose huit niveaux de gravité, d’emergency à debug, et permet d’écrire via la façade Log [1]. Vérifiez aussi les permissions de storage et bootstrap/cache, que Laravel doit pouvoir écrire en fonctionnement [2].

1. Analyser Node.js. Distinguez une exception non gérée, un rejet de promesse, un port déjà occupé, une variable absente, une dépendance manquante et un arrêt par la plateforme. Ajoutez des messages structurés et non sensibles autour des étapes critiques. Les valeurs de process.env sont des chaînes ; une comparaison ou conversion incorrecte peut donc produire un comportement inattendu [3].

1. Comparer avec les ressources et limites. Un dépassement de mémoire, de durée d’exécution, de stockage de logs, de connexions ou de processus peut interrompre une application même si le code est correct. Les seuils et métriques accessibles varient selon le forfait : demandez à NovaHoster la limite exacte et l’horodatage observé plutôt que d’estimer.

1. Reproduire avec un test minimal. Testez une route de santé, puis une route dépendant de la base et enfin l’action en erreur. Pour Laravel, une route de santé peut retourner 200 ou 500 selon le démarrage de l’application [2]. Pour Node.js, vérifiez que le processus écoute le port fourni par l’environnement et que le serveur n’est pas limité à localhost lorsque la plateforme exige une écoute externe.

1. Corriger puis vérifier. Modifiez une cause à la fois, déployez un commit identifiable et relancez le même test. Confirmez que les logs ne contiennent pas de mot de passe, jeton, cookie, en-tête d’autorisation ou donnée personnelle. Réduisez ensuite le niveau de verbosité si le diagnostic est terminé.

1. Préparer l’escalade. Un ticket efficace comprend le service, le domaine, l’environnement, le commit, la période UTC ou locale, le code HTTP, le message exact anonymisé, les étapes de reproduction et les vérifications déjà réalisées. Ne communiquez jamais les secrets dans le ticket.

Cas d’erreur et diagnostic

Quand contacter l’Espace client

Contactez NovaHoster si vous ne voyez pas les journaux nécessaires, si les accès semblent insuffisants, si l’application est arrêtée par une limite de mémoire ou de durée, si un processus ne redémarre pas, si un domaine renvoie 502/503 malgré un code fonctionnel, ou si vous devez connaître la rétention, le quota de stockage, le nombre de processus et les options de suivi. Fournissez un extrait anonymisé et les informations de contexte ; ne transmettez pas de clé ou de mot de passe.

Maillage interne suggéré

• [Déployer une application depuis Git sur NovaHoster](#guide-1--déployer-une-application-depuis-git-sur-novahoster)
• [Configurer les environnements Laravel et Node.js](#guide-2--configurer-les-environnements-dune-application-laravel-ou-nodejs)
• [Comprendre les codes HTTP 404, 500 et 502]
• [Réduire et faire tourner les journaux applicatifs]
• [Vérifier les quotas et limites de son offre NovaHoster]

Sources techniques

[1] Laravel — Logging [2] Laravel — Deployment [3] Node.js — Environment Variables

Note éditoriale commune — limites d’offre et exactitude

NovaHoster peut proposer plusieurs niveaux de service. Les fonctions telles que déploiement Git automatisé, accès SSH, sélection de version PHP/Node.js, tâches cron, workers persistants, file d’attente, logs centralisés, métriques, restauration, compilation longue ou redémarrage automatique peuvent être conditionnées par le forfait, la région, la configuration du site ou les droits du compte. Ce bundle ne les présente pas comme garanties générales. Pour chaque projet, la source de vérité est l’Espace client et, en cas de doute, la confirmation écrite du support NovaHoster.

Références générales

Les affirmations techniques de ce bundle s’appuient sur les documentations officielles suivantes :

[1] Laravel — Configuration [2] Laravel — Deployment [3] Laravel — Logging [4] Git — git-remote [5] Node.js — Environment Variables [6] Node.js — The difference between development and production

*Document préparé pour NovaHoster — version éditoriale à valider contre les libellés et capacités exacts de l’Espace client.*