Analyser les logs avec journalctl

Sous systemd (Ubuntu/Debian sur VPS HolyCloud), les journaux applicatifs et noyau sont centralisés par journald et consultables avec journalctl. Ce guide couvre les requêtes essentielles pour diagnostiquer Apache, SSH, MariaDB ou un service custom après incident.

Prérequis

• VPS HolyCloud avec systemd (Ubuntu 22.04+, Debian 12)
• Accès sudo (certains journaux système sont restreints)
• Service concerné identifié (ex. ssh, apache2, mariadb)
• Fuseau horaire serveur cohérent pour interpréter les horodatages

Conseil : combinez journalctl avec les fichiers classiques /var/log/apache2/, /var/log/nginx/ quand l'application écrit encore sur disque.

Étape 1 : premiers commandes

journalctl --version
journalctl -n 30 --no-pager

Dernières entrées en temps réel (Ctrl+C pour quitter) :

sudo journalctl -f

Boot actuel uniquement :

sudo journalctl -b

Boot précédent (utile après crash) :

sudo journalctl -b -1

Étape 2 : filtrer par unité systemd

SSH :

sudo journalctl -u ssh -n 50 --no-pager
sudo journalctl -u ssh --since "1 hour ago"

Apache :

sudo journalctl -u apache2 -p err -n 100 --no-pager

MariaDB :

sudo journalctl -u mariadb --since today

PHP-FPM (adaptez la version) :

sudo journalctl -u php8.2-fpm -n 40 --no-pager

Étape 3 : priorité et messages d'erreur

Niveaux : emerg, alert, crit, err, warning, notice, info, debug.

Erreurs et plus graves depuis hier :

sudo journalctl -p err --since yesterday --no-pager

Critiques du boot courant :

sudo journalctl -b -p crit..emerg --no-pager

Étape 4 : plages horaires

sudo journalctl --since "2026-06-20 14:00:00" --until "2026-06-20 15:00:00"
sudo journalctl --since "2 hours ago"
sudo journalctl --since today --until "16:00"

Format relatif pratique pendant une mise en production :

sudo journalctl -u apache2 --since "10 min ago" -f

Étape 5 : noyau et démarrage

Messages noyau :

sudo journalctl -k -b
sudo journalctl -k -p err -n 30

Chaîne de démarrage (temps de boot) :

systemd-analyze
systemd-analyze blame | head -20
systemd-analyze critical-chain

Étape 6 : export et recherche

Export JSON pour ticket support :

sudo journalctl -u mariadb --since "24 hours ago" -o json-pretty > /tmp/mariadb-logs.json

Recherche texte (grep sur la sortie courte) :

sudo journalctl -u ssh --since today | grep -i "Failed password"
sudo journalctl | grep -i "out of memory" | tail -20

Sortie brute sans pager :

sudo journalctl -u nginx -n 200 --no-pager

Étape 7 : persistance et espace disque

Espace utilisé :

journalctl --disk-usage

Limiter la taille (persistent) :

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/size.conf

[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day

sudo systemctl restart systemd-journald
sudo journalctl --vacuum-size=200M

Vérification

sudo journalctl -u ssh -n 1 -o short-iso
sudo journalctl -p err -b --no-pager | wc -l
systemctl status ssh --no-pager

Vous devez voir des lignes horodatées cohérentes et pouvoir remonter à l'heure d'un incident connu.

Besoin d'aide HolyCloud

• Journal vide pour un service : nom d'unité incorrect (systemctl list-units --type=service | grep -i apache)
• Horodatages décalés : timedatectl status
• Disque plein à cause des logs : journalctl --disk-usage, --vacuum-size
• Support HolyCloud : journalctl -u NOM_SERVICE --since "…" -n 200 --no-pager (sans données sensibles)