Monitoring serveur Linux : top, htop, journalctl et analyse des logs

Pourquoi monitorer un serveur au quotidien

Un serveur ne tombe pas toujours de manière spectaculaire. Dans la majorité des cas, les signaux faibles arrivent avant l'incident : une charge CPU qui monte progressivement, un service qui redémarre en boucle, une saturation mémoire, une file de requêtes qui s'allonge ou des erreurs applicatives qui s'accumulent dans les logs.

Le monitoring quotidien sert justement à repérer ces signaux avant qu'ils ne deviennent un problème utilisateur. Même sans stack d'observabilité complète, un administrateur peut déjà faire beaucoup avec quatre outils très concrets : top pour la vue système immédiate, htop pour naviguer plus confortablement dans les processus, journalctl pour les services pilotés par systemd, et les logs applicatifs pour comprendre la cause métier ou technique.

Cet article complète un guide plus centré sur systemd et journalctl. Ici, l'objectif est différent : construire une méthode simple de diagnostic terrain quand un serveur devient lent, qu'une API renvoie des erreurs ou qu'un service semble instable.

À retenir : le bon réflexe n'est pas de lancer des commandes au hasard, mais d'enchaîner une lecture système, une lecture processus, une lecture service, puis une lecture des logs applicatifs.

Lire rapidement la charge avec top

top est souvent le premier outil à ouvrir quand un serveur répond lentement. Il affiche en temps réel l'état général de la machine : charge moyenne, consommation CPU, mémoire utilisée, swap, ainsi que les processus les plus gourmands.

La première erreur fréquente consiste à regarder uniquement la colonne CPU d'un processus. En réalité, il faut commencer par le haut de l'écran : les load average indiquent la pression globale sur le système, tandis que la ligne CPU permet de distinguer si le temps part en calcul utilisateur, en noyau, en attente d'entrées/sorties ou en inactivité.

top

# Trier par consommation mémoire
Shift + M

# Trier par CPU
Shift + P

# Afficher uniquement certains processus via PID
top -p 1821,2450

# Rafraîchir plus vite
top -d 1

Si la charge monte alors que le CPU reste peu utilisé, le problème peut venir d'une attente disque ou réseau. Si le swap commence à être sollicité, la dégradation des performances peut devenir très rapide. Sur un serveur web, un php-fpm, un node ou un worker queue qui reste en tête longtemps mérite une investigation plus fine.

Attention : un load average élevé n'est pas automatiquement synonyme de CPU saturé. Sur Linux, cette valeur reflète aussi des processus bloqués en attente d'I/O.

Exemple concret : API lente en production

Imaginons une API derrière Nginx qui devient lente à 14 h. Avec top, vous constatez un load average anormalement haut, plusieurs workers php-fpm actifs et très peu d'idle CPU. Cette lecture indique déjà que le souci ne vient pas d'un simple pic réseau : les workers sont réellement occupés et il faut maintenant identifier lesquels.

Diagnostiquer plus vite avec htop

htop n'est pas toujours installé par défaut, mais c'est souvent l'outil le plus agréable pour l'analyse interactive. Là où top donne une vue brute, htop permet de scroller, filtrer, rechercher et visualiser les arbres de processus beaucoup plus facilement.

# Installation sur Debian / Ubuntu
sudo apt update
sudo apt install htop

# Lancer htop
htop

Une fois dans htop, quelques fonctions sont particulièrement utiles :

F3 pour rechercher un processus par nom.
F4 pour filtrer l'affichage et ne garder qu'une famille de processus.
F5 pour afficher l'arbre parent/enfant, très pratique avec Nginx, PM2 ou des workers.
F6 pour changer la clé de tri.
F9 pour envoyer un signal si vous devez stopper un processus bloqué.

Sur un serveur applicatif, htop aide à distinguer un problème ponctuel d'un problème systémique. Si un seul worker consomme toute la mémoire, il faut inspecter sa requête ou sa tâche. Si tous les workers sont actifs simultanément, on penche plutôt vers une saturation de capacité, un backlog ou un incident externe comme une base de données lente.

Bon réflexe : utilisez la vue en arbre pour voir si un process parent relance en boucle ses enfants. C'est très parlant avec des superviseurs ou des services qui crashent puis redémarrent automatiquement.

Exemple concret : worker bloqué

Sur un backend Node.js exécuté par PM2, htop permet souvent de voir immédiatement si un process reste à 100 % CPU, si plusieurs instances ont divergé, ou si une fuite mémoire pousse progressivement le service vers l'OOM killer.

Investiguer les services avec journalctl

Quand l'analyse système montre qu'un service pose problème, journalctl devient la source principale pour comprendre ce qu'il s'est réellement passé. Il est particulièrement utile pour Nginx, PHP-FPM, Docker, des workers personnalisés ou toute application déclarée comme unité systemd.

# Voir les derniers événements d'un service
sudo journalctl -u nginx -n 50

# Suivre les logs en temps réel
sudo journalctl -u php8.2-fpm -f

# Limiter la recherche à la dernière heure
sudo journalctl -u myapp --since "1 hour ago"

# Filtrer les erreurs
sudo journalctl -u myapp -p err

# Afficher avec timestamps précis
sudo journalctl -u myapp -o short-precise

L'intérêt majeur de journalctl est le filtrage temporel. Lorsqu'un incident est signalé à 16 h 42, inutile de relire toute la journée. Vous pouvez vous concentrer sur quelques minutes avant et après l'événement. Cette approche réduit le bruit et fait gagner beaucoup de temps.

Il faut aussi apprendre à relier l'état du processus et le journal système. Si top montre un service qui consomme beaucoup, journalctl dira peut-être qu'il retry une connexion à la base, qu'il a perdu une dépendance réseau, qu'il rencontre une erreur de permission, ou qu'il redémarre après dépassement mémoire.

À ne pas confondre : journalctl raconte la vie du service côté système, mais pas toujours le détail métier d'une requête. Pour ça, il faut compléter avec les logs applicatifs.

Exemple concret : service redémarré plusieurs fois

sudo systemctl status myapp
sudo journalctl -u myapp --since "20 minutes ago"
sudo journalctl -u myapp -p warning --since "20 minutes ago"

Si vous repérez plusieurs redémarrages rapprochés, la cause peut être un crash applicatif, une dépendance inaccessible ou une limite mémoire trop basse dans le fichier d'unité.

Croiser avec les logs applicatifs

Les logs système ne suffisent pas toujours. Sur beaucoup d'architectures, l'information la plus utile se trouve dans les logs applicatifs : erreurs PHP, exceptions Node.js, access logs Nginx, logs de workers, logs de tâches planifiées ou logs produits par un framework.

Voici quelques emplacements classiques à vérifier selon la stack :

/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/apache2/error.log
/var/www/app/storage/logs/laravel.log
/home/node/app/logs/app.log
/var/log/syslog

L'idée n'est pas d'ouvrir tous les fichiers à l'aveugle, mais de croiser les indices. Par exemple :

top montre un pic CPU sur php-fpm.
journalctl ne montre pas de crash de service.
Le error.log Nginx reste calme.
Le log applicatif Laravel révèle une requête SQL très lente ou une boucle d'exception.

Dans ce cas, le diagnostic bascule du niveau système vers le niveau applicatif. Vous savez que le serveur tient encore, mais que l'application consomme mal ses ressources.

# Lire les 100 dernières lignes
tail -n 100 /var/log/nginx/error.log

# Suivre un log applicatif
tail -f /var/www/app/storage/logs/laravel.log

# Chercher rapidement des erreurs
grep -i "error\\|exception\\|fatal" /var/www/app/storage/logs/laravel.log

Conseil pratique : gardez des logs applicatifs horodatés, structurés et cohérents. Des messages vagues comme "Erreur inconnue" rendent le monitoring beaucoup moins utile.

Routine de diagnostic en cas d'incident

Quand un serveur devient lent, la pression pousse souvent à tester mille hypothèses. Une routine fixe permet au contraire de rester efficace. Voici une séquence simple qui fonctionne bien sur la plupart des incidents applicatifs Linux.

1. Confirmer le symptôme

Vérifiez si le problème est global ou localisé : site inaccessible, lenteur sur une route précise, erreurs 502/504, file de jobs en retard, timeouts de base de données ou mémoire saturée.

2. Lire l'état système

top
free -m
df -h

Cette étape répond à trois questions simples : le CPU souffre-t-il, la mémoire manque-t-elle, ou le disque est-il presque plein ?

3. Identifier le processus impliqué

htop
ps aux --sort=-%mem | head -n 10
ps aux --sort=-%cpu | head -n 10

Vous isolez ensuite le composant le plus suspect : Nginx, PHP-FPM, Node.js, MySQL, Redis, worker ou script cron.

4. Lire les événements du service

sudo systemctl status nginx
sudo journalctl -u nginx --since "15 minutes ago"

Cette étape révèle souvent un redémarrage, une erreur de conf, un problème de dépendance ou une instabilité récente.

5. Lire les logs applicatifs

C'est ici que l'on passe du symptôme à la cause : exception non gérée, endpoint qui boucle, connexion DB lente, quota externe dépassé, ou erreur introduite par un déploiement.

Méthode : notez l'heure exacte du début d'incident. Elle sert de pivot pour filtrer journalctl et les fichiers de logs sans vous perdre dans l'historique.

Bonnes pratiques de monitoring

Les commandes vues dans cet article sont très utiles, mais elles ne remplacent pas une vraie discipline d'exploitation. Le plus important est de rendre l'observation régulière et comparable dans le temps.

Définissez une baseline : charge moyenne normale, RAM habituelle, temps de réponse cible, taille de logs acceptable.
Centralisez ce qui doit l'être : métriques système, logs Nginx, logs applicatifs, journaux de services critiques.
Activez une rotation des logs pour éviter qu'un incident secondaire ne remplisse le disque.
Conservez des logs lisibles par date, niveau et contexte technique.
Surveillez les signaux faibles : montée progressive mémoire, erreurs intermittentes, redémarrages rares mais récurrents.
Documentez vos commandes d'intervention pour que l'équipe applique toujours la même méthode.
Complétez cette approche manuelle par des outils comme Prometheus, Grafana, Loki, Uptime Kuma ou une solution APM selon vos besoins.

Si vous administrez un serveur web, pensez aussi à relier ce monitoring aux réglages de performance et de services déjà abordés dans la configuration Nginx, PHP-FPM en production et l'optimisation des performances serveur.

Vision long terme : l'objectif du monitoring n'est pas seulement de réparer plus vite, mais d'anticiper les incidents et de comprendre le comportement normal de votre plateforme.

Conclusion

Pour un diagnostic serveur efficace, il n'est pas nécessaire de commencer par une stack complexe. Une bonne maîtrise de top, htop, journalctl et des logs applicatifs couvre déjà une grande partie des incidents courants en production.

La séquence à retenir est simple : observer la machine, isoler le processus, lire le journal du service, puis confirmer la cause dans les logs métier. Cette méthode permet d'aller vite, de limiter les actions impulsives et de mieux documenter les incidents pour les prochaines interventions.

Prochaine étape : si vous gérez plusieurs serveurs, formalisez cette routine dans un runbook interne afin que chaque membre de l'équipe applique les mêmes vérifications dès les premières minutes d'un incident.