TOC

Comment ajouter le module de journal à Nginx sur Debian 8

introduction

L’administration du serveur ne concerne pas seulement la configuration initiale des services. Cela implique également de superviser ces services et de s’assurer qu’ils fonctionnent le mieux possible. Les fichiers journaux, qui contiennent des informations sur les événements système, constituent l’une des sources de connaissances les plus importantes pour les administrateurs.

Dans le cas d’un serveur Web, tel que Nginx, les journaux contiennent des informations précieuses sur chaque tentative d’accès aux ressources via le serveur Web. Chaque visiteur du site Web et chaque image vue ou fichier téléchargé est méticuleusement enregistré dans les journaux. Lorsque des erreurs se produisent, elles sont également enregistrées dans les journaux. Il est beaucoup plus facile de travailler avec des fichiers journaux bien structurés.

Dans ce guide, nous verrons comment utiliser le module de journalisation de Nginx. Nous allons configurer des fichiers journaux distincts pour différents blocs de serveur, puis personnaliser la sortie de journalisation. Nous ajouterons également des informations supplémentaires sur les demandes (dans l’exemple de ce didacticiel, le temps nécessaire pour répondre à une demande) au journal d’accès au-delà de ce que Nginx inclut par défaut.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

Étape 1 - Création de fichiers de test

Dans cette étape, nous allons créer plusieurs fichiers de test dans le répertoire par défaut du site Web Nginx. Nous allons les utiliser pour tester notre configuration de journalisation.

Lorsque Nginx (ou tout autre serveur Web) reçoit une demande HTTP pour un fichier, il ouvre ce fichier et le transmet à l’utilisateur en transférant son contenu via le réseau. Plus le fichier est petit, plus il peut être transféré rapidement. Lorsque le fichier est intégralement transféré, la demande est considérée comme terminée et le transfert est ensuite consigné.

Dans la suite de ce didacticiel, nous modifierons la configuration de la journalisation pour inclure des informations utiles sur le temps pris par chaque requête. Le moyen le plus simple de tester la configuration modifiée et de constater la différence entre différentes requêtes consiste à créer plusieurs fichiers de test de différentes tailles, qui seront transmis dans un laps de temps différent.

Créons un fichier de 1 mégaoctet nommé + 1mb.test + dans le répertoire par défaut de Nginx en utilisant + truncate +.

sudo truncate -s 1M /var/www/html/1mb.test

De la même manière, créons deux autres fichiers de tailles différentes, les 10, puis 100 mégaoctets, en les nommant en conséquence.

sudo truncate -s 10M /var/www/html/10mb.test
sudo truncate -s 100M /var/www/html/100mb.test

Enfin et surtout, créons un fichier vide également:

sudo touch /var/www/html/empty.test

Nous utiliserons ces fichiers à l’étape suivante pour renseigner le fichier journal avec la configuration par défaut, puis plus loin dans le didacticiel pour illustrer la configuration personnalisée.

Étape 2 - Comprendre la configuration par défaut

Le module de journalisation est un module principal de Nginx, ce qui signifie qu’il n’a pas besoin d’être installé séparément pour être utilisé. La configuration par défaut, cependant, est un strict minimum. Dans cette étape, nous verrons comment fonctionne la configuration par défaut.

Lors d’une nouvelle installation, Nginx enregistre toutes les demandes dans deux fichiers distincts: le journal des accès et le journal des erreurs. Le journal des erreurs, situé dans + / var / log / nginx / error.log +, stocke des informations sur les erreurs de serveur inhabituelles ou dans le traitement de la demande.

Le journal des accès, situé dans + / var / log / nginx / access.log +, est utilisé plus souvent. C’est là que les informations sur toutes les demandes adressées à Nginx sont conservées. Dans ce journal, vous pouvez notamment voir quels fichiers les utilisateurs accèdent, quels navigateurs Web ils utilisent, leurs adresses IP et le code de statut HTTP que Nginx a répondu à chaque demande.

Voyons à quoi ressemble un exemple de ligne du fichier journal d’accès. Commencez par demander le fichier vide créé à l’étape 1 à Nginx afin que le fichier journal ne soit pas vide.

curl -i http://localhost/empty.test

En réponse, vous devriez voir plusieurs en-têtes de réponse HTTP:

En-têtes de réponse Nginx

HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Fri, 09 Dec 2016 23:05:18 GMT
Content-Type: application/octet-stream
Content-Length: 0
Last-Modified: Fri, 09 Dec 2016 23:05:13 GMT
Connection: keep-alive
ETag: "584b38a9-0"
Accept-Ranges: bytes

De cette réponse, vous pouvez apprendre plusieurs choses:

  • + HTTP / 1.1 200 OK + nous dit que Nginx a répondu avec le code de statut +200 OK + nous indiquant qu’il n’y avait pas d’erreur.

  • + Content-Length: 0 + signifie que le document retourné a une longueur nulle.

  • La demande a été traitée le vendredi, le 09 déc. 2016 à 23:05:18 GMT.

Voyons si cela correspond à ce que Nginx a stocké dans son journal d’accès. Les fichiers journaux ne sont lisibles que par les utilisateurs administratifs. Par conséquent, vous devez utiliser + sudo + pour y accéder.

sudo tail /var/log/nginx/access.log

Le journal contiendra une ligne comme celle-ci, correspondant à la demande de test que nous avons émise précédemment.

Entrée du journal d’accès

127.0.0.1 - - [09/Dec/2016:23:07:02 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0"

Nginx utilise Combined Log Format, un format normalisé de journaux d’accès couramment utilisés par les serveurs Web pour assurer l’interopérabilité. Dans ce format, chaque information est délimitée par un seul espace; Les traits d’union représentent des informations manquantes.

De gauche à droite, les catégories sont:

  • L’adresse * IP de l’utilisateur * qui a demandé la ressource. Comme vous avez utilisé + curl + localement, l’adresse pointe sur l’hôte local, + 127.0.0.1 +.

  • * Informations de journalisation à distance. Ce sera toujours un tiret car Nginx ne prend pas en charge cette information.

  • Le * nom d’utilisateur d’un utilisateur connecté * selon l’authentification de base HTTP. Ce sera vide pour toutes les demandes anonymes.

  • La * date de demande *. Vous pouvez voir que cela correspond à la date de nos en-têtes de réponse.

  • Le * chemin de requête *, qui inclut la méthode de requête (+ GET +), le chemin du fichier demandé (+ / empty.text +) ainsi que le protocole utilisé (+ HTTP / 1.1 +).

  • Le * code d’état de la réponse *, qui était «+200 OK +», signifie réussite.

  • La * longueur du fichier transféré *, qui est + 0 + ici parce que le fichier était vide.

  • L’en-tête * HTTP Referer *, qui contient l’adresse du document d’où provient la demande. Dans cet exemple, il est vide, mais s’il s’agissait d’un fichier image, le référent indiquerait la page sur laquelle l’image était utilisée. + L’en-tête HTTP Referer est une orthographe erronée du mot "referrer", qui remonte aux origines de HTTP et fait partie du standard HTTP.

  • Le * user agent *, qui est + curl + ici.

Même une seule entrée de journal dans le journal d’accès contient beaucoup d’informations précieuses sur une demande. Cependant, il manque une information importante. Bien que nous ayons demandé l’emplacement exact de + http: // localhost / empty.test +, seul le chemin d’accès au fichier + / empty.test + se trouve dans l’entrée du journal; les informations sur le nom d’hôte (ici, le + localhost +) sont perdues.

Étape 3 - Configuration d’un journal d’accès distinct

Nous allons ensuite remplacer la configuration de journalisation par défaut (où Nginx stocke un fichier journal d’accès pour toutes les demandes) et obliger Nginx à stocker à la place un fichier journal séparé pour le bloc de serveur par défaut fourni avec l’installation en mode minimal de Nginx. Vous pouvez vous familiariser avec les blocs de serveur Nginx en lisant le Comment configurer des blocs de serveur Nginx sur Debian 7.

Il est recommandé de stocker des fichiers journaux distincts pour chaque bloc de serveur, en séparant efficacement les journaux de différents sites Web. Cela réduit non seulement les fichiers journaux, mais facilite également leur analyse, ce qui permet de détecter les erreurs et les activités suspectes.

Pour modifier la configuration de bloc du serveur Nginx par défaut, ouvrez le fichier de configuration Nginx du bloc de serveur dans + nano + ou dans votre éditeur de texte favori.

sudo nano /etc/nginx/sites-available/default

Trouvez le bloc de configuration + serveur +, qui ressemble à ceci:

/ etc / nginx / sites-available / default

. . .
# Default server configuration
#

server {
   listen 80 default_server;
   listen [::]:80 default_server;

. . .

et ajoutez les deux lignes marquées en rouge à la configuration:

/ etc / nginx / sites-available / default

. . .
# Default server configuration
#

server {
   listen 80 default_server;
   listen [::]:80 default_server;



. . .

La directive + access_log + définit le chemin du fichier dans lequel les journaux d’accès seront stockés, et + error_log + fait la même chose pour le journal des erreurs. Nous utilisons le même répertoire que les journaux par défaut de Nginx (+ / var / log / nginx +), mais avec des noms de fichiers différents. Si vous avez plusieurs blocs de serveur, il est judicieux de nommer les fichiers journaux de manière cohérente et significative, par exemple en utilisant le nom de domaine dans le nom du fichier.

Enregistrez et fermez le fichier pour quitter.

Pour activer la nouvelle configuration, redémarrez Nginx.

sudo systemctl restart nginx.service

Pour tester la nouvelle configuration, exécutez la même demande que précédemment pour notre fichier de test vide.

curl -i http://localhost/empty.test

Vérifiez que la ligne de journal identique à celle que nous avons vue précédemment est écrite dans le fichier séparé que nous venons de configurer.

sudo tail /var/log/nginx/default-access.log

Dans l’étape suivante, nous allons personnaliser le format des journaux dans ce nouveau fichier et inclure des informations supplémentaires.

Étape 4 - Configuration d’un format de journal personnalisé

Ici, nous allons configurer un format de journalisation personnalisé pour que Nginx enregistre des informations supplémentaires (le temps nécessaire au traitement de la demande) et configurera le bloc de serveur par défaut pour utiliser ce nouveau format.

Nous devons définir le nouveau format de journal avant de pouvoir l’utiliser. Dans Nginx, chaque format de journal a un nom unique, global pour l’ensemble du serveur. Des blocs de serveur individuels peuvent être configurés pour utiliser ces formats ultérieurement en se référant simplement à leurs noms.

Pour définir le nouveau format de journalisation, créez un nouveau fichier de configuration appelé + timed-log-format.conf + dans le répertoire de configuration supplémentaire de Nginx.

sudo nano /etc/nginx/conf.d/timed-log-format.conf

Ajoutez le contenu suivant:

/etc/nginx/conf.d/timed-log-format.conf

log_format timed '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" $request_time';

Enregistrez et fermez le fichier pour quitter.

La directive + log_format + définit le nouveau format de journal. L’élément suivant est l’identifiant unique de ce format; Ici, nous utilisons * timed *, mais vous pouvez choisir n’importe quel nom.

Vient ensuite le format de journal lui-même, divisé en trois lignes pour la lisibilité. Nginx expose les informations sur toutes les demandes dans les variables système nommées, précédées du signe dollar. Celles-ci seront remplacées par les informations réelles concernant la demande lors de l’écriture des détails de la demande dans le journal d’accès (par exemple, + $ request_addr + sera remplacé par l’adresse IP du visiteur).

Le format ci-dessus est identique au format de journal commun discuté précédemment avec une différence: l’ajout de la variable système + $ request_time + à la toute fin. Nginx utilise cette variable pour stocker combien de temps la demande a pris en millisecondes et en utilisant cette variable dans notre format de journal, nous demandons à Nginx d’écrire ces informations dans le fichier journal.

Nous avons maintenant un format de journal personnalisé nommé * timed * défini dans la configuration de Nginx, mais le bloc de serveur par défaut n’utilise pas encore ce format. Ensuite, ouvrez le fichier de configuration Nginx du bloc serveur.

sudo nano /etc/nginx/sites-available/default

Recherchez le bloc de configuration + serveur + que nous avons modifié précédemment et ajoutez le nom du format de journal + timed + au paramètre + access_log + comme indiqué en rouge ci-dessous:

/ etc / nginx / sites-available / default

. . .
# Default server configuration
#

server {
   listen 80 default_server;
   listen [::]:80 default_server;

   access_log /var/log/nginx/default-access.log ;
   error_log /var/log/nginx/default-error.log;
. . .

Enregistrez et fermez le fichier pour quitter.

Pour activer la nouvelle configuration, redémarrez Nginx.

sudo systemctl restart nginx.service

Maintenant que tout est configuré, vérifions que cela fonctionne.

Étape 5 - Vérification de la nouvelle configuration

Nous pouvons tester la nouvelle configuration en appelant certaines requêtes à Nginx avec + curl +, comme nous l’avons fait à l’étape 2. Cette fois, nous allons utiliser les exemples de fichiers créés à l’étape 1:

curl -i http://localhost/empty.test
curl -i http://localhost/1mb.test
curl -i http://localhost/10mb.test
curl -i http://localhost/100mb.test

Vous remarquerez que l’exécution de chaque commande suivante prend plus de temps, à mesure que les fichiers s’agrandissent et que le transfert prend plus de temps.

Affiche le journal des accès après avoir exécuté ces demandes.

sudo tail /var/log/nginx/default-access.log

Le journal contiendra désormais plus de lignes, mais les quatre dernières correspondront aux demandes de test que vous venez d’exécuter.

Entrées du journal d’accès

127.0.0.1 - - [09/Dec/2016:23:07:02 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0"
127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /empty.test HTTP/1.1" 200 0 "-" "curl/7.38.0"
127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /1mb.test HTTP/1.1" 200 1048576 "-" "curl/7.38.0"
127.0.0.1 - - [09/Dec/2016:23:08:28 +0000] "GET /10mb.test HTTP/1.1" 200 10485760 "-" "curl/7.38.0"
127.0.0.1 - - [09/Dec/2016:23:08:39 +0000] "GET /100mb.test HTTP/1.1" 200 68516844 "-" "curl/7.38.0"

Vous verrez que les chemins diffèrent à chaque fois, indiquant le nom de fichier correct, et que la taille de la demande augmente à chaque fois. La partie importante est le dernier numéro en surbrillance, qui correspond au temps de traitement de la demande en millisecondes que nous venons de configurer dans notre format de journal personnalisé. Comme vous vous en doutez, plus le fichier est volumineux, plus le transfert prend du temps.

Si tel est le cas, vous avez correctement configuré le format de journal personnalisé dans Nginx!

Conclusion

Bien qu’il ne soit pas particulièrement utile de voir que les fichiers volumineux prennent plus de temps à transférer, le temps de traitement des demandes peut être très utile lorsque Nginx est utilisé pour la gestion de sites Web dynamiques. Il peut être utilisé pour identifier les goulots d’étranglement sur le site Web et trouver facilement les demandes qui ont pris plus de temps que nécessaire.

+ $ request_time + est l’une des nombreuses variables système exposées par Nginx pouvant être utilisées dans des configurations de journalisation personnalisées. D’autres incluent, par exemple, la valeur des en-têtes de réponse envoyés avec la réponse au client. Ajouter d’autres variables au format de journal est aussi simple que de les insérer dans la chaîne de format de journal, comme nous l’avons fait avec + $ request_time +. C’est un outil puissant que vous pouvez utiliser à votre avantage lors de la configuration de la journalisation pour vos sites Web.

La liste des variables pouvant être utilisées avec les formats de journal Nginx est décrite dans la section Nginx.

Related