Graylog vs ELK

Que vous soyez développeur ou administrateur réseaux, vous aurez tôt ou tard besoin de consulter les logs de production ce qui n’est pas toujours facile selon votre infrastructure. Pour éviter ces désagréments, il est conseillé de centraliser les logs des serveurs et/ou applicatifs sur un système central. Il sera ainsi aisé de rechercher des logs depuis une interface web et même d’être alerté en cas d’erreurs importantes.

Il existe de nombreuses solutions payantes : des outils comme Splunk qui peuvent s’installer dans votre architecture ou des offres dans le cloud tel que Loggly. Les tarifs sont variables et pour les offres cloud, il faut veiller à ne pas enfreindre les règles de sécurités en place dans votre société (une norme PCI-DSS par exemple).

Du côté des offres open-source, 2 produits sortent du lot : ELK (Elasticsearch / Logstash / Kibana) et Graylog.

 

ELK

ELK est une offre composée de 3 outils :

  • Elasticsearch qui est un moteur de recherche orienté document facilement scalable pour répondre à de gros volumes
  • Logstash qui permet de configurer des flux d’entrées et des flux de sorties (un fichier lu et envoyé vers Elasticsearch par exemple)
  • Kibana qui est une IHM permettant de consulter les documents d’une base Elasticsearch et d’en sortir des tableaux de bords

Ces 3 produits sont maintenus par la société Elastic.

Cette solution est très simple à mettre en oeuvre avec des outils qui se prennent en main rapidement. Logstash permet, grâce à de nombreux plugins, d’intégrer des logs en provenance de fichiers, d’un rabbitMQ, d’un syslog, … Kibana permet de créer des tableaux de bords très complet avec de nombreux widgets : camembert, graphique, mappemonde, …

kibana4_logmanagement_dashboard

Kibana ne gère cependant pas d’authentification utilisateur. N’importe quel utilisateur peut donc accéder à l’ensemble des logs enregistrés dans le cluster Elasticsearch. La société Elastic propose pour cela un autre outil « Shield » mais qui est payant.

De base, il n’est pas possible de recevoir des alertes sur des conditions précises. Il serait utile par exemple d’être prévenu lorsqu’il y a des tentatives de connexions en erreur sur un serveur ou qu’une base de données n’est plus joignable pour un applicatif. Là aussi, un outil peut être utilisé « Watcher » mais il est soumis à l’achat d’une licence.

Enfin, vous devrez gérer l’épuration des index Elasticsearch par vous même.

 

Graylog

Graylog est une solution composée de 3 briques :

  • Elasticsearch qui est le moteur d’indexation des documents
  • Mongodb qui est une base NoSQL permettant de stocker la configuration et quelques autres paramètres
  • Graylog-server et graylog-web-interface pour la collecte et la visualisation des logs (ces 2 outils vont fusionner dans la prochaine version)

Graylog permet d’intégrer des logs au format syslog, des messages en provenance d’un Rabbit MQ mais également des documents au format GELF. Le GELF est une sorte de syslog améliorée contenant des meta-datas et qui n’a pas de limite de taille sur la longueur du message. Les logs sont traités par la partie serveur et enregistrées dans Elasticsearch.

La partie IHM vous permet d’effectuer des recherches et de configurer :

  • des streams : un stream permet de catégoriser vos logs pour mieux les retrouver. En spécifiant des critères sur la source, le niveau d’erreur, le message, … un log pourra être stocké dans un ou plusieurs streams.
  • des alertes : sur chaque stream, il est possible de définir des alertes afin d’être prévenu s’il y a plus de 10 logs d’erreur sur les 5 dernières minutes par exemple. L’alerte peut être de différents types : par mail, par message slack, via un appel de web-services, …
  • des tableaux de bords : vous pouvez créer des widgets et les intégrer à des tableaux de bords. A ce jour, il existe beaucoup moins de widgets que sur Kibana, mais des nouveautés arrivent avec la prochaine version de Graylog
  • des utilisateurs et des droits d’accès : l’accès à l’interface web nécessite un login et un mot de passe. L’outil propose également une gestion de droit complète permettant de définir les accès aux streams et dashboard pour chaque utilisateur. Il est même possible de brancher Graylog avec le LDAP de votre entreprise

Dans la configuration de la partie serveur, vous pouvez définir une politique de rétention afin que les logs de plus de 6 mois soit automatiquement supprimés par exemple.

graylog_streams

graylog_dashboard_exemple

 

Dans une startup ou une entreprise de petite taille, la stack ELK sera rapidement mise en place et suivant les besoins, il sera possible de la faire évoluer avec les produits proposés par la société Elastic (Watcher, Shield, …) ou de développer ses propres outils pour gérer les alertes par exemple.

Dès lors qu’une entreprise aura besoin d’une authentification pour les utilisateurs et d’alertes pour pouvoir agir rapidement, la solution Graylog sera la plus à même de répondre au besoin.

N’hésitez pas à tester les 2 solutions pour vous faire une idée et voir ce qui répond le mieux à vos besoins.

L’envoi des logs applicatifs vu par CommitStrip

Les logs applicatifs permettent de vérifier le bon fonctionnement d’une application et de logger les erreurs. Ils existent de nombreux outils et méthodes pour en tirer le maximum. CommitStrip a publié aujourd’hui une planche de BD très intéressante sur le sujet intitulée : « Savoir coder, c’est savoir logger« .

Strip-Log-nonstandard-1

Image de CommitStrip (source)

Ahhh, l’envoi des logs par email… j’avoue que j’ai utilisé cette méthode il y a de nombreuses années, mais lorsqu’un applicatif commence à envoyer des milliers de logs par minutes (un problème de boucle infinie, une connexion à la BDD HS, …), le serveur de mails ne tient pas très longtemps en général :-/

La centralisation des logs est une étape importante à ne pas négliger lors du développement d’un nouveau projet. Cela peut être réalisé via des solutions payantes comme Splunk ou open-source avec la stack ELK ou encore Graylog.

 

Le Graylog marketplace centralise les extensions pour Graylog

Graylog Marketplace est disponible à cette adresse : marketplace.graylog.org

Il s’agit de regrouper en un seul endroit l’ensemble des outils (plugins, content-pack, librairies et autres) pour faciliter l’intégration des logs et vous aider à tirer profit au maximum de la solution Graylog.

graylog_marketplace

Vous pouvez effectuer des recherches par mots clés ou parcourir la liste des outils. Chaque ressource dispose d’une fiche détaillant sa finalité et comment l’utiliser.

graylog_marketplace_addons

Quelques exemples :

  • Slack plugin : un plugin pour recevoir les alertes configurées sur les streams dans un salon Slack
  • Apache GELF log module : un module Apache pour envoyer les logs vers Graylog en GELF
  • GELF library for node.js : une librairie GELF pour node.js
  • Nginx content pack : un pack pour Nginx qui configure automatiquement 2 inputs (un pour les access_log, l’autre pour les error_log), des extracteurs afin d’extraire les données ainsi qu’un tableau de bord

 

Les nouveautés à venir sur Graylog 2.0

Depuis maintenant 15 jours, il est possible de tester une version alpha de Graylog 2.0. Le socle technique a été modifié pour permettre d’ajouter de nouvelles fonctionnalités : certaines sont déjà disponible dans la version de test et d’autres vont être ajoutées au fur et à mesure jusqu’à l’annonce de la version finale.

Rafraîchissement automatique des résultats :

L’outil de recherche intègre désormais l’équivalent de la commande linux tail -f. Vous allez pouvoir configurer le résultat de recherche pour être actualisés automatiquement sur une période allant de 1 seconde à 5 minutes. Il ne sera donc plus nécessaire de relancer la recherche pour voir les derniers logs arriver.

graylog_livetail

Configuration des périodes sur la recherche :

Le champ de recherche propose actuellement différentes périodes de recherche par défaut allant des 5 dernières minutes jusqu’au 30 derniers jours. Il est également possible de rechercher dans l’ensemble des résultats ce qui peut parfois provoquer des lenteurs sur des gros volumes de données.

Désormais, l’administrateur va pouvoir configurer 2 choses dans le menu « System > Configuration« .

  • La période maximale d’une recherche. Si le maximum est configuré à 15 jours, les utilisateurs ne pourront pas faire de recherche portant sur une période plus importante.
  • Les périodes de recherche proposée dans le sélecteur de temps relatif.
graylog_configuretimeframe

Source : graylog.org

Configuration de la rotation des index et de la rétention via l’interface

Jusqu’à présent, la configuration des index et la durée de rotation sont à configurer dans le fichier de configuration. Une modification d’une des règles imposait de redémarrer le service. Désormais, il sera possible de configurer ces éléments directement depuis l’interface web et il ne sera plus utile de redémarrer Graylog.

D’autres évolutions à venir :

Graylog dispose d’un site permettant de demander une fonctionnalité précise. Les utilisateurs peuvent ensuite voter pour les idées les plus intéressantes qui sont alors planifiées pour être développées. Ce site est disponible à cette adresse : graylog.ideas.aha.io

Dans les idées planifiées susceptible d’arriver sur la version 2.0 de Graylog, on trouve :

  • GL2E-I-356 : le support pour des rétentions différentes en fonction d’un input source ou d’un stream. Cela permettrait de supprimer par exemple de supprimer des logs non critiques après 15 jours et de garder les plus important sur une période d’un an.
  • GL2E-I-364 : intégration de Geoip pour obtenir des informations de géolocalisation en fonction d’une IP et ajout d’un widget sur le tableau de bord pour visualiser ces informations sur une carte géographique (comme Kibana le propose)
  • GL2E-I-399 : un bouton pour voir les messages à + ou – X secondes. Cela permettrait sur un log donné de voir ce qui s’est passé juste avant et juste après pour mieux comprendre une situation précise.

Si vous avez d’autres idées, n’hésitez pas à les remonter.

 

La version 2.0 de Graylog disponible en alpha-test

Au fur et à mesure des mises à jour, Graylog est devenu plus rapide et plus riche en fonctionnalités. Avec la montée en puissance du cloud, de l’architecture microservices, de Docker, … la centralisation des logs devient une étape importante et cruciale au sein d’une entreprise pour bien comprendre son infrastructure. Aussi, pour suivre les besoins des utilisateurs, Graylog continue d’évoluer et nous propose aujourd’hui de tester une toute première version de Graylog 2.0.

Il s’agit d’une version alpha, on est donc encore loin d’avoir toutes les fonctionnalités qui seront disponible dans la version finale. L’architecture même de Graylog a beaucoup évolué :

  • Auparavant découpé en 2 applications : graylog-server et graylog-web-interface, il n’y a désormais plus qu’un seul module qui regroupe les deux. Cela permettra de proposer des plugins qui pourront agir sur la partie web.
  • De gros changements dans l’intégration des logs : on devrait en savoir plus un peu plus tard
  • Elasticsearch 2.x : elasticsearch est également un produit qui évolue et pour tirer parti des nouveautés, il faudra désormais avoir un cluster Elasticsearch en version 2.

Pour tester cette version (à ne pas mettre en production), vous pouvez :

 

Envoyer des logs applicatifs vers Graylog

Graylog permet de stocker tout type de messages, qu’il s’agisse de logs serveurs, de journaux web ou de logs applicatifs. Ces derniers sont important car ils permettent de savoir ce qu’il se passe dans le programme. Les logs peuvent être de type DEBUG pour aider les développeurs, de type INFO lorsqu’il est nécessaire de conserver un historique des actions ou bien ERROR / CRITICAL si un problème important survient et impacte le bon fonctionnement.

L’objectif est bien de conserver et centraliser ces informations sur une plateforme dédiée comme Graylog. Pour cela, vous devrez :

  • Configurer Graylog pour accepter les logs
  • Configurer votre applicatif pour envoyer les logs vers Graylog

Avant cela, vous allez devoir choisir un protocole pour l’envoi des logs :

  • GELF : il s’agit d’un format conçu par Graylog pour ne pas avoir les limitations du syslog
  • RAW/plaintext
  • Syslog

Personnellement, je vous conseille d’utiliser le format GELF qui est très bien adapté aux logs applicatifs. Il permet en effet d’envoyer en plus d’un message horodaté des informations complémentaires sous forme de clé/valeurs. Cela peut être des informations sur le client, sur l’environnement, … (idClient=5, plateforme=préproduction, … par exemple). Ces éléments seront ensuite disponible sur l’affichage des logs mais aussi dans la recherche pour ne récupérer que les logs générés par un client donné.

Configurer Graylog pour accepter les logs

Connectez-vous sur Graylog et allez dans le menu « System/Inputs » puis « Inputs ». Sélectionnez ensuite le flux d’entrée de log à créer (GELF UDP par exemple) puis cliquez sur « Launch new input ». Vous devrez renseigner quelques informations comme un nom, le port, … Une fois l’input créé, pensez à cliquer sur le bouton « Start input ».

graylog_creation_input_gelf

Configurer votre applicatif pour envoyer les logs vers Graylog

Maintenant il va falloir permettre à votre logiciel d’envoyer les logs vers l’input précédemment créé. Pour cela, plusieurs solutions existent :

Si les développeurs en ont la possibilité, l’idéal est d’utiliser une librairie GELF qui permettra d’envoyer directement les logs vers Graylog. Il en existe pour tous les langages : java, php, node, ruby, … Une liste complète est disponible sur le marketplace de Graylog.

Par exemple pour un projet en Java utilisant logback comme framework de log, il suffit d’ajouter une dépendance à logback-gelf et d’ajouter la configuration suivante :


<configuration>
<appender name="GELF UDP APPENDER" class="me.moocar.logbackgelf.GelfUDPAppender">
<remoteHost>somehost.com</remoteHost>
<encoder class="me.moocar.logbackgelf.GZIPEncoder">
<layout class="me.moocar.logbackgelf.GelfLayout"/>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="GELF UDP APPENDER" />
</root>
</configuration>

Il peut être intéressant de configurer une écriture dans un log fichier en local avec un historique des logs très court et d’envoyer l’ensemble des logs vers votre serveur Graylog.

Dans le cas ou vous ne souhaitez pas utiliser de librairie GELF ou que ce n’est pas possible, vous pouvez conserver l’écriture des logs dans un fichier texte et utiliser un outil comme logstash ou Graylog Collector pour lire ce fichier et envoyer chaque ligne vers votre serveur Graylog.