Graylog est disponible depuis quelques jours en version 2.2.0. Pour cette release, le focus a été mis sur l’amélioration de 4 fonctionnalités : la rétention des données, les alertes, le système de pipeline et enfin le collector sidecar. Pour télécharger cette nouvelle version, je vous invite à vous rendre sur le site officiel.
Vous retrouvez plus d’informations sur les nouveautés dans le précédent article.
Présentation des nouveautés de Graylog 2.2
La prochaine version stable de Graylog sera la 2.2 et apportera plusieurs nouveautés. Cette version 2.2 est pour le moment en version beta : il est possible de la tester en utilisant une image OVA ou un script docker-compose (voir ici). Voici quelques détails sur les nouveautés :
Une page listant les alertes :
Une nouvelle page fait son apparition dans le menu permettant d’accéder à la liste des alertes qui ont été levées. Pour chacune des alertes, on trouvera un détail et le statut permettant de savoir si l’alerte est toujours d’actualité ou non.
La gestion « d’index set » :
Actuellement la rétention se configure de manière globale pour l’ensemble des logs. Avec la version 2.2, il sera possible de créer plusieurs « index set » permettant de configurer des règles de rétention différentes. Idéal si vous souhaitez par exemple conserver les logs de prod pendant 3 mois et les logs de dev/préprod pendant 15 jours seulement.
A la création d’un stream, il faudra spécifier l’index set qui sera à utiliser.
De meilleures performances pour les pipelines :
Les développeurs de Graylog ont améliorer le système des pipelines afin d’accélérer les traitements.
Voici une vidéo qui fait le tour des fonctionnalités de Graylog 2.2 :
Graylog est disponible en version 2.0
Le développement de Graylog a débuté en 2010 et ressemblait à ceci en version 0.9.x :
Aujourd’hui, Graylog est disponible en version 2.0 et ressemble plutôt à cela :
L’équipe en charge du développement a su améliorer l’outil au fur et à mesure en écoutant les besoins de la communauté des utilisateurs. Cette nouvelle mouture en version 2.0 apporte de nombreuses nouveautés. Voyons les améliorations disponibles :
Elasticsearch 2.0
Le stockage des logs est assurés par Elasticsearch qui était jusqu’à présent en version 1.x. Pour tirer profit des dernières nouveautés d’Elasticsearch 2, il vous faudra mettre à jour votre cluster. Une documentation (en anglais) est disponible pour l’upgrade.
Le serveur et l’interface Web ne font plus qu’un
Actuellement, il fallait installer la brique serveur ET la brique interface web. Désormais, l’ensemble des fonctionnalités sont disponible dans un seul package ce qui offre plusieurs avantages :
- une installation plus simple à réaliser
- une réécriture complète de l’interface web en react.js qui a permis d’enlever des limitations/bugs qui existaient dans la précédente version
- la possibilité d’étendre les fonctionnalités de l’interface web grâce aux plugins
Tail -f et messages du contexte
Deux nouveautés étaient très demandées : la première correspondant à l’équivalent de la commande shell « tail -f » pour avoir un rafraîchissement automatique de la page afin d’avoir les derniers messages. La deuxième permet d’afficher les messages qui entourent un log précis : cela permet d’en savoir plus sur le contexte dans lequel se trouve le log en question.
GeoIP et Map Widget
Grosse nouveauté là aussi, il est possible dans cette nouvelle version de mapper automatiquement une adresse ipv4 ou ipv6 avec une position géographique (latitude, longitude). Cela se fait en configurant le plugin « GeoIP resolver » (installé de base). Pour cela, il vous faudra :
- télécharger la base de données sur le serveur dans le dossier de votre choix. Base de données que vous pouvez trouver ici.
- activer et configurer le plugin GeoIP resolver en spécifiant le chemin sur disque e la base de données
- et c’est tout 🙂
Pipeline de messages
Le pipeline de messages est une grosse nouveauté qui permet de configurer depuis l’IHM le routage des messages. Il est possible de configurer des règles pour masquer certains champs comme des numéros de CB, de blacklister certains messages, de router selon vos propres règles les messages dans des streams, …
L’objectif est de simplifier les différents outils qui existaient actuellement à différents endroits comme les extracteurs, les règles drools, les règles pour les streams, …
C’est une partie qui est encore jeune et qui devrait évoluer dans le bon sens dans les prochaines mises à jour. Cette nouvelle fonctionnalité mérite un article complet.
Graylog Entreprise
Il est intéressant de noter également que cette version 2.0 marque également le lancement du premier plugin commercial : un plugin d’archivage. Rassurez-vous, Graylog est et reste open-source et la société derrière Graylog compte bien continuer à ajouter des fonctionnalités au fur et à mesure. Mais pour répondre au besoin des grandes entreprises, certains plugins plus poussés pourront être payant. Actuellement, la partie Entreprise est facturée USD $1,500 par an et par instance de graylog-server.
Pour finir, vous retrouverez les liens de téléchargement sur cette page.
Vous pouvez également tester très rapidement cette nouvelle version avec Docker :
$ docker run --name some-mongo -d mongo
$ docker run --name some-elasticsearch -d elasticsearch elasticsearch -Des.cluster.name="graylog"
$ docker run --link some-mongo:mongo --link some-elasticsearch:elasticsearch -d graylog2/server
RunAbove (OVH) lance un lab Paas Logs utilisant Graylog
RunAbove est le laboratoire technologique du groupe OVH chargé de transformer des idées en solutions techniques efficaces et répondant aux besoins des clients.
Dès lors qu’un nouveau produit est prêt à être testé, il est proposé sous forme de « lab » aux utilisateurs qui peuvent alors le tester gratuitement (il faut juste créer un compte sur la plateforme RunAbove). Après une période de plusieurs mois, l’équipe RunAbove peut décider en fonction des retours des utilisateurs de fermer le lab s’il ne répond pas au besoin initial ou de le transformer en produit OVH.
Actuellement, 10 labs sont proposés sur la plateforme RunAbove dont un dédié à la gestion des logs. Ce lab nommé « Paas Logs » utilise tout le potentiel de Graylog ! Une option permet même d’utiliser Kibana pour pouvoir créer des dashboards plus visuels.
Pour tester cette solution, vous devrez au préalable créer un compte sur RunAbove en cliquant ici puis une documentation très complète vous accompagnera pas à pas pour envoyer vos premiers logs dans le cloud et ouvrir votre accès à Graylog.
Depuis votre compte RunAbove, vous allez pouvoir créer un utilisateur : le login et mot de passe vous permettront d’accéder à l’interface Graylog. L’interface vous permettra ensuite de configurer les Streams, Inputs, Dashboards, … Pour ce lab, il n’est pas possible de créer plus d’un stream ou plus d’un dashboard.
L’étape suivante consiste à créer un Stream : un token vous sera attribué et il devra être envoyé avec chaque log pour être routé dans le bon stream. Les logs peuvent être envoyés au format GELF, LTSV, RFC 5424 ou Cap’n’Proto.
Exemple pour envoyer un log au format GELF en ligne de commande :
echo -e '{"version":"1.1",
"_X-OVH-TOKEN":"d93eee2a-697f-4bac-a452-705416b98a04",
"host": "example.org",
"short_message": "A short message",
"full_message": "Backtrace here\n\nmore stuff",
"timestamp": 1385053862.3072,
"level": 1,
"_user_id": 9001,
"_some_info": "foo",
"some_metric_num": 42.0 }\0' |
openssl s_client -quiet -no_ign_eof -connect laas.runabove.com:12202Vous pouvez également depuis l’écran principal créer un dashboard, gérer des alertes sur vos streams pour être prévenu en cas de problème, créer des inputs pour logstash ou flowgger, …
RunAbove utilise toute la puissance des API proposées par Graylog pour créer automatiquement les users, les streams avec la règle de routage sur le X-OVH-TOKEN, les dashboards, … Vous avez ensuite accès à vos logs à l’adresse https://laas.runabove.com/graylog/login avec votre compte utilisateur initialement créé.
Pour ceux qui le souhaite, il est également possible d’activer une option pour Kibana. En installant alors Kibana sur votre serveur web, vous pourrez le configurer pour se connecter directement à votre compte sur le lab Paas Logs de RunAbove et ainsi visualiser vos données sous toutes les coutures.
Cette solution est idéale pour ceux qui ne souhaite pas gérer les serveurs et l’installation de Graylog mais qui veulent malgré tout pouvoir centraliser les logs, les consulter facilement et être alerté en cas de problèmes. Pour le moment, le test est gratuit. Nous verrons d’ici quelques mois si cette solution imaginée par RunAbove rencontre le succès qu’elle mérite et si elle passe en production chez OVH. Restera alors à voir le coût d’une telle solution.
Graylog v2.0 disponible en bêta.1
Après plusieurs version alpha, Graylog 2.0 arrive en version bêta. On est proche de la version finale mais quelques bugs peuvent encore exister. Parmi les nouveautés, on retrouve certaines améliorations déjà évoquée dans un précédent article :
- Le rafraîchissement automatique des résultats (comme un tail -f)
- La configuration des périodes sur la recherche
- La configuration de la rotation des index et de la rétention via l’interface
- L’intégration de Geoip pour obtenir des informations de géolocalisation en fonction d’une IP et ajout d’un widget de type carte géographique
Mais les évolutions sont encore plus complètes avec beaucoup d’autres nouveautés :
- Le support d’Elasticsearch 2.0
- Un nouveau système de routage des messages « Pipelines » pour être plus modulaires
- Un plugin d’archivage (soumis à licence)
- Un plugin « Collector sidecar » qui aura pour objectif de simplifier la configuration des outils tiers comme nxlog, logstash, …
- L’affichage des messages entourant un log particulier permettant de voir les messages enregistrés juste avant et juste après à X secondes
- …
Cette nouvelle version se veut résolument plus modulaire : la communauté pourra très facilement étendre les fonctionnalités en développant des plugins.
Le fondateur de Graylog a également annoncé le lancement d’un plugin d’archivage qui ne sera pas open-source. Ce plugin sera payant et permettra à l’équipe de développement de travailler au mieux sur la partie open-source du logiciel. Lennart Koopmann précise par ailleurs que les principales fonctionnalités de Graylog sont et resteront toujours open-source.
Tester les nouveautés de Graylog 2.0 avec Docker
Graylog 2.0 est actuellement en phase de développement et depuis début février, il est possible de tester les dernières nouveautés grâce à des releases en alpha-test. Toutes les nouvelles fonctionnalités ne sont pas encore disponible, mais cela permet de tester et remonter d’éventuels bugs aux développeurs.
Actuellement, la 5ème version alpha est disponible en cliquant ici sous forme d’OVA (image virtuelle) ou dans une archive avec le livrable qu’il faut configurer soi-même.
Pour tester, on peut également utiliser Docker. Voici comment procéder :
Pré-requis : vous devez avoir Git et Docker d’installer sur le serveur.
$ # Récupération du Dockerfile
$ git clone https://github.com/Graylog2/graylog2-images.git
$ cd graylog2-images/docker
$ # Construction de l'image en local
$ docker build -t graylog-server - < Dockerfile.server
$ # Démarrage des containers pour mongodb et elasticsearch
$ docker run --name some-mongo -d mongo
$ docker run --name some-elasticsearch -d elasticsearch elasticsearch -Des.cluster.name="graylog"
$ # Démarrage du container pour la version alpha de Graylog 2.0
$ docker run --link some-mongo:mongo --link some-elasticsearch:elasticsearch -d graylog-server
Attendez ensuite quelques secondes que les services démarrent correctement puis vous pourrez accéder à Graylog via l’ip du container : http://<container-ip>:9000
Le login et mot de passe par défaut sont : admin / admin
Pour récupérer l’ip du container, vous pouvez utiliser les commandes suivantes :
$ # Affichage de la liste des containers et des ids
$ docker ps
$ # Affichage des propriétés du container (dont l'ip)
$ docker inspect
Avec la version alpha-5, vous allez pouvoir tester :
- le rafraichissement automatique des résultats de recherche
- le nouveau système de pipeline (je reviendrais dessus dans un prochain article)
- le nouveau widget affichant une mappemonde
- …
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, …
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.
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« .
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.
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.
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.
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.
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.