Journalisation des erreurs et des exceptions PHP

En ce qui concerne les journaux d'erreurs du service Nginx + PHP, nous pensons généralement aux journaux d'accès Nginx, aux journaux d'erreurs et aux journaux d'erreurs PHP. Bien que cela semble être une question très simple, cela implique en fait la configuration de l'application et l'emplacement d'enregistrement du journal. Si vous utilisez apt-get pour l'installer sur un système tel qu'Ubuntu, il dispose de son propre ensemble de fichiers de configuration plus raisonnables. De plus, la configuration dans l'application en cours d'exécution affectera également la méthode et le contenu de la journalisation.

La différence entre les erreurs et les exceptions

Concernant les erreurs et les exceptions, nous pouvons utiliser un exemple simple pour comprendre :

<?php
try {
    1 / 0;
} catch (Exception $e) {
    echo "catched", PHP_EOL;
}

L'exécution de ce petit exemple sera Obtenez directement une erreur "Avertissement PHP : Division par zéro...". La raison est simple : il s’agit d’une erreur logique, pas d’une exception, elle ne peut donc pas être détectée par un essai. De même, si une variable n'est pas définie avant utilisation, un avertissement sera généré au lieu d'être capturé.

Cependant, ce problème a quelques changements dans PHP7. Par exemple, dans l'exemple ci-dessus, j'ai changé / en %, et une fois exécuté dans l'environnement PHP7, j'obtiendrai une invite différente :

PHP Fatal error: Uncaught DivisionByZeroError ...

<. 🎜 >Selon cette astuce, si je modifie les conditions dans catch :

<?php
try {
    1 / 0;
} catch (DivisionByZeroError $e) {
    echo "catched", PHP_EOL;
}

De cette façon, l'erreur peut être capturée normalement et capturée sera sortie.

Pour le premier exemple, si vous remplacez Excepiton par ErrorException, vous pouvez également l'attraper normalement.

Quant à savoir pourquoi le reste et la division sont les mêmes en PHP5 mais la division n'est pas un problème DivisionByZeroError en PHP7 (mon environnement de test est 7.0.4), cela devrait être un BUG.

Enregistrements de journaux

PHP lui-même possède les journaux configurables suivants :

● Journal des erreurs php-fpm (php-fpm. conf, enregistre le démarrage et informations de fin du processus php-fpm)

● Journal lent de php-fpm (également configuré dans php-fpm.conf, enregistre l'exécution lente)

● Journal des erreurs php (configuré dans php .ini, enregistre les journaux d'erreurs d'application)

De plus, Nginx dispose également de deux journaux configurables : un journal d'accès et un journal d'erreurs. Ces fichiers journaux ont des fonctions différentes et des contenus enregistrés différents. Mais il y a un point à noter : si l'emplacement du journal des erreurs dans php-fpm est configuré, mais que l'emplacement du journal n'est pas accessible en écriture (l'emplacement doit être correct lors de la configuration, car php-fpm le vérifiera au démarrage), sous le conditions de configuration appropriées Le journal des erreurs sera renvoyé à cgi et écrit dans le journal des erreurs de nginx.

Ainsi, lorsque nous rencontrons des problèmes, nos idées générales de recherche sont :

1. Vérifiez le code d'état de la requête dans le journal d'accès Nginx

2. Vérifiez l'erreur php. log Enregistrements d'erreurs et informations sur la pile

3. Vérifiez le journal php-fpm pour les enregistrements de redémarrage anormaux (cela se produira s'il y a des problèmes de base ou d'extension)

Mais dans les situations ci-dessus, vous le ferez également. constatez qu'il n'y a aucun enregistrement de journal de l'exception levée par le programme mentionné ci-dessus.

Enregistrement d'exception

L'exception est différente de l'erreur À proprement parler, il s'agit d'une exception de la logique d'application plutôt que d'une erreur. Elle peut être déclenchée manuellement via une logique de programme raisonnable. . Mais dans la plupart des cas, les exceptions doivent également être enregistrées, telles que les exceptions déclenchées par l'impossibilité de se connecter à la base de données ou une mauvaise utilisation du framework. Nous devons utiliser des journaux pour localiser le problème et le traiter en temps opportun.

PHP fournit deux fonctions pour personnaliser les méthodes de gestion des erreurs et des exceptions :

Quantity set_error_handler

Quantity set_exception_handler

Vous pouvez donc utiliser la fonction set_exception_handler La méthode injectée intercepte toutes les exceptions et les enregistre.

monolog est une excellente bibliothèque d'enregistrement d'exceptions et est également basée sur l'implémentation de la norme PSR-3 . Il est également utilisé par défaut dans Laravel et Symfony pour enregistrer les exceptions. Si nécessaire, vous pouvez également envisager de l’introduire dans vos propres projets.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!