Top 6 des outils open-source d'analyse de logs: Wazuh, Graylog et plus

En tant que RSSI dans un secteur hautement réglementé avec environ 20 ans d'expertise en cybersécurité, j'ai travaillé avec plusieurs plateformes d'analyse de logs de type SIEM. Parmi celles-ci, j'ai sélectionné les 6 meilleurs outils d'analyse de logs open-source. Pour évaluer ces outils, je me suis concentré sur des facteurs clés tels que la flexibilité de la collecte de logs, la détection d'événements en temps réel, la scalabilité et la prise en charge de divers formats de logs.

Fonctionnalités de gestion et de détection des logs

Fonctionnalités d'intégrité et de non-répudiation

Tarification des outils d'analyse de logs

Wazuh

Wazuh est un SIEM open-source qui va plus loin que la plupart des outils de cette catégorie. Il combine la surveillance des logs, la sécurité des endpoints, la surveillance de l'intégrité des fichiers, la détection des vulnérabilités et la détection d'événements de sécurité en temps réel au sein d'une plateforme unique basée sur des agents.

Fonctionnement de la gestion des logs dans Wazuh

Un agent endpoint déployé sur chaque système surveillé collecte les logs localement et les transmet au serveur de gestion Wazuh pour traitement et analyse. L'agent gère la collecte des logs, la surveillance de l'intégrité et la réponse active localement ; ce n'est pas simplement un expéditeur. Wazuh s'intègre nativement avec l'Elastic Stack, en utilisant Elasticsearch pour le stockage et la recherche des logs, et Kibana (via le plugin Wazuh) pour les tableaux de bord et les investigations.

Le moteur de règles s'exécute sur le gestionnaire et évalue les événements de logs entrants par rapport à un ensemble de règles qui inclut des règles par défaut, des benchmarks CIS, des mappages MITRE ATT&CK et toutes les règles personnalisées que vous écrivez. Lorsqu'une règle se déclenche, Wazuh génère une alerte et, si vous avez configuré une réponse active, peut entreprendre une action automatisée sur l'endpoint : bloquer une adresse IP, tuer un processus ou mettre un fichier en quarantaine.

Options d'hébergement :

• Auto-hébergé : La plateforme est gratuit à télécharger et à utiliser. Le support annuel optionnel est tarifé en fonction du nombre d'endpoints surveillés (serveurs, postes de travail et équipements réseau). L'organisation est responsable de la maintenance du matériel et des ressources dans ce modèle.
• Hébergé dans le cloud : Le fournisseur d'hébergement gère le serveur Wazuh et l'Elastic Stack ; vous n'avez qu'à déployer des agents. La tarification dépend des données indexées (anciennement appelées stockage chaud) et de la période de rétention choisie.

Fonctionnalités remarquables :

• Collecte de logs flexible : Wazuh ingère des logs depuis l'Observateur d'événements Windows, les messages système Linux, les logs d'application au format JSON et une large gamme de types de sources sans plugins supplémentaires. La couverture prête à l'emploi est plus large que celle de Graylog ou Logstash, qui nécessitent davantage de configuration pour atteindre la même étendue.
• Mappage MITRE ATT&CK : Les règles correspondent par défaut aux techniques MITRE ATT&CK, de sorte que les alertes vous indiquent non seulement ce qui s'est passé, mais aussi où cela se situe dans une chaîne d'attaque. Cela est important pour le triage ; vous pouvez faire la différence entre un échec d'authentification bruyant et une tentative de credential stuffing sans écrire de corrélation personnalisée.
• Intégrations tierces : Intégrations natives avec Office 365, AWS, GCP, Azure et Rapid7. Une bibliothèque Python intégrée prend en charge les intégrations personnalisées sans la configuration de plugins requise par Syslog-ng ou Fluentd.
• API et réponse active : Une API RESTful couvre les requêtes de logs, la gestion des règles et des décodeurs, les requêtes d'alertes et les interactions avec les agents. La fonction de réponse active exécute des scripts sur l'endpoint surveillé en cas d'alerte — blocage d'adresses IP, arrêt de processus, isolement d'hôtes. Cela n'est pas disponible dans l'Elastic Stack sans outillage supplémentaire.

Graylog

Graylog est une plateforme de gestion de logs avec un cœur open-source (Graylog Open) et des éditions payantes qui s'étendent aux opérations de sécurité. Cette distinction est plus importante que ce que la plupart des descriptions des éditeurs laissent entendre : Graylog Open vous offre la collecte de logs, la recherche, les pipelines de traitement, les tableaux de bord et les alertes basées sur les flux, ce qui est suffisant pour les cas d'usage opérationnels. Les règles Sigma, l'alignement MITRE ATT&CK, l'UEBA, la détection d'anomalies et la gestion des cas sont des fonctionnalités payantes des éditions Graylog Security et Enterprise. Si votre cas d'usage principal est les opérations de sécurité plutôt que la surveillance d'infrastructure, tenez-en compte dans le calcul des coûts.

Fonctionnement de Graylog

Graylog reçoit les données de logs via des entrées GELF (Graylog Extended Log Format), syslog, Beats ou HTTP, les stocke dans Elasticsearch ou OpenSearch (via le Graylog Data Node) et les rend consultables via une interface web. Le système de flux est central dans le fonctionnement de Graylog : les messages entrants sont acheminés vers des flux en fonction de règles, et les alertes, les pipelines et les contrôles d'accès sont tous attachés aux flux plutôt qu'à la couche de stockage. Cela signifie que vous pouvez avoir un flux pour les erreurs d'application acheminé vers une équipe et un flux séparé pour les événements d'authentification acheminé vers la sécurité, avec des politiques de rétention et des permissions différentes pour chacun.

Les pipelines de traitement vous permettent d'analyser, d'enrichir, de supprimer ou de réécrire les messages avant leur stockage. Si vos logs d'application arrivent sous forme de texte non structuré, vous écrivez une règle de pipeline pour extraire les champs en données structurées. Graylog Illuminate (inclus dans les éditions payantes, disponible pour Open avec des limitations) fournit des analyseurs et des tableaux de bord prêts à l'emploi pour les sources courantes : journaux d'événements Windows, Cisco, Palo Alto, AWS CloudTrail et autres.

• La version minimale du broker Kafka est 2.1. Toute entrée Kafka connectée à un broker plus ancien échouera après la mise à niveau.
• Les API tokens expirent désormais après 30 jours par défaut. Toute automatisation, intégration de surveillance ou script utilisant un API token à longue durée de vie cessera de fonctionner à moins que vous n'ayez une politique de rotation des tokens en place. Ce problème a tendance à se manifester sous la forme d'un incident nocturne lorsque quelque chose cesse de rapporter, plutôt que pendant la mise à niveau elle-même.

Fonctionnalités remarquables :

• Routage et traitement basés sur les flux : Le modèle de flux vous permet de segmenter les données de logs par source, application ou niveau de sensibilité au moment de l'ingestion, puis d'appliquer différents pipelines, politiques de rétention et contrôles d'accès par flux. C'est plus flexible sur le plan opérationnel que les modèles index-par-source d'Elasticsearch.
• Extraction et analyse des logs : Les extracteurs extraient des champs spécifiques des messages de logs à l'ingestion. Les pipelines de traitement gèrent des transformations plus complexes, la logique conditionnelle, les recherches, le renommage des champs et la suppression des messages. Together, ils vous donnent un contrôle fin sur ce qui finit dans le stockage. Graylog Illuminate a également livré des correctifs d'analyseur dans la version 7.0.3, y compris une correction de l'analyse des timestamps Apache HTTPD qui produisait des valeurs de temps incorrectes.
• Recherche et investigation : La syntaxe de recherche de Graylog est plus simple que Lucene/KQL pour les requêtes de base, ce qui est important lorsque vous avez besoin qu'un ingénieur d'astreinte recherche des logs à minuit sans documentation de référence. Les recherches sauvegardées, les plages de temps relatives et les superpositions d'histogrammes sont toutes disponibles sans modules payants supplémentaires.
• Gestion des utilisateurs avec intégration AD/LDAP : L'authentification Active Directory et LDAP est prise en charge dans Graylog Open. Les contrôles d'accès basés sur les rôles vous permettent de restreindre les flux et les tableaux de bord que chaque équipe peut voir.

Les difficultés de Graylog

Le niveau gratuit de Graylog présente des lacunes importantes si les opérations de sécurité sont votre cas d'usage : la prise en charge des règles Sigma, la détection d'anomalies et la gestion des cas sont toutes payantes. La dépendance à Elasticsearch/OpenSearch ajoute une complexité opérationnelle similaire à celle de l'ELK Stack. À grande échelle, le traitement par pipeline peut créer des goulets d'étranglement de performance qui nécessitent un réglage minutieux de l'ordre des étapes du pipeline et de l'allocation des threads de travail.

Elastic Stack (ELK Stack) – Logstash

Elastic Stack est un ensemble de produits open-source ; ses composants principaux sont Elasticsearch, Kibana et Logstash.

Fonctionnement de l'analyse de logs ELK

Logstash est un pipeline de traitement de données côté serveur. Il reçoit les données de logs à partir d'entrées (fichiers, Beats, syslog, Kafka, HTTP et des dizaines d'autres), applique des plugins de filtrage pour analyser et enrichir les données, et achemine la sortie vers une ou plusieurs destinations. La plupart des déploiements envoient la sortie vers Elasticsearch, mais Logstash peut simultanément écrire vers S3, un SIEM, une file de messages ou un autre cluster Elasticsearch.

Elasticsearch stocke les données de logs traitées et les rend consultables à l'aide d'un index inversé. C'est la raison pour laquelle ELK peut monter à l'échelle du pétaoctet tout en renvoyant des résultats de recherche en moins d'une seconde sur des requêtes ciblées, mais cette performance provient de la structure d'index, ce qui signifie que les charges de travail intensives en écriture nécessitent une gestion minutieuse du cycle de vie des index. Kibana repose sur Elasticsearch et fournit la couche visuelle : tableaux de bord, la vue Discover pour la recherche de logs ad hoc, Canvas pour les rapports personnalisés et Lens pour les visualisations par glisser-déposer.

• Recherche en texte intégral à grande échelle : L'architecture d'index inversé d'Elasticsearch prend en charge la recherche en moins d'une seconde sur des milliards d'entrées de logs. KQL (Kibana Query Language) et ES|QL (le nouveau langage de requête basé sur les pipes dans la version 9.x) offrent aux analystes deux interfaces de requête différentes selon leur préférence de travail. Pour les investigations de logs complexes sur de grands ensembles de données, rien dans l'espace open-source n'égale la profondeur de recherche d'ELK.
• Ingestion et filtrage multi-sources : Logstash dispose d'environ 200 plugins d'entrée et 200 plugins de filtrage. Le filtre grok traite le texte non structuré en utilisant des modèles de capture nommés ; le filtre json traite les logs JSON structurés ; le filtre csv traite les données tabulaires. Plusieurs étapes de filtrage s'exécutent en séquence, de sorte que vous pouvez analyser une ligne syslog brute, extraire des champs, rechercher une adresse IP dans une base de données GeoIP et supprimer les messages de niveau debug avant que l'événement n'atteigne Elasticsearch, le tout dans un seul pipeline.
• Détection d'anomalies par machine learning : Les fonctionnalités ML de Kibana (payantes) identifient des schémas inhabituels dans les données de logs sans que vous ayez à définir des seuils. Utile pour détecter des attaques à évolution lente ou une dégradation progressive des performances que les alertes à seuil fixe manquent.
• Tableaux de bord Kibana : Les options de visualisation de Kibana sont étendues : séries temporelles, cartes, cartes de chaleur, tableaux de données, jauges, etc. Les recherches sauvegardées et les modèles d'index permettent aux analystes de partager des contextes d'investigation entre les équipes.
• Routage de sortie extensible : Un seul pipeline Logstash peut écrire simultanément vers Elasticsearch, un bucket S3, un deuxième cluster Elasticsearch pour la reprise après sinistre et un topic Kafka pour le traitement en aval.

Les difficultés d'ELK

La charge opérationnelle est réelle. Les clusters Elasticsearch nécessitent une planification de la mémoire (le heap JVM doit être dimensionné avec soin), une gestion des shards (trop de petits shards ou trop peu de grands nuisent tous deux aux performances) et une configuration de la politique de cycle de vie des index pour contrôler les coûts de rétention.

La plupart des équipes qui exécutent ELK à grande échelle finissent par avoir un ingénieur plateforme dédié dont la responsabilité principale est Elasticsearch. La situation des licences mérite également d'être comprise : les composants de l'Elastic Stack sont sous la licence Elastic 2.0, qui n'est pas une licence open-source approuvée par l'OSI. L'utilisation auto-hébergée est gratuit, mais proposer Elasticsearch en tant que service géré à des tiers n'est pas autorisé dans le niveau gratuit.

Fluentd

Fluentd est un collecteur de données open-source sous la licence Apache 2.0, conçu pour unifier l'ingestion et le routage des logs à travers une infrastructure hétérogène. Sa fonction principale est simple : accepter les événements de logs provenant de sources, appliquer un traitement optionnel et les acheminer vers des destinations. Fluentd ne stocke ni n'analyse les logs lui-même ; c'est un collecteur et un routeur, pas une plateforme d'analyse de logs¹

Cette distinction est importante lorsqu'on l'évalue par rapport à Wazuh ou Graylog. Fluentd est généralement la première couche d'un pipeline plus large. Une architecture courante : des agents Fluentd sur chaque serveur collectent les logs d'application, les logs système et les logs de conteneurs, les mettent en mémoire tampon localement (pour que rien ne soit perdu si la destination en aval est temporairement indisponible), appliquent l'analyse et le filtrage, et transmettent le résultat vers Elasticsearch, Splunk, un SIEM cloud ou un autre backend de stockage. L'analyse a lieu dans ce qui reçoit les données.

Fluentd vs. Fluent Bit

Les équipes qui évaluent Fluentd pour des environnements Kubernetes finissent souvent par choisir Fluent Bit, et il est utile de comprendre pourquoi. Fluent Bit est un forwarder léger dans le même écosystème CNCF, un binaire d'environ 4 Mo contre le processus Ruby de Fluentd qui est nettement plus lourd. Pour les déploiements Kubernetes où vous voulez un collecteur de logs s'exécutant en DaemonSet sur chaque nœud, la différence d'empreinte de ressources est significative à grande échelle. Fluent Bit prend également en charge l'analyse des logs multilignes, l'injection dynamique de métadonnées à partir des labels et annotations des pods Kubernetes, et la gestion intégrée de la contre-pression pour éviter la perte de données lorsque les destinations en aval ralentissent.

Fluentd est le meilleur choix lorsque vous avez besoin de l'écosystème complet de plus de 500 plugins ou d'une logique de routage complexe que la bibliothèque de plugins plus réduite de Fluent Bit ne peut pas couvrir. Pour la plupart des déploiements natifs Kubernetes effectuant un simple acheminement de logs, Fluent Bit est le choix pratique. Les projets partagent des concepts de configuration, donc passer de l'un à l'autre ne nécessite pas une réécriture complète.

Comment Fluentd gère les données de logs

Fluentd modélise les données de logs comme un flux d'événements étiquetés. Chaque événement possède un tag (une chaîne séparée par des points comme app.web ou system.syslog), un timestamp et un enregistrement. Les tags pilotent le routage : les directives match dans la configuration spécifient quels tags sont envoyés où, quels filtres s'appliquent et dans quel ordre. Plusieurs sorties peuvent correspondre au même tag, de sorte que vous pouvez envoyer les mêmes événements simultanément vers Elasticsearch et une archive S3.

Le système de tampon est ce qui rend Fluentd fiable en production. Plutôt que d'écrire directement vers la destination, les événements s'accumulent dans un tampon et sont vidés par blocs à des intervalles configurables ou lorsque le tampon atteint un seuil de taille. Si la destination est inaccessible, les événements restent dans le tampon et sont réessayés avec un backoff exponentiel.

Fonctionnalités remarquables :

• Plus de 500 plugins communautaires : Couvre les intégrations avec la plupart des principales destinations de logs et sources de données sans développement personnalisé.
• Routage flexible des données : Les événements peuvent être acheminés vers plusieurs destinations simultanées, telles que des fichiers, des SGBDR, des bases NoSQL, des IaaS, des SaaS et Hadoop, en fonction de règles de routage basées sur les tags.
• Accent sur le traitement des logs : Fluentd est optimisé pour le traitement et le transfert de logs à grande échelle, ce qui le rend bien adapté comme couche de collecte et de routage devant Elasticsearch ou d'autres backends de stockage plutôt que comme plateforme d'analyse autonome.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Syslog-ng

Syslog-ng est un programme open-source de gestion de logs qui collecte, classifie, transforme et achemine les données de logs provenant de sources multiples vers le stockage ou des plateformes en aval. Sa capacité distinctive est le traitement structuré : les logs peuvent être normalisés dans un format cohérent avant d'être transmis à des systèmes tels qu'Apache Kafka ou Elasticsearch.

Capacités :

• Classifier et structurer les logs à l'aide d'analyseurs intégrés comme csv-parser
• Stocker les logs dans des fichiers, des files de messages (AMQP) ou des bases de données (PostgreSQL, MongoDB)
• Transférer vers des plateformes big data, notamment Elasticsearch, Apache Kafka ou Hadoop

Fonctionnalités distinctives :

• Archivage automatisé des logs : Syslog-ng gère nativement la rotation et l'archivage des logs, y compris la compression et la dénomination des fichiers avec horodatage. Pour les environnements soumis à des exigences de conformité en matière de rétention, cela réduit le besoin d'outils externes comme logrotate ajoutés par-dessus.
• Prise en charge de multiples formats de messages : RFC3164 (syslog traditionnel), RFC5424 (syslog structuré), JSON et les formats clé-valeur sont tous analysés nativement. Syslog-ng peut recevoir un message RFC3164 et le restituer en RFC5424 avec des champs de données structurées ajoutés, ce qui est utile lors de l'alimentation de systèmes qui attendent un format syslog moderne.
• Transport chiffré : Le transport syslog chiffré par TLS est pris en charge nativement à la fois pour la réception et le transfert. Cela est important dans les environnements où les données de logs transitent par des segments de réseau non fiables.
• Routage conditionnel : Les expressions de filtre vous permettent de router en fonction de n'importe quel champ analysé — sévérité, facility, hôte ou champs personnalisés extraits par les analyseurs. Une seule instance syslog-ng peut router les échecs d'authentification vers le flux de l'équipe de sécurité, les erreurs d'application vers le flux de l'équipe de développement et les messages de debug vers /dev/null.

Où syslog-ng est pertinent (et où il ne l'est pas)

Syslog-ng est le bon choix lorsque vos sources de logs sont principalement des équipements réseau et des serveurs parlant syslog, et lorsque vous avez besoin d'une collecte fiable à haut débit avec extraction de champs structurés avant transfert vers un backend de stockage. Ce n'est pas une plateforme d'analyse de logs ; il n'y a pas d'interface de requête, pas de tableaux de bord et pas d'alertes intégrées. Il fonctionne comme la couche de collecte et de routage devant Elasticsearch ou Graylog, pas comme un outil autonome.

Nagios

Une clarification nécessaire avant d'aller plus loin : Nagios Core est le projet de surveillance open-source sous licence GPL, et il se concentre sur la surveillance des hôtes, des services et du réseau plutôt que sur l'analyse de logs.[15] Le produit décrit ici est Nagios Log Server, un produit commercial distinct de Nagios Enterprises. Si vous recherchez spécifiquement un outil d'analyse de logs open-source et gratuit, Nagios Log Server n'est pas celui qu'il vous faut. Ce qu'il propose, c'est une plateforme de gestion de logs avec support commercial, provenant d'un éditeur ayant une longue expérience dans la surveillance d'infrastructure.

Nagios Log Server collecte les données de logs en temps réel et les transmet à une interface de recherche. Il est compatible avec les serveurs Windows, Linux et Unix et inclut un assistant de configuration pour intégrer de nouveaux endpoints ou applications.²

Fonctionnalités remarquables :

• Surveillance des services réseau : Couvre SMTP, POP3, HTTP, PING et d'autres services réseau en mettant l'accent sur la santé de l'infrastructure.
• Surveillance des ressources des hôtes : Suit la charge du processeur, l'utilisation du disque et la santé du système sur les hôtes surveillés.
• Rotation et archivage des fichiers de logs : Rotation automatisée et archivage à long terme sans intervention manuelle.
• Filtrage géographique des logs : Filtre les données de logs par origine géographique et génère des cartes de flux de trafic.
• Interface web : Interface optionnelle pour visualiser l'état actuel du réseau et les fichiers de logs.

Pour des conseils sur le choix du bon outil ou service, consultez nos sources basées sur les données : logiciel d'analyse de logs.

FAQ

Citer cette recherche

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{hafa2026,
  author = {Hafa, Adil and Sezer, Sena},
  title  = {{Top 6 des outils open-source d'analyse de logs: Wazuh, Graylog et plus}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/open-source-log-analysis-tools}},
  note   = {AIMultiple. Consulté le 23 Juin 2026}
}

Liens de référence

1.

Fluentd | Open Source Data Collector | Unified Logging Layer

2.

Nagios Log Server | Nagios Enterprises

Nagios Enterprises

Adil Hafa

Conseiller technique

Suivre

Adil est un expert en sécurité avec plus de 16 ans d'expérience dans la défense, le commerce de détail, la finance, la bourse, la commande de nourriture et le gouvernement.

Voir le profil complet

Recherche effectuée par

Sena Sezer

Analyste du secteur

Suivre

Sena est analyste sectorielle chez AIMultiple. Elle a obtenu sa licence à l'Université de Bogazici.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire