[Web] Nginx coupe automatiquement les journaux d’accès

Le journal d’accès web (access_log) enregistre le comportement d’accès de tous les clients externes au serveur web, incluant des informations importantes telles que l’IP du client, la date d’accès, la ressource URL accédée, le code d’état HTTP retourné par le serveur, etc.
Un journal d’accès web typique ressemble à ceci :

112.97.37.90 - - [14/sept/2013:14:37:39 +0800] « GET / HTTP/1.1 » 301 5 « - » « Mozilla/5.0 (Linux ; U; Android 2.3.6 ; zh-cn ; Lenovo A326 Version/GRK39F) AppleWebKit/533.1 (KHTML, comme Gecko) Version/4.0 Mobile Safari/533.1 MicroMessenger/4.5.1.259" -

Planification :

1. Pour résoudre le problème :

Lorsque le site reçoit un grand nombre de visites, il y aura beaucoup de données de journal, et si tout est écrit dans un fichier journal, le fichier deviendra de plus en plus grand. La vitesse des gros fichiers ralentira, comme des centaines de mégaoctets d’un fichier. Lors de l’écriture de journaux, cela affecte la vitesse de fonctionnement. Aussi, si je veux regarder les journaux d’accès, un fichier de plusieurs centaines de mégabits est lent à télécharger et à ouvrir. En utilisant un outil tiers gratuit d’analyse de journaux - Log Treasure, vous pouvez télécharger des fichiers journaux depuis nginx, apache et iis, qui aident à analyser les aspects de sécurité des sites web. Après tout, se spécialiser est plus professionnel. Log Bao a également une limite de taille pour les fichiers téléchargés, pas plus de 50 m.

2. Nignx ne dispose pas de mécanisme pour séparer automatiquement les fichiers et stocker les journaux. Puisque nginx ne sauvegarde pas automatiquement les fichiers pour vous. Par conséquent, vous devez écrire votre propre script pour l’implémenter.

Le fichier script shell nginx_log_division.sh le contenu suivant :

# /biche/coup

logs_path="/data/wwwlogs/ »

#以前的日志文件.

log_name="xxx.log »   

pid_path="/usr/local/nginx/logs/nginx.pid »

mv ${logs_path}${log_name} ${logs_path}${log_name}_$(date --date="LAST WEEK » +" %Y- %m-d »).log

kill -USR1 'cat ${pid_path}'

Le principe du script shell ci-dessus est de déplacer et renommer le fichier journal précédent en un, le but étant de sauvegarder.

Selon le nom du dernier lundi, lorsque le script est exécuté au moment « 2013-09-16 », le nom du fichier généré est « xxx.log_ 20130909.log ».

Même si la commande mv a été exécutée sur le fichier avant que kill -USR1 'cat ${{pid_path}' ne soit exécutéNom de fichier modifié, nginx continuera d’écrire les données de journal dans le nouveau fichier nommé « xxx.log_20130909 » comme d’habitude. La raison en est que dans les systèmes Linux, le noyau recherche les fichiers en fonction des descripteurs de fichiers.

---------------- compréhension des descripteurs de fichiers Linux

Un descripteur de fichier est un identifiant entier que le noyau Linux nomme pour chaque fichier ouvert.

Le noyau Linux génère (ou maintient) un "Table des descripteurs de fichiersCette table descripteur de fichiers enregistre « le fichier ouvert par ce processus (identifié) ».

Dans cet environnement, nginx est un processus en cours d’exécution qui a déjà ouvert un fichier journal et enregistre le fichier dans la table des descripteurs du fichier.

Même si le chemin du fichier journal a changé, il peut toujours être trouvé (il peut être localisé selon la table des descripteurs du fichier).

----------------------------------------------

Lors de l’exécution de la commande « kill -USR1 'cat ${pid_path}' », ce que vous enregistrez dans le fichier nginx.pid est en réalité un chiffre (vous pouvez l’ouvrir et regarder, je suis 894 ici), et nginx écrit le pid (numéro de processus) de son processus principal dans le fichier nginx.pid, vous pouvez donc obtenir directement son numéro de processus principal via la commande cat et opérer directement le numéro de processus spécifié.

kill -USR1 'cat ${pid_path}' équivaut à

kill – USR1 894 #指定发信号 (USR1) signal pour numéroter ce processus.

Dans les systèmes Linux, Linux communique avec des « processus en cours » via des signaux. Dans les systèmes Linux, il existe également de nombreux signaux prédéfinis, comme SIGHUP. USR1 est un signal défini par l’utilisateur. On peut comprendre cela comme le processus lui-même définissant ce qu’il doit faire lorsqu’il reçoit ce signal (c’est-à-dire que le concepteur du processus décide lui-même s’il reçoit ce signal ou s’il ne fait rien, et laisse entièrement le soin du développeur de décider). Dans nginx, il écrit son propre code pour gérer la gestion de la réouverture du fichier journal par nginx lorsque je reçois un signal USR1. Le principe spécifique est le suivant :

1. Le processus principal de nginx reçoit le signal USR1 et rouvre le fichier journal (nommé d’après le nom du journal dans le fichier de configuration nginx, qui est la valeur définie par l’élément access_log dans le fichier de configuration, et si le fichier n’existe pas, un nouveau xxx.log de fichier sera automatiquement créé).

2. Puis changer le propriétaire du fichier journal en « processus worker », afin que le processus worker ait les permissions de lecture et d’écriture sur le fichier log (maître et ouvrier s’exécutent généralement comme utilisateurs différents, donc le propriétaire doit être modifié).

3. Le processus principal nginx fermera le fichier journal dupliqué (c’est-à-dire le fichier qui a été renommé en xxx.log_ 20130909.log en utilisant la commande mv récemment),et informe le processus worker d’utiliser le fichier journal nouvellement ouvert(xxx.log le fichier ouvert par le processus principal à l’instant). L’implémentation spécifique est plus détaillée : le processus principal envoie le signal USR1 au travailleur, et après avoir reçu ce signal, le travailleur rouvre le fichier journal (c’est-à-dire le xxx.log convenu dans le fichier de configuration)

=================================== Exécuter des scripts à intervalles réguliers

Configurez le fichier script shell ci-dessus pour être ajouté à la tâche planifiée. crontab est un processus de tâche planifié sous Linux. Ce processus commencera lorsque vous l’activerez, et il ira de temps en temps dans sa liste pour voir s’il y a des tâches à accomplir.

Crontab -e

* 04 * * 1 /data/wwwlogs/nginx_log_division.sh

Un fichier s’ouvrira avec le code ci-dessus ajouté

Le format est « Chemin de fichier shell à exécuter ». * peut être compris comme « à chaque », chaque minute, chaque heure, chaque mois, etc.

J’ai configuré un script pour exécuter nginx_log_division.sh à 4h du matin lundi, et le contenu du script consiste à régénérer un nouveau fichier journal.

Pièce jointe :InstallernginxConfiguration des journaux

log_format site « $remote_addr - $remote_user [$time_local] « $request » »

             '$status $body_bytes_envoyés « $http_référent » '

             '"$http_user_agent » $http_x_forwarded_for' ;

access_log /data/wwwlogs/xxxx.com.log site

#第二个参数表示使用那个日志格式, un nom est identifié pour chaque format de journal, et le site correspond au nom indiqué dans le log_format

Ce qui précède implique l’utilisation du gestionnaire de tâches planifiées Crontab.

Il y a aussi des endroits où il n’y a pas une compréhension complète et des erreurs. J’espère faire des mises à jour à l’avenir.