[[public:graylog]]

Graylog : Article

  • Comment mettre à profit une source de données inépuisable et contenant des informations cruciales ?
    • Les équipements informatiques génèrent des “logs”, lignes de textes par milliers qui contiennent les événements survenus dans un système, du plus anodin au plus critique. Ces informations sont souvent oubliées et peu étudiées.
  • Prévoir de répondre à des questions que l’on ne se pose pas encore.
    • Les logs ont une date de péremption afin d'éviter qu'ils prennent trop de place au vu de la vitesse à laquelle ils sont générés. Ils sont peu exploités et périssables.
  • La quantité de logs générés par notre infrastructure informatique est importante.
  • L'objectif de l'entreprise, c'est de s'assurer que ses systèmes soient opérationnels et qu'ils le soient à leur pleins potentiel.
  • Le moindre incident peut impacter la production des utilisateurs, nous devons réagir vite et éviter que cela se reproduise.

C'est la que les logs deviennent importants. Ils permettent d'étudier le comportement exact du système et aussi de tracer la cause du problème :

Qui, quoi, quand, comment et pourquoi ?

Le log management, ou «gestion d’historique» en français, est un ensemble de pratiques permettant la collecte et la manipulation des journaux d’événements produits par des équipements informatiques. Cela consiste plus précisément en plusieurs pratiques qui permettent d’aboutir à un résultat plus simple à comprendre et à analyser, plutôt que la consultation directe des logs par un humain. Plusieurs raisons peuvent motiver la mise en place d’une solution de gestion de logs :

  • Vitesse de génération : Les logs sont générés dès lors qu’un événement se produit et bien que les logs soient générés dans des fichiers liés au service qu’il concerne, on ne peut parfois pas suivre le déroulement des événements aussi vite qu’ils se produisent. On parle parfois de plusieurs dizaines d’événement à la seconde par service
  • Volume des données : Bien qu’étant des fichiers textes, les logs sont produits en permanence et parfois très rapidement, par chaque service et par chaque système. La quantité de données est très grande et nécessite des tailles de stockage potentiellement immenses suivant la stratégie de collection et de rétention.
  • Normalisation : Les logs sont des lignes de texte, mais ces lignes ne sont pas toujours formalisées de la même façon. Il est nécessaire de savoir normaliser leur génération afin de réduire les formats et de les rendre plus facilement lisibles par les collecteurs.
  • Véracité :
    • Tous les logs sont-ils utiles ? De la même façon qu’un administrateur réseau peut paraître inutile lorsque tout son système fonctionne, les logs sont-ils intéressants même quand tout va bien ? La première réponse est oui, il est impossible de pouvoir certifier que tout va bien et encore moins que la situation ne sera pas amenée à changer. Il est donc important d’avoir une génération constante des logs pour s’assurer de comprendre la situation en cas de perturbation. Ensuite, comment peut-on valider que tout fonctionne parfaitement ? Certains services peuvent très bien continuer de fonctionner malgré des erreurs (parfois non critiques). Leur configuration peut aussi être non optimale et entraîner un comportement du système normal pour lui mais non désirable pour l’utilisateur.trice. L’observation des logs peut aider à corriger ces problèmes voire à les anticiper.
    • Tous les logs sont-ils pertinents ? Certains systèmes produisent des logs d’alerte en se basant sur des principes de détection d’erreur, d’intrusion ou produisent simplement des logs avec une criticité très faible. Il est normal d’avoir des logs peu pertinents voir même des fausses alertes qui « polluent » le fil de logs.
  • Améliorer notre capacité de réaction :
    • L'entreprise possède déjà un système de supervision efficace qui nous alerte sur le non-fonctionnement d'un service. Il est néanmoins possible d'améliorer ce genre de système avec des alertes plus spécifiques qui se base sur des métriques générées sur une durée et non des états instantanés.
    • Un exemple :
      • Un serveur devient inaccessible suite à une attaque informatique, notre équipe est immédiatement avertie par notre système de supervision qui détecte le service comme indisponible.
      • Avec une solution de log management couplé à un système d'alerte, une meilleure gestion d'un tel incident est possible :
        • il est possible de mettre en surbrillance les logs liés à des tentatives d'intrusion comme les authentifications échouées.
        • il est possible de déclencher des alertes lorsque ces métriques atteignent des seuils anormaux, ce qui peut permettre à notre équipe d'agir avant l'arrivée d'un véritable incident et donc d'éviter des pertes de temps de production.
  • Avoir la possibilité de déterminer la source de problèmes
    • Il est à aujourd'hui impossible de tout prévoir et il est nécessaire de se concentrer sur la véracité de l'information tant sa quantité est grande. Trop d'info tue l'info !
    • Dans le cas où notre équipe rencontre un problème et afin d'en comprendre l'origine, un système de log management permet de :
      • rechercher des logs de façon précise dans un intervalle de temps donné afin de trouver la date d'apparition du problème.
      • cibler l'origine du problème par corrélation entre les logs de chaque service
      • quantifier l'impact et le corriger. Optimiser cette chasse au problème permet un gain de temps majeur.

Puissant outil de log management, Graylog se base sur des produits fiables et propose de nombreuses fonctionnalités. C’est un produit extensible en fonction de nos besoins, il répond globalement à toutes les problématiques et à l’avantage d’être gratuit et open source. L'installation d'un serveur Graylog permet de mettre en place une collecte de logs provenant de sources multiples,sous multiples formats et d'en effectuer une gestion fine au sein d'une plateforme commune. Technologies utilisés par Graylog dans cet article :

  • Distribution Linux (Debian)
  • Elasticsearch
  • MongoDB

  1. Configuration de la source
    • Sans agent : La plupart des équipements générants des logs utilisent des formats de log standards (syslog, RFC 5424) et prennent en charge la redirection des logs vers un serveur de log distant. Il faut configurer les sources de logs en spécifiant au moins le serveur de log distant (le serveur Graylog), le port utilisé.
    • Avec agent : Certains systèmes génèrent des logs avec des formats spécifiques (Windows et son observateur d'événements par exemple). Ceux la necessitent un agent (aussi appellé “collecteur”) qui, une fois installé et configuré s'occupera de “traduire” puis d'envoyer les logs sur le serveur de gestion des logs.
  2. Création de l'input : Il est nécessaire de configurer Graylog pour qu'il accepte des sources et formats de logs qui lui sont envoyés.
  3. Établir la demande :
    • Définir les sources de logs : Le pare-feu de l'entreprise
    • Définir l'information qui nous intéresse : Les authentifications VPN échouées
  4. Rechercher les messages
    • Rechercher le log exact donné lors d'une authentification échouée :
    • Afficher la liste des messages en question via la recherche de Graylog:
      gl2_source_input:'votre input' AND source:'votre pare-feu' AND message:"could not authenticate"
  5. Créer un dashboard (étape optionnelle mais permettant d'avoir une vue rapide sur les logs):
    • Un premier tableau listant l'ensemble des logs liés à l'authentification VPN pour cette source
    • Un compteur des erreurs d'authentifications
    • Un diagramme permettant de visualiser rapidement le taux de réussite d'authentification
  6. Définir un événement via l'onglet Alerts et via “Create Event Definition” : Cette étape définit les critères de déclenchement des alertes.
    • Spécifier la requête exacte, dont les résultats définissent l'apparition d'un événement.
    • Spécifier le Stream, qui défini les sources de logs à utiliser
    • Déterminer la fréquence de vérification
    • Dans notre cas :

Il reste bien entendu possible d'effectuer des requêtes différentes, de personnaliser les tableaux en fonction de la requête et de changer la définition d'un événement, en se basant sur la fréquence d'apparition d'un log plutôt que sur son existence.

Exemples d'utilisation de Graylog

  • Suivi des connexions VPN

  • Suivi des logs des serveurs Linux

  • La quantité de données est énorme, le choix de rétention sur la rétention des logs est à étudier et doit être réfléchi afin de ne pas se retrouver avec des disques durs saturés de données ou à l'inverse de ne pas avoir récupéré assez d'information.
  • Quelle solution optimale dans le cas de l'entreprise ? Centraliser ? Décentraliser ? Dans le cas de l'infogérance de notre infrastructure multi-sites, il faut bien établir la façon dont seront collectés les logs :
    • en local via un serveur de log dédié chez chaque client qui retransmet les informations à un serveur distant Graylog central.
    • en distanciel, les logs seront envoyés directement vers le serveur central ?
    • via des serveurs Graylog locaux (des nodes) qui seront ensuite accessibles et gérés depuis un serveur central distant?
  • Comment intégrer et faire évoluer notre façon de travailler à l'aide d'une solution de log management ? Le log management permet de nombreuses opportunités, au niveau le plus technique comme pour du support utilisateur, il est important que cet outil soit maîtrisé et intégré à nos habitudes de travail.
  • Quelle importance y attribuer ? La collecte des logs, la mise en place de tableaux de bord, la création d'alertes pertinentes, l'affinage des recherches, cela représente un temps de configuration relatif à l'importance qu'on y attribue.

Cet article est une introduction au log management et présente la puissance d'un tel outil. Nous pourrons aborder dans un futur article l'utilisation des fonctions avancées de Graylog (Decorateurs, Streams, Pipelines…) qui n'ont pas été toutes abordées ici. Nous avons intégré Graylog à notre routine de résolution des incidents et nous continuons d'adapter cet outil a notre cycle de travail. C'est à dire faire en sorte que l'information que Graylog collecte, analyse et nous retransmet soit pertinente, lisible et accessible. L'objectif serait aussi de proposer nos solutions à la communauté, Graylog mettant en place des outils de communication et de partages des contenus créés par ses utilisateurs.

  • public/graylog.txt
  • Dernière modification: 29/11/2021/ 15:39
  • par t.agnelli