La gestion centralisée des logs est un pilier de l’administration système moderne. Face aux problèmes de performance, de complexité d’installation et de licence rencontrés avec l’ELK Stack (Elasticsearch, Logstash, Kibana), Graylog s’impose comme une alternative robuste et plus accessible. Conçu dès le départ pour la centralisation de logs, il offre une interface unifiée, des alertes natives et une intégration simplifiée — le tout en open source.
Avec la version 7.1, Graylog a migré d’Elasticsearch vers OpenSearch pour son moteur d’indexation, s’affranchissant des contraintes de licence imposées par Elastic en 2021. L’architecture repose désormais sur trois composants : MongoDB (métadonnées), un Data Node basé sur OpenSearch (indexation), et le serveur Graylog lui-même (traitement, interface). Sur un mono-nœud, 4 à 8 Go de RAM suffisent pour couvrir les besoins d’une PME ou d’un lab.
Cet article couvre l’installation complète de Graylog 7.1 sur Debian 12 (Bookworm) et Ubuntu 24.04 LTS, sa configuration initiale, la collecte de logs depuis des sources multiples via Graylog Sidecar, et la mise en place d’alertes opérationnelles. Pour une présentation de la stack ELK, consultez notre article sur la centralisation de logs avec ELK Stack.
Graylog vs ELK : ce qui change concrètement
L’ELK Stack est modulaire par conception : Elasticsearch stocke, Logstash transforme, Kibana visualise. Cette flexibilité a un coût : la complexité opérationnelle et la consommation mémoire sont élevées. Une installation ELK fonctionnelle nécessite facilement 8 à 16 Go de RAM pour un usage production modeste, sans compter la gestion des certificats TLS entre chaque composant.
Graylog adopte une approche plus intégrée :
- Interface unique : inputs, extracteurs, streams, dashboards et alertes dans un seul panneau web
- Alertes natives : conditions configurables sans plugin tiers (contrairement à Elasticsearch Watcher)
- GELF natif : le protocole Graylog Extended Log Format évite les problèmes de troncature des messages syslog
- Empreinte réduite : 4 Go de RAM suffisent pour un mono-nœud en lab ou PME
- Backend libre : OpenSearch (Apache 2.0) remplace Elasticsearch depuis Graylog 6
Architecture de Graylog 7
Depuis la version 6, Graylog embarque son propre Data Node basé sur OpenSearch, ce qui simplifie la gestion des certificats TLS inter-composants et réduit la surface de configuration.
# Ports par composant
# MongoDB : 27017 — métadonnées (streams, users, dashboards, alertes)
# Data Node : 9200 — API OpenSearch (indexation et recherche)
# Data Node : 9300 — communication interne cluster OpenSearch
# Graylog : 9000 — interface web et API REST
# Inputs : 514 — syslog UDP/TCP
# : 5044 — Beats (Filebeat, Winlogbeat)
# : 12201 — GELF TCP/UDP
Installation sur Debian 12 / Ubuntu 24.04
Prérequis système
Un serveur avec minimum 4 Go de RAM (8 Go recommandés en production), un système de fichiers XFS pour les volumes du Data Node, et les paquets de base :
# Mise à jour et dépendances
apt update && apt upgrade -y
apt install -y apt-transport-https gnupg curl pwgen
# Augmenter vm.max_map_count pour OpenSearch (requis)
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p
# Vérifier la valeur appliquée
sysctl vm.max_map_count
# vm.max_map_count = 262144
Installation de MongoDB 8.0
# Importer la clé GPG MongoDB
curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc |
gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor
# Ajouter le dépôt — Debian 12
echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ]
https://repo.mongodb.org/apt/debian bookworm/mongodb-org/8.0 main"
> /etc/apt/sources.list.d/mongodb-org-8.0.list
# Pour Ubuntu 24.04 (Noble), remplacer bookworm par noble :
# echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ]
# https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse"
# > /etc/apt/sources.list.d/mongodb-org-8.0.list
apt update && apt install -y mongodb-org
# Épingler la version pour éviter les mises à jour automatiques non maîtrisées
apt-mark hold mongodb-org
systemctl enable --now mongod
systemctl status mongod
Ajout du dépôt Graylog 7.1
# Télécharger et installer le paquet de dépôt Graylog 7.1
wget https://packages.graylog2.org/repo/packages/graylog-7.1-repository_latest.deb
dpkg -i graylog-7.1-repository_latest.deb
apt update
Installation et configuration du Data Node
apt install -y graylog-datanode
# Générer une clé secrète unique (96 caractères) — à conserver précieusement
SECRET=$(pwgen -N 1 -s 96)
echo "password_secret généré : $SECRET"
# Injecter la clé dans la configuration du Data Node
sed -i "s|^#?password_secret =.*|password_secret = $SECRET|"
/etc/graylog/datanode/datanode.conf
# Allouer la moitié de la RAM disponible au heap OpenSearch
# Exemple : 4 Go sur un serveur avec 8 Go de RAM
echo 'GRAYLOG_DATANODE_JAVA_OPTS="-Xms4g -Xmx4g"'
>> /etc/default/graylog-datanode
systemctl enable --now graylog-datanode
# Le Data Node peut mettre 1 à 2 minutes à démarrer complètement
journalctl -fu graylog-datanode
Installation et configuration de Graylog Server
apt install -y graylog-server
# Générer le hash SHA-256 du mot de passe administrateur
echo -n "VotreMotDePasseAdmin" | sha256sum | cut -d" " -f1
# Editer /etc/graylog/server/server.conf
# Les quatre paramètres obligatoires :
# password_secret — identique à celui du Data Node
# root_password_sha2 — hash SHA-256 du mot de passe admin
# http_bind_address — interface d'écoute de l'UI
# mongodb_uri — connexion MongoDB
# Extrait de /etc/graylog/server/server.conf
password_secret = <meme_valeur_que_datanode>
root_password_sha2 = <hash_sha256_mot_de_passe_admin>
http_bind_address = 0.0.0.0:9000
mongodb_uri = mongodb://localhost:27017/graylog
# Allouer la mémoire JVM au serveur Graylog
echo 'GRAYLOG_SERVER_JAVA_OPTS="-Xms2g -Xmx2g"'
>> /etc/default/graylog-server
systemctl enable --now graylog-server
# Vérifier que les trois services sont actifs
systemctl status mongod graylog-datanode graylog-server
Note sécurité : En production, placez Graylog derrière un reverse proxy Nginx avec TLS, et restreignez l’accès au port 9000 au réseau de gestion. Les ports d’inputs (514, 12201, 5044) doivent rester accessibles uniquement depuis vos hôtes sources.
Première connexion et création d’un Input
L’interface web est accessible sur http://VOTRE_IP:9000. Connectez-vous avec le compte admin et le mot de passe défini lors de la configuration. La première étape consiste à créer un Input, point d’entrée des messages de logs.
- Naviguer vers System → Inputs
- Sélectionner Syslog UDP dans la liste déroulante
- Configurer le port
514et un titre explicite - Cliquer sur Launch input
Pour les applications compatibles GELF (Docker, applications Java, etc.), préférer l’input GELF TCP sur le port 12201.
Collecte de logs avec Graylog Sidecar
Le Sidecar est un agent léger (version 1.5.4 en juin 2026) installé sur les hôtes à superviser. Il récupère sa configuration de collecteurs (Filebeat, Winlogbeat) directement depuis l’interface Graylog centrale, ce qui évite de maintenir des fichiers de configuration Filebeat locaux sur chaque serveur.
# Sur chaque hôte à superviser (Debian/Ubuntu)
wget https://packages.graylog2.org/repo/packages/graylog-sidecar-repository_1-5_all.deb
dpkg -i graylog-sidecar-repository_1-5_all.deb
apt update && apt install -y graylog-sidecar filebeat
# Générer un token API dans Graylog :
# System → API Tokens → Create token (rôle : Graylog Sidecar)
# Configurer le Sidecar
cat > /etc/graylog/sidecar/sidecar.yml << 'EOF'
server_url: "http://IP_GRAYLOG:9000/api/"
server_api_token: "VOTRE_TOKEN_API"
node_name: "nom-du-serveur"
log_path: "/var/log/graylog/sidecar"
tls_skip_verify: false
update_interval: 10
send_status: true
list_log_files:
- /var/log
collector_binaries_whitelist:
- "/usr/bin/filebeat"
EOF
systemctl enable --now graylog-sidecar
# Vérifier la connexion au serveur Graylog
journalctl -fu graylog-sidecar | grep -i "connected|error"
Une fois le Sidecar connecté, il apparaît dans System → Sidecars. Depuis l’interface, assignez-lui une Configuration de collecteur Filebeat pointant vers votre Input GELF ou Beats.
Streams, extracteurs et alertes
Streams : routage et cloisonnement des logs
Les streams sont le mécanisme central de routage dans Graylog. Chaque message entrant est évalué par les règles de stream ; s’il correspond, il y est archivé (et peut déclencher des alertes). Exemple de stream pour les échecs d’authentification SSH :
- Champ
facility=auth - Champ
messagecontientFailed password
Alertes par Event Definitions
# Configuration d'une alerte SSH brute-force dans Graylog :
# Alerts → Event Definitions → Create Event Definition
#
# Nom : SSH-BruteForce
# Type : Count (nombre de messages)
# Stream : SSH-Failures
# Condition : count >= 10 sur une fenêtre de 5 minutes
# Grouper : par champ src_ip (pour identifier l'attaquant)
# Notif. : Slack webhook ou email SMTP
Extracteurs : structurer les logs bruts
Les extracteurs analysent le champ message brut pour créer des champs structurés interrogeables. Depuis System → Inputs → Manage extractors :
# Extracteur regex — isoler l'IP source d'un échec SSH
# Message source : "Failed password for root from 192.168.1.50 port 42312 ssh2"
# Type : Regex
# Expression : from (d{1,3}.d{1,3}.d{1,3}.d{1,3})
# Champ cible : src_ip
# Condition : message contient "Failed password"
# Le champ src_ip devient ensuite filtrable dans les dashboards et streams
À lire également
- Centralisation logs avec ELK Stack — Elasticsearch, Kibana, Filebeat — comparez l’approche ELK avec Graylog pour choisir la solution adaptée à votre infrastructure
- Gestion des journaux avec syslog et journalctl — maîtriser les logs locaux avant de les centraliser dans Graylog
- Prometheus et Grafana sur Debian — installation, configuration et dashboards pratiques — compléter Graylog avec des métriques systèmes via Prometheus
- Supervision avec Zabbix 7.0 LTS sur Debian/Ubuntu — supervision applicative à coupler avec la centralisation de logs Graylog