journalisation avec NGINX – comment le configurer et ce Qu’il faut surveiller

NGINX est un serveur web performant et fiable, capable de gérer d’énormes quantités de trafic pour les sites Web les plus fréquentés d’internet. Lors du dépannage, vous avez besoin d’un moyen de donner un sens au trafic et NGINX fournit des fonctionnalités de journalisation flexibles pour capturer des détails précieux et vous aider à comprendre le comportement de votre serveur web.

NGINX offre deux fichiers différents pour enregistrer des données de serveur web précieuses., Ces deux fichiers sont error_log et access_log. access_log est utilisé pour stocker des informations sur les demandes des clients web et error_log stocke d’autres messages inattendus ou informatifs.

configuration d’access_log

le fichier access_log collecte toutes les demandes des clients immédiatement après le traitement de la demande, offrant un excellent moyen de consigner les pages que les utilisateurs demandent à votre serveur web., Vous pouvez choisir où les données acess_log sont écrites en utilisant la syntaxe de fichier de configuration suivante:

access_log path ] ];access_log off;

Specifyingformat vous permet d’utiliser un format personnalisé dans vos journaux en utilisant des variables telles que le nombre de bytessent au client (by bytes_sent) ou la longueur de la requête ($request_length).

normalement, NGINX enregistrera chaque transaction qu’il traite dans access_log. Le paramètre if=condition fournit un puissantmanière pour effectuer une journalisation conditionnelle afin qu’il stocke les messages de journal d’accès au journal si une condition est vraie., Par exemple, si vous ne souhaitez enregistrer que les requêtes renvoyant un code D’état HTTP 404, vous pouvez utiliser l’extrait de code suivant:

map $status $should_log {404 1;default 0;}access_log logs/access.log combined if=$should_log;

Avec cette modification, toutes les requêtes complétées avec succès (2xx), redirigées vers une autre page (3xx) ou rencontrées par un servererror (5xx) ne seront pasles erreurs log—only404 seront enregistrées.

Si vous avez plus d’un hôte virtuel ou plusieurs directions http, serveur ou emplacement, il est parfois pratique de pouvoir désactiver la journalisation au niveau de la directive actuelle, et la valeur off spéciale a été créée à cet effet.,La ligne de configuration suivante montre comment vous pouvez empêcher NGINX d’écrire des informations d’accès à n’importe quelle cible access_log au niveau actuel:

access_log off;

Pour une explication plus complète des options de configuration, consultez la documentation NGINX access_log.

Nginx Log Severity Levels

NGINX prend en charge un large éventail de niveaux de sévérité pour faciliter l’enregistrement des informations qui vous intéressent. Chacun de ces niveaux peut être utilisé avec la directive error_log pour définir le niveau minimum auquel les messages sont enregistrés., Voici les niveaux de support dans l’ordre le plus bas à le plus élevé, ainsi qu’un guide sur la façon dont ils sont utilisés:

• Debug – débogage des messages qui ne sont pas utiles la plupart du temps.
• Info-messages D’information qui pourraient être bons à savoir.
• avis-quelque chose de normal mais important s’est produit et il convient de le noter.
• avertir – quelque chose d’inattendu s’est produit, mais ce n’est pas une source d’inquiétude.
• Erreur – quelque Chose a échoué.
• Crit – un état critique est survenu.
• Alerte – une action Immédiate est nécessaire.
• Emerg – Le système est inutilisable.,

configuration de error_log

par défaut, le fichier error_log capture tous les messages de journal au niveau de gravité de l’erreur, ce qui signifie qu’il est principalement utilisé pour comprendre les messages fatals ou critiques pour aider à résoudre les problèmes. L’emplacement par défaut pour error_logis logs / error.journal. La façon dont les messages d’erreur NGINXstores est flexible et—en plus de vous permettre d’écrire des messages dans un fichier—il prend également en charge l’envoi de messages error_logmessages vers stderr ou le démon syslog. Si vous utilisez NGINXopen source 1.5.,2 ou plus récent, vous pouvez également envoyer des messages error_log à plus d’un endroit à la fois en spécifiant plusieurs directives error_log au même niveau de configuration.

Si vous souhaitez enregistrer tous les messages à la sévérité du journal warn ou au-dessus, Modifiez la configuration suivante:

error_log logs/error.log warn;

journalisation vers Syslog avec NGINX

les directives access_log et error_log prennent en charge l’envoi de messages vers un démon syslog en utilisant la chaîne syslog: dans votre configuration., L’extrait de code suivant montre la syntaxe pour utiliser l’une ou l’autre des directives avec un démon syslog:

http {error_log syslog:server;…}

par exemple, si vous voulez diriger tous les messages error_log avec warn ou une sévérité plus élevée vers le syslogdaemon utilisez cette ligne de directive:

error_log syslog:server=192.168.1.1 severity=warn;

vous pour convenir à votre environnement en utilisant le paramètre syslog décrit dans la documentation nginxsyslog.

$ nginx -V 2>&1 | grep—‘—with-debug’configure arguments: --with-debug

error_log memory:32m debug;...http {...}

set $log = ngx_cycle->logwhile $log->writer != ngx_log_memory_writerset $log = $log->nextendset $buf = (ngx_log_memory_buf_t *) $log->wdatadump binary memory debug_log.txt $buf->start $buf->end