Surveillance des logs Nginx : commandes clés pour analyser le trafic web et les erreurs

La surveillance des logs Nginx est souvent le moyen le plus rapide de répondre à la question que les gens posent lors d'un incident : « Que se passe-t-il réellement en ce moment ? » Les métriques peuvent vous dire que les erreurs 5xx ont augmenté. Les logs peuvent montrer le chemin, l'amont, le code d'état, l'adresse IP du client et les détails de synchronisation pour les requêtes qui ont échoué.

Les commandes ici utilisent des outils Linux ordinaires : tail, grep, awk, sort, uniq, less et leurs variantes pour logs compressés. Ils ne remplacent pas une véritable plateforme de logs, mais ils sont exactement ce dont vous avez besoin lorsque vous avez un accès SSH à un serveur et que vous avez besoin d'une réponse rapide et défendable.

Comprendre les types de logs Nginx

Nginx génère généralement deux types principaux de logs, configurés dans le fichier nginx.conf ou les fichiers de configuration associés :

Logs d'accès (access.log) : Enregistre chaque requête traitée par le serveur. Ce log est essentiel pour comprendre le comportement des utilisateurs, le volume de trafic, la répartition géographique et les temps de réponse. Par défaut, les champs incluent souvent l'adresse IP, la méthode de requête, l'URI, le code d'état HTTP, la taille de la requête et l'agent utilisateur.
Logs d'erreur (error.log) : Enregistre les informations de diagnostic, les avertissements et les erreurs critiques rencontrées par Nginx lui-même (par exemple, problèmes de configuration, dépassements de délai en amont, épuisement des ressources). Ce log est le premier arrêt pour le dépannage des défaillances côté serveur.

Emplacements standard des logs

Bien que les emplacements puissent être personnalisés, les logs Nginx se trouvent généralement dans les répertoires suivants sur la plupart des distributions :

Type de distribution	Chemin de log par défaut
Debian/Ubuntu	`/var/log/nginx/`
RHEL/CentOS	`/var/log/nginx/`
Installation personnalisée (Source)	Variable, vérifier `nginx.conf`

Nous utiliserons /var/log/nginx/access.log et /var/log/nginx/error.log comme exemples principaux.

1. Surveillance en temps réel avec `tail`

La commande tail est essentielle pour surveiller l'activité actuelle du serveur en temps réel. L'option -f (follow) maintient la sortie défilante en temps réel.

Surveillance du trafic d'accès en direct

Pour voir les nouvelles requêtes arrivant sur le serveur, utilisez tail -f sur le log d'accès :

tail -f /var/log/nginx/access.log

Surveillance simultanée des erreurs

Il est souvent utile de surveiller les erreurs lors des tests de modifications de configuration ou des déploiements. Vous pouvez le faire en exécutant deux sessions de terminal séparées, ou en utilisant un outil comme multitail (s'il est installé) :

tail -f /var/log/nginx/error.log

Astuce : Si vous avez besoin de voir les 100 dernières lignes avant de suivre les nouvelles entrées, utilisez tail -n 100 -f /var/log/nginx/access.log.

2. Recherche et filtrage avec `grep`

grep (Global Regular Expression Print) est le cheval de bataille pour trouver des lignes spécifiques dans les fichiers journaux. Il vous permet de filtrer rapidement les logs en fonction des codes d'état, des adresses IP, des méthodes, etc.

Trouver des codes d'état HTTP spécifiques

Lors du dépannage, identifier rapidement toutes les requêtes ayant abouti à une erreur spécifique est crucial. Nous utilisons des espaces autour du code d'état pour éviter les faux positifs provenant de nombres similaires (par exemple, éviter de faire correspondre 200 dans 2000).

Trouver toutes les erreurs 404 (Non trouvé) :

grep " 404 " /var/log/nginx/access.log

Trouver toutes les erreurs serveur 5xx :

grep -E " 50[0-9] " /var/log/nginx/access.log

Filtrer par chemin de requête ou adresse IP

Pour voir toutes les requêtes effectuées par une adresse IP cliente spécifique ou toutes les tentatives d'accès à un chemin spécifique (par exemple, /admin) :

# Filtrer par adresse IP cliente
grep "192.168.1.10" /var/log/nginx/access.log

# Filtrer les tentatives d'accès à une URL spécifique
grep "/wp-login.php" /var/log/nginx/access.log

Filtrage en temps réel

Vous pouvez rediriger la sortie de tail -f vers grep pour surveiller uniquement des événements spécifiques au fur et à mesure qu'ils se produisent :

# Flux en direct des seules erreurs 5xx
tail -f /var/log/nginx/access.log | grep -E " 50[0-9] "

3. Gestion des logs volumineux et rotatifs

Les fichiers journaux peuvent devenir rapidement volumineux. Nginx utilise généralement des utilitaires de rotation des logs (logrotate) pour compresser les anciens logs avec gzip.

Examiner les fichiers volumineux avec `less`

Au lieu de charger l'intégralité du fichier en mémoire (ce qui peut planter une session de terminal), utilisez less pour le parcourir. less permet également la navigation arrière et la recherche efficace.

less /var/log/nginx/access.log
# Dans less, appuyez sur 'G' pour aller à la fin, 'g' pour aller au début, et '/' pour rechercher.

Rechercher dans les logs compressés avec `zgrep`

Pour rechercher dans les logs rotatifs (fichiers .gz) sans les décompresser manuellement, utilisez les variantes z des commandes courantes (zcat, zgrep).

# Rechercher une erreur 403 dans un fichier journal compressé
zgrep " 403 " /var/log/nginx/access.log.1.gz

4. Analyse structurée avec `awk`, `cut` et `sort`

Les logs Nginx, en particulier ceux utilisant le format combiné standard, sont structurés par des espaces. Cette structure permet à des outils comme awk et cut d'extraire des champs de données spécifiques pour une analyse statistique.

Dans le format combiné par défaut, les champs clés sont généralement :

$1 : Adresse IP distante
$7 : URI demandée
$9 : Code d'état HTTP
$10 : Octets envoyés
$12 : Référent HTTP
$14 : Agent utilisateur

Trouver les pages les plus demandées

Ce pipeline utilise awk pour extraire l'URI ($7), sort pour regrouper les entrées identiques, uniq -c pour les compter, et sort -nr pour les lister numériquement dans l'ordre inverse (le nombre le plus élevé en premier).

awk '{print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr | head -10

Compter les codes d'état

Pour obtenir rapidement une répartition de tous les codes d'état enregistrés dans le log :

awk '{print $9}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr

Exemple de sortie :

Identifier les requêtes à latence élevée (si enregistrées)

Si votre configuration Nginx enregistre le temps de réponse amont ($upstream_response_time), vous pouvez utiliser awk pour trouver les requêtes lentes (par exemple, plus lentes qu'une seconde).

Remarque : Cela suppose que le temps de réponse est le 12ème champ ($12). Vérifiez votre configuration log_format avant de vous fier au numéro de champ.

awk '($12 > 1.0) {print $12, $7}' /var/log/nginx/access.log | sort -nr

Bonnes pratiques pour l'analyse des logs

Utiliser `grep -v` pour l'exclusion

Parfois, vous devez filtrer le bruit courant, comme les vérifications de santé ou les bots bénins connus. L'option -v dans grep inverse la correspondance, affichant les lignes qui ne correspondent pas au motif.

# Afficher les logs d'accès, en excluant toutes les réponses 200 réussies
grep -v " 200 " /var/log/nginx/access.log

# Afficher les logs, en excluant les agents utilisateurs Googlebot connus
grep -v "Googlebot" /var/log/nginx/access.log

Comparer les logs d'accès avec les logs d'erreur

Lorsque vous voyez un pic de réponses 502 ou 504, vérifiez le log d'erreur pour la même fenêtre de temps. Les logs d'accès montrent le résultat côté client. Les logs d'erreur expliquent souvent la raison côté proxy :

grep "upstream" /var/log/nginx/error.log | tail -50
grep -E "connect\(\) failed|upstream timed out|no live upstreams" /var/log/nginx/error.log

Par exemple, un 502 dans le log d'accès plus connect() failed (111: Connection refused) dans le log d'erreur indique un service amont qui n'accepte pas les connexions. Un 504 plus upstream timed out indique un amont lent ou un paramètre de délai d'attente trop bas pour ce chemin de requête.

Faire attention aux numéros de champ

De nombreux exemples supposent le format de log combiné de Nginx. Les configurations de production réelles ajoutent souvent $request_time, $upstream_response_time, $host, $request_id ou des champs d'IP transférée. Avant d'utiliser une commande awk '{print $9}' dans une enquête sérieuse, vérifiez le format actif :

nginx -T 2>/dev/null | grep -A3 "log_format"

Si votre format de log encapsule la requête entre guillemets, les champs awk séparés par des espaces fonctionnent toujours pour les vérifications simples, mais ils sont faciles à mal interpréter pour les agents utilisateurs et les référents car ces valeurs contiennent des espaces. Pour une analyse plus approfondie, envoyez les logs à un analyseur ou utilisez un format tel que l'échappement JSON dans un log d'accès dédié.

Manipulation sécurisée

Les logs d'accès Nginx contiennent des données sensibles comme les adresses IP et potentiellement des paramètres de requête. Assurez-vous que lors du transfert de logs pour analyse, vous utilisez des protocoles sécurisés (SCP/SFTP) et restreignez l'accès au répertoire des logs au personnel autorisé (généralement l'utilisateur root ou syslog).

# Vérifier les permissions
ls -l /var/log/nginx/

Un flux de travail pratique

Commencez par le symptôme. Si les utilisateurs signalent des erreurs, comptez les codes d'état et isolez les chemins défaillants. Si le serveur semble lent, recherchez les champs de temps de requête ou ajoutez-les au format de log avant le prochain incident. Si une IP est bruyante, comptez les principales adresses client :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Puis passez du général au spécifique : code d'état, chemin, erreur amont, fenêtre de temps, modèle client. Conservez les commandes exactes que vous avez utilisées dans les notes d'incident. Elles facilitent grandement la prochaine révision et aident un autre ingénieur à reproduire vos conclusions au lieu de se fier à un vague souvenir de ce à quoi les logs "ressemblaient".

Les logs Nginx sont en texte brut, ce qui est une force lorsque les bons outils sont à portée de main. Connaissez votre format de log, évitez de trop vous fier aux numéros de champ copiés et associez les modèles de logs d'accès aux messages de logs d'erreur avant de décider ce qui s'est cassé.