Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

GRAYLOG : Centralisation des logs et données messages

Par Francis VIALLET Publié le 04/01/2017 à 15:23:49 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Présentation de Graylog

Graylog est une solution open-source de gestion de messages/texte/logs. Chaque message reçu par un nœud serveur est enregistré dans une base de données Mongo DB indexée via Elasticsearch. Une interface web permet de gérer et analyser les données.

Graylog2 est découpé en 2 parties principales : graylog-server et graylog-web. La première est une application Java qui accepte les messages sur différents protocoles : UDP, TCP, GELF, AMQP, …. Une API Rest est également intégré à l’outil et est notamment utilisée par la partie web-interface. Celle-ci (la deuxième partie), vous permet de gérer des utilisateurs, des streams et des Dashboard.

  • Architecture Utilisée ici (un serveur avec tous les rôles) :

  • Architecture répartie / en clusters :

Quelques usages possibles :

  • Centralisation des messages

  • Big Data

  • Vue globales de l'état des ressources

  • Debug d'applications

  • Gestion des exeptions

  • Analyse (Du réseau par exemple via les messages de équipements, des niveaux d'erreurs, etc.)

  • Alertes directes (par ex. : lors d'une connection, de l'execution de certaines commandes, etc.)

  • Etc.

Installation

Nous allons donc commencer par installer l’OS (Debian, car stable, documenté, utilisé déjà dans l’entreprise, et un paquet .deb est créé pour chaque version par l’équipe Graylog), avec le JRE 7 de l’Open JDK. Puis nous installerons MongoDB pour stocker nos logs, users, etc… Ensuite Elasticsearch pour l’indexation etc…, Puis Graylog (Server et WebInterface), en expliquant les deux options (Via compilation des sources ou via le package .deb (recommandé)).

Documentation Graylog :

http://docs.graylog.org/en/latest/

Debian 8

Minimum: 4 GB – 2CPU – HDD 30Go

Il s’agit d’une installation classique de Debian :

Si pas de DHCP pour le réseau, on le configure nous-même :

Puis on continue :

On créé nos user (root; et un autre choisi).

On partitionne le disque nous-mêmes (/home ne sera pas souvent utilisé car nous utiliserons root dans /, et en tant que logserver la partition /var est importante (elle contiendra les logs du serveur, et la base MongoDB de logs de l’infrastructure) :

Créer une nouvelle partition

On affecte 17.1 Go, ce sera la partition root, primaire, en début de disque :

Sélectionner ensuite l’espace libre et refaire la même chose pour chaque partition afin d’arriver au résultat suivant :

On termine et on applique.

ATTENTION : ceci est pour une architecteure de test; pour l'utiliser en entreprise, Mettre en place du LVM, ou au minimum mettre la partition /var à la fin afin de pouvoir l'agrandir si l'on agrandit le disque dans le cas d'un serveur virtualisé. Dans l'idéal, mettre /var sur un disque séparé.

On continue :

Debian est installé, la machine va maintenant redémarrer dessus.

Vérifications, configurations et agrémentations de base : On vérifie hostname, hosts, config IP, DNS:

On va aussi mettre en place la synchronisation de l’heure avec le serveur ntp du domaine afin que les authentifications se fassent correctement, et que nos logs soient correctement horodatés. (On va utiliser ntpdate, et le planifier) :

NTPDATE_USE_NTP_CONF=no : indique à ntpdate d’utiliser la liste NTPSERVERS ci-dessous pour synchroniser l’heure.

NTPSERVERS= : indique les serveurs de temps à utiliser pour la synchronisation de l’heure.

NTPOPTIONS= ‘’ -u ‘’ : passe une option à la commande NTP (-u permet d’utiliser des ports non-privilégiés pour faire passer la requête, ceci est utile au cas où on se trouve derrière un firewall strict par exemple).

On lance une synchronisation de l’heure et on vérifie si elle est dorénavant correcte :

On planifie l’exécution de la synchronisation à l’aide de cron (crontab –e) :

# SYNCHRO NTP

18 1 * * * /usr/sbin/ntpdate-debian

@reboot /usr/sbin/ntpdate-debian

(La ligne 1 va synchroniser l’horloge à 18h01 tous les jours).

(La ligne 2 lance la synchronisation au démarrage).

(On peut aussi ajouter : @hourly /usr/sbin/ntpdate-debian afin de lancer la synchronisation toutes les heures).

On installe VIM et SSH (on autorise le root login pour ssh et on active des options ergonomiques pour VIM) :

Remplacer « without-password » par « yes »

Pour VIM :

On va éditer et récupérer le .bashrc plus ergonomique d’un user Debian puis remplacer celui de root avec :

Décommenter les lignes suivantes :

Le .bashrc est exécuté à l’ouverture de session : se déconnecter puis reconnecter pour appliquer les changements.

On vérifie les sources et on fait un Full- Upgrade :

Si c'est une VM, on installe les Tools :

On éteind la VM (« poweroff » ou « halt – p » ou « shutdown –h now ») et on fait un snapshot (à l’état arreté) puis on la démarre, et on va passer à l’étape suivante (installation du Java Runtime environment 7).

OpenJDK

On installe le java runtime environment 7 open source validé pour graylog (« open-jdk-7-jre »), et non le propriétaire oracle :

MongoDB

On installe MongoDB, le serveur pour pouvoir s’y connecter, et le client pour pouvoir se connecter au serveur via le terminal et ainsi administrer MongoDB en ligne de commandes :

On démarre le serveur, on vérifie le statut du service, et on l’active au démarrage (Debian 8 Jessie est passé sous systemd, et n’utilise plus sysv (/etc/init.d ; etc..) sauf pour rétrocompatibilités avec le package systemd-sysv) :

MongoDB n’a par défaut pas d’utilisateurs après installation. La « LocalHost Exeption » (qui permet à tout utilisateur depuis la ligne de commande du serveur local (et donc se connectant sur le serveur Mongo via la boucle locale) d’avoir les droits admin complets), est donc normalement activée par défaut.

Remarque : Si après diverse manipulations des utilisateurs existent mais qu’ils n’ont pas assez de droits et que l’exeption localhost est désactivée, redémarrer le serveur mongoDB avec l’option --noauth , ou modifier /etc/mongodb.conf en décommentant #noauth = true et commentant #auth = true, puis redémarrer mongodb (systemctl mongodb restart)(pour activer la « localhost exeption »).

(Attention : la version de MongoDB dans les dépôts Debian (2.4) est un peu ancienne, les commandes de la documentation Mongo peuvent ne pas être entierement compatibles, lizez bien la bonne version de la documentation).

Nous allons donc créer l’utilisateur « root » de mongoDB (dans la BDD « admin », qui est pour l’instant vide).

II disposera du maximum de privilèges que nous pouvons lui accorder avec les rôles « buil-tin » (http://docs.mongodb.org/v2.4/tutorial/add-user-administrator/) (http://docs.mongodb.org/v2.4/reference/user-privileges/) :

(on voit que la BDD admin est vide)

On va créer notre user root avec tous les droits :

On voit que les tables système nécessaires au stockage de ces informations ont étées crées dans la base « admin » :

Maintenant que notre superutilisateur à été créé, nous allons l’utiliser pour administrer notre instance MongoDB. Nous désactivons donc la possibilité de connexion sans authentification via la boucle locale, puis on redémarre mongodb (systemctl restart mongodb) :

On en profite aussi pour désactiver l’interface web :

Notre utilisateur d’administration « root » est maintenant créé dans la BDD « admin ».

Pour se connecter à notre instance Mongo dans le but de l’administrer, il faudra donc utiliser cet utilisateur et son mot de passe en renseignant la BDD « admin » comme source d’authentification pour ouvrir la session :

(on remarque que notre utilisateur « root » à les droits escomptés, et qu’un utilisateur non authentifié ne peut rien faire).

Afin de réduire les risques, allons créer un utilisateur « graylog-dba » pour la future BDD « graylog ». Cet utilisateur ne disposera de droits que sur cette base de données, et sera stocké dans cette base de données (http://docs.mongodb.org/v2.4/tutorial/add-user-to-database/) :

(En rouge le mot de passe de l’utilisateur « root » pour se connecter avec les droits d’administration, en vert le mot de passe souhaité pour l’utilisateur « graylog-dba »).

(l’utilisateur a bien les droits escomptés)

Enfin, il aurait été intéressant d’activer SSL pour la communication graylog-server <-> MongoDB (à moindre niveau tout de même car la communication passe par la boucle locale dans notre cas), mais le graylog server ne le supporte pas encore : (http://docs.mongodb.org/manual/tutorial/configure-ssl/).

Exemple pour activer SSL (à ne pas faire) :

  • Création de certificats auto-signés (protège contre l’ « eyedropping » mais pas contre « MITM » car pas de vraie certification), puis de la PEM :

  • Activation dans la configuration mongodb :

  • Activation dans la configuration Graylog-Server :

Mais graylog ne supporte pas encore le SSL vers MongoDB : On ne fait donc pas cette configuration :

Approfondissement/Remarques :

Les fichiers de données :

Par défaut, les fichiers de données sont stockés dans le répertoire /var/lib/mongodb. Ces fichiers pouvant devenir volumineux, il est parfois nécessaire de les déplacer. Pour ce faire, il faut effectuer les opérations suivantes en super-utilisateur :

  • Arrêter le service mongodb avec la commande « systemctl stop mongodb »

  • Déplacer les fichiers du répertoire /var/lib/mongodb vers leur nouvel emplacement

  • S'assurer que les permissions des fichiers sont correctes (notamment l'utilisateur propriétaire mongodb), y compris sur le répertoire parent.

  • Modifier la ligne dbpath=/var/lib/mongodb dans le fichier de configuration (/etc/mongodb.conf) pour indiquer le nouvel emplacement

  • Relancer le service mongodb avec la commande « systemctl start mongodb »

Connexions :

Par défaut, la connexion à mongodb n'est possible que localement. Pour rendre la connexion possible depuis une autre machine, il suffit de commenter la ligne bind_ip = 127.0.0.1 dans le fichier de configuration. Il est aussi possible de modifier le port TCP utilisé (27017 par défaut) en décommentant la ligne port = 27017. Assurez-vous que votre pare-feu ou votre routeur laisse passer le trafic sur le port concerné, le cas échéant. Il est de plus conseillé dans ce cas d’activer authentification et SSL.

Elasticsearch

On se rend sur le site elastic pour télécharger elasticsearch (« products > elasticsearch > download > DEB »), puis on le copie dans /tmp/ par SCP sur notre serveur ou on utilise wget

(on peut (ou pourra plus tard lors de MAJ si pour l’instant on souhaite utiliser DPKG) aussi utiliser les dépots elastic si souahité. Ainsi on pourra faire apt-get install elasticsearch après avoir installé apt-transport-https et configuré le proxy si il y a lieu, et fait un update et elasticsearch sera de plus mis à a jour lors d’un ‘apt-get update’. Pour ce faire, cf.Partie MAJ)

:

Son fichier de configuration est alors : /etc/elasticsearch/elasticsearch.yml

On va éfiter sa configuration :

Puis nommer notre cluster Elasticsearch :

Puis nommer notre noeud Elasticsearch :

Ce nœud est le master (on à qu'un soeul noeud :celui-ci, dans cette infra de test) :

Puis on démarre le service et l'ajoute au démarrage :

Graylog

On se rend sur le site de packages de graylog :

https://packages.graylog2.org/packages

Et on télécharge la dernière version pour Debian 8 :

https://packages.graylog2.org/repo/packages/graylog-1.1-repository-debian8_latest.deb

OU

On télécharge les sources sur www.graylog.org pour installation par compilation :

On place les fichiers dans /tmp/ (On les télécharge directement sur la Machine avec wget par exemple, ou on les copie dessus ultérieurement via SCP).

Installation avec DPKG

Le .deb va installer un dépôt APT pour Graylog, non Graylog lui-même :

On installe le support https pour Apt (requis pour ensuite installer Graylog) et on met à jour notre liste de paquets :

On installe ensuite nos deux composants Graylog :

Les fichiers de configuration sont situés dans « /etc/graylog » :

  • «./server » pour la configuration du composant serveur.

  • «./web» pour la configuration du composant web interface.

Installation depuis les sources

Après avoir récupéré puis placé les deux sources dans /tmp/ :

cd /tmp/

tar xzf LesFichiersSource

Pas de compilation, il suffit de copier les différents répertoires dans les bons répertoires système ; exemple :

cp graylog.conf.example /etc/graylog/server/server.conf

cp –r /web/conf/ /etc/graylog/web/

Pour les scripts systemd (pour démarrer/redémarrer/arrêter, etc. les serveurs) :

https://github.com/hadret/scripts-graylog2

On peut ensuite passer à la configuration.

Configuration & Interconnection des composants ; Rétention

  • Le graylog-server :

Le grand administrateur de ce Graylog-Server : utilisable depuis l’interface web, il dispose du maximum de droits sur ce nœud graylog-server, et doit être configuré après l’installation. C’est le seul se situant dans le fichier de configuration car propre à ce serveur, et non au cluster ou à l’interface web.

Le compte avec les droits root de Graylog sera stocké dans le fichier de configuration et non dans la BDD (ce qui sera le cas des autres utilisateurs). Le but est de ne pas stocker un compte en clair dans un fichier de configuration. On va donc hasher l’ensemble.

On installe pwgen pour le « password_secret » : il s’agit d’une clé secrète (pepper) qui sera utilisée pour sécuriser les mots de passe.

pwgen –N 1 -s 96

(http://stackoverflow.com/questions/16891729/best-practices-salting-peppering-passwords)

On génère la clé secrète :

On génère ensuite le hash du mot de passe de notre compte super admin (qui sera stocké dans la variable « root_password_sha2 » du fichier de configuration).

echo –n ChosenPassword | shasum -a 256

On le génère (la valeur ne comprends pas le « - ») :

Puis on les rentre dans le fichier de configuration (et on choisit par ailleurs un nom d’utilisateur « root_username ») (vi /etc/graylog/server/server.conf) :

On configure ensuite la zone de temps (important, il est préférable que nos différents rôles aient la même, et afin que nous puissions avoir la bonne heure à côté des messages reçus sur l’interface en étant connecté avec ce « grand administrateur ») (ls -l /usr/share/javazi/Continent/Ville pour avoir la syntaxe de la zone de temps souhaitée) :

Nous n’avons pas de cluster, nous ne faisons écouter l’API REST que sur la boucle locale :

Préfixes pour les index et alias Elasticsearch, créés/utilisés par Graylog. Nous choisissons « graylog » comme préfix :

Nous renseignons le nom de notre cluster Elasticsearch (configuré lors de l’installation du serveur Elasticsearch) pour que le client graylog s’y connecte, ainsi que le nom du nœud :

Le client Elasticsearch (tout comme le serveur) dispose de la faculté de découvrir ses pairs via du multicast, mais cela est lent et imprécis ; nous désactivons donc cette fonctionnalité (que nous avons déjà désactivée sur le serveur lors de l’installation) et renseignons les IP de découverte d’hôtes en Unicast (un seul hôte : ce serveur, nous mettons son IP & sa boucle locale, en laissant le port 9300, qui est aussi le même que configuré dans Elasticsearch server) :

On indique les informations de connexion et d’authentification (obligé car activé dans la configuration MongoDB) pour la base de données « graylog » crée précédemment lors de l’installation/configuration de MongoDB :

Mongodb_uri = mongodb://UserAuthorisedOnDataBase:[email protected]:Port/DataBase

On démarre le « graylog-server », on check si il a bien démarré, et on ajoute le service au démarrage :

On vérifie que les tables sont dans la bonne BDD et bien crées :

Remarques : Options de configuration "pratiques" :

« allow_leading_wildcard_searches = true » : permet d’utiliser le joker “*” en début de requête par exemple (Attention, à tester car peut occasionner une rosse consommation de ressources).

« allow_highlighting = true » : permet de mettre en surbrillance les mots recherchés dans les résultats (Attention, à tester car peut occasionner une rosse consommation de ressources).

  • Le graylog-web :

On configure le serveur web qui publiera les données récupérées sur le graylog-server via l’API REST :

« graylog2-server-uris » : URLs de communication avec l’API REST de nos graylog-server.

(Ici un seul serveur, nous renseignons sa boucle locale et le port 12900 : comme configuré dans le server.conf, partie « #REST API Listen URIs ».).

(Nous ajoutons aussi l’IP du serveur même si l’API REST n’écoute pas sur ce réseau ni cette IP, utile au cas où nous évoluons dans l’architecture…).

Nous créons aussi une clé secrète pour les instances du graylog-web avec « pwgen –N 1 –s 96 » puis nous la renseignons dans « application.secret ».

Enfin nous renseignons la bonne « timezone » (ici « Europe/Paris ») :

RQ : « field_list_limit » permet de modifier la limite d’affichage de champs lors de résultats de la recherche (« 100 » par défaut, mettre « 0 » pour tout afficher). Ne pas modifier, car si trop de champs, cela occasionnera beaucoup trop de charge sur le serveur.

On démarre le graylog-web, on check si il a bien démarré, et on ajoute le service au démarrage :

Le serveur écoute par défaut sur le port 9000 : http://10.138.224.55:9000/

On peut désormais s’y connecter :

Pour changer le port par défaut d’écoute du serveur web graylog, on pouurais modifier son script de démarrage systemd (/usr/share/graylog-web/bin/graylog-web) (appelé par /etc/systemd/system/multi-user.target.wants/graylog-web.service) :

Puis passer le port de 9000 à 80 (port http standard) :

Mais ça n'est pas très propre.

Le logicel suivant les bonne pratiques, on remarque le sourcing du fichier de configuration default (qui écraserai les réglages faits au-dessus).

Nous allons donc uniquement éditer le fichier default configuration (vi /etc/default/graylog-web) :

Procédure d'update

Il est recommandé de faire une Mise à jour lors de nouvelles versions de Graylog.

Lors de cette mise à jours nous en profiterons pour :

  • Faire un Snapshot de la VM

  • Préparer et Mettre à jour Elasticsearch

  • Vérifier les dépôts Graylog et les changelogs etc.

  • Mettre à jour tout le système Debian et Graylog (Comprenant aussi l’OpenJDK et MongoDB car installés depuis les dépôts Debian) - Laisser en test avant de supprimer le Snapshot - Mettre à jour les Notes de Mises à Jour

Il va de soi que nous regarderons les changelogs, etc. afin de s’assurer de la réussite des MAJ, et regarderons s’il n’y a pas de changements dans les fichiers de configuration avant d’appliques les Mises à jour.

Snapshot

Toujours faire un Snapshot ou une sauvegarde de la machine avant une Mise à Jour.

Elasticsearch

On regarde sur quelle version d’Elasticsearch nous sommes :

On voit qu’il y a une MAJ disponible sur le site Elasticsearch, on va regarder les journaux des changements. ICI on remarque que le passage à la version 1.7.1 ne devrait pas poser de problèmes (de plus dans la documentation graylog on voit que toute version supérieure à la 1.3.7 est OK.) :

On vérifie pour être sur les « Breaking Changes », et on remarque qu’il n’y a pas de dispositions particulières (https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes.html) :

Nous n’avons qu’un seul nœud à mettre à jour, pour plusieurs nœuds, il est possible faire une « rolling upgrade » afin de ne pas avoir d’interruption de service (https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades). Nous allons donc ajouter les dépôts Elasticsearch (https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-repositories.html).

Pour cela on commence par ajouter la clé GPG Publique pour pouvoir communiquer de manière chiffrée avec les dépôts Elastic.

On récupère donc la clé et on la met dans /tmp/ via scp (ou on utilise wget directement sur le serveur Debian) : https://packages.elastic.co/GPG-KEY-elasticsearch

Puis on l’ajoute :

Et on ajoute l’adresse du dépôt Debian dans la configuration des sources d’APT (‘echo "deb http://packages.elastic.co/elasticsearch/1.7/debian stable main" | tee -a /etc/apt/sources.list.d/elasticsearch-1.7.list’):

(« tee » copie ce qu’il a en entrée (donc la sortie de la commande echo grâce au « | ») sur la sortie standard (ce qui explique que le retour fait par cette commande soit le résultat de la commande echo), mais aussi dans tous les fichier passés en argument (et donc dans ‘/etc/apt/sources.list.d/elasticsearch-1.7.list’)).

(Nous sommes prêts pour la mise à jour d’Elasticsearch via apt-get qui viendra partie suivante).

Graylog

On voit sur le site http://www.graylog.org qu’une nouvelle version est sortie :

Sur notre serveur on remarque que nous sommes en 1.1.4 (« System>Nodes>Details ») :

On observe les notes de mise à jour de chaque version supérieure afin de voir si nous devons réaliser des manipulations spécifiques. Il n’y a rien de noté pour notre cas, nous pouvons migrer directement de la 1.1.4 vers la 1.1.6 :

On check aussi le changelog afin de voir si des précautions nécessaires sont à observer (version d’Elasticsearch compatible avec le client car ici le client est mis à jour, etc.) :

On vérifie les dépôts (facultatif sauf si erreur lors de l’ « apt-get update ») :

Sinon le .deb pour le mettre à jour : https://packages.graylog2.org/debian/pool/jessie/1.1/g/graylog-1.1-repository-debian8 :

Application des MAJ

On met à jours la liste des packages présents dans les dépôts configurés pour APT :

On lance le téléchargement des paquets plus récents que ceux installés ; et leur installation (avant de valider, on vérifie que les paquets mis à jour n’apporteront pas de problèmes) :

On redémarre alors Elasticsearch; mongo-db; graylog-server; graylog-web:

On vérifie qu’ils ont bien redémarré :

Enfin, pour s’assurer d’un système le plus à jour possible et vérifier et mettre à jour les paquets dont l’upgrade est bloquée à cause de dépendances : on réalisera un ‘dist-upgrade’ (dans l’exemple suivant aucune mise à jour n’est possible) :

Si nous voulons faire une montée de version (Par exemple lorsque le successeur de Debian Jessie passera en Stable), il faudra mettre à jour le fichier ‘/etc/apt/sources.list’ avec les sources du successeur Debian 9 « Stretch » au lieu de Debian 8 « Jessie » et aussi celles des logiciels tiers dans ‘/etc/apt/sources.list.d/*.list’ si des plus récentes sont disponibles.

  • On fera alors un apt-get autoremove --purge pour s’assurer que les paquets/dépendances inutilisée et oubliées soient supprimées pour éviter les conflits :

  • Puis on mettra à jour notre base de paquets :

  • On commencera alors par une mise à jour minimale du système pour éviter les conflits (Cette commande met à niveau les paquets qui peuvent l'être sans entraîner l'installation ou la suppression d'autres paquets) :

  • Puis on mettra à niveau tout le système (Cette commande effectue une mise à niveau complète du système, en installant les versions les plus récentes de tous les paquets, et en résolvant tous les changements possibles de dépendances entre paquets des différentes versions. Si nécessaire, elle installe de nouveaux paquets (habituellement de nouvelles versions de bibliothèques, ou des paquets ayant changé de nom), et retire les paquets obsolètes en conflit). Nous examinerons donc avec encore plus d’attention la liste des paquets à supprimer qui s’affichera avant de valider :

    (Les paquets déjà installés ayant une nouvelle version, mais qui ne peuvent être installés sans modifier l'état d'un autre paquet, seront laissés dans leur version actuelle (et affichés comme retenus — « held back »). Cela peut être résolu soit en utilisant aptitude et en choisissant d'installer ces paquets, soit en essayant apt-get install paquet).

  • On supprime les reliquats de configuration des paquets supprimés (« dpkg -l | awk '/^rc/ { print $2 }' » affiche une liste de tous les paquets supprimés qui pourraient avoir laissé des fichiers de configuration sur le système) : apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')

  • Un reboot et vous serez sur la nouvelle version de Debian.

RQ : il est préférable de préalablement désactiver le « pinning » si utilisé pour aller chercher des paquets dans une autre distribution que celle utilisée (par exemple dans « testing » pour avoir les version d’un logiciel plus récentes) en éditant ‘/etc/apt/preferences’ et ‘/etc/apt/preferences.d’ pour éviter les problèmes de blocage d’installation à cause de dépendances non résolues car impossible à mettre à la bonne version car liées à ce pinning (sur une distribution priopre aucun pinning n’est fait par défaut bien sûr) :

Pour plus de détails : https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.html

Mettre à jour les notes de MAJ

Elles sont situées tout à la fin à la partie « NOTES DE MISES A JOUR ».

Afin d’avoir un suivi des mises à jour effectuées, des problèmes rencontrés et de leurs résolutions, ajouter un « Titre2 » du Type « x) MAJ JJ/MM/AAAA » puis renseignez :

  • Paquets de l’infrastructure (OpenJDK, MongoDB, Elasticsearch, Graylog-Server, Graylog-Web) Mis à jour (Nom du paquet ; Version avant MAJ ; Version après MAJ)

  • Liste des Paquets mis à jour (/var/log/apt/history.log)

  • Problèmes rencontrés et leur résolution

Supprimer Snapshot après tests

Après quelques temps de test vous pouvez supprimer le Snapshot de la machine.

Connexion et Utilisation

On se rend sur l’IP:9000 ; (ou IP:80) si l’on a suivi la procédure pour changer le port) :

Premier tour de l'interface

Search : tous les messages apparaissent ici, il est aussi possible d’en rechercher spécifiquement, etc.

Streams : Permet de créer des flux, afin de filtrer les messages entrants, et donc pouvoir ne donner les droits à un utilisateur que sur certains flux et non toute la base, mais aussi créer des alertes, forwarder les messages entrants etc. C’est la base pour la gestion des droits sur graylog.

Dasboard : Pages d’accueils en widget permettant d’afficher des résumés d’informations sur un Stream, ou une recherche. On peut aussi donner les droits à un utilisateur que sur certains dashboard.

Sources : Vue d’ensemble des sources des messages entrants.

  • Overview : vue d’ensemble de l’état du système.

  • Nodes : affiche l’état du cluster graylog et des nœuds le composant.

  • Inputs : permet d’ouvrir des flux en acceptant les messages entrants suivant certains protocoles/ports.

  • Output : Permet de Forwarder(Transférer) des messages (d’un stream, etc.) vers un autre nœud ou équipement, etc (nous n’y utiliserons pas).

  • Collectors : Les graylog-collector (agent java léger développé par l’équipe graylog à installer sur des OS utilisé pour transmettre les logs à graylog) en activité (nous ne les utiliserons pas).

  • Indices : Contient la liste des index, leurs données, leur état, la possibilité de forcer le passage à un nouvel index, d’en supprimer, etc.

  • Logging : configure la politique de journalisation des activités du système graylog.

  • Users : permet de gérer les utilisateurs/droits.

  • Content Pack : Permet d’ajouter des pack de contenus pour certains types de services/équipements (nous ne l’utiliserons pas).

  • Grok Patterns : Patterns en langage grok pouvant être réutilisés dans des extracteurs afin de remettre en forme les messages réceptionnés (nous n’utiliserons pas cette méthode).

Ajouter des Inputs

Pour cela on se rend dans « System > Inputs » sur l’interface Web :

Nous allons utiliser le Protocol Syslog, donc des Inputs Syslog pour écouter collecter les messages :

Nous utiliserons le port Syslog par défaut (514) pour les switches/routeurs HUAWEI, car il n’est pas possible d’en changer dans la configuration des switches.

En revanche, pour les autres périphériques nous utiliserons d’autres ports, afin de séparer les flux par Inputs (il est décidé d’utiliser ceux à partir de 1514).

Hôtes rsyslog (ex.: OS Debian)

« Rsyslog », est le système de traitement de log par défaut sous Debian (et la majeure partie des OS linux) ; il permet de la transmission via TCP (plus fiable que l’UDP), que nous utiliserons. Le post utilisé sera le 1520. On choisit donc « Syslog TCP » puis « launch new input » :

La page de configuration du nouvel input s’ouvre :

  • On le lance sur notre nœud (on en a qu’un), on peut aussi cocher la case « Global Input » qui va le lancer sur tous nos nœuds, ce qui importe peut car nous n’avons pas d’autres nœud sur lequel le démarrer.

  • On le nomme explicitement « Debian Hosts (rsyslog) »

  • On renseigne le port TCP choisi (1520)

  • On le bind sur 0.0.0.0 pour écouter sur tous les réseaux.

  • On autorise de remplacer la date reçue par celle du serveur si elle n’est pas lisible dans le message reçu.

  • On stocke le message complet dans « full_message » pour ensuite pouvoir en extraire des données (vu plus tard).

  • On laisse les autres options par défaut, leurs valeurs nous conviennent.

  • On clique sur « Launch » pour lancer la capture.

Notre Input est lancé :

Switches Huawei

Le système de traitement des logs est géré par l’« info-center », sur les switches HUAWEI. Il permet l’envoi de logs via UDP uniquement, et il n’est pas possible d’en changer de port. Nous utiliserons donc un Input Syslog UDP sur port 514.

On choisit donc « Syslog UDP » puis « launch new input » :

La page de configuration du nouvel input s’ouvre :

  • On le lance sur notre nœud (on en a qu’un), on peut aussi cocher la case « Global Input » qui va le lancer sur tous nos nœuds, ce qui importe peut car nous n’avons pas d’autres nœud sur lequel le démarrer.

  • On le nomme explicitement « Huawei Switches (Info-Center)»

  • On laisse le port UDP par défaut (514)

  • On le bind sur 0.0.0.0 pour écouter sur tous les réseaux.

  • On autorise de remplacer la date reçue par celle du serveur si elle n’est pas lisible dans le message reçu.

  • On stocke le message complet dans « full_message » pour ensuite pouvoir en extraire des données (vu plus tard).

  • On laisse les autres options par défaut, leurs valeurs sont ok.

  • On clique sur « Launch » pour lancer la capture.

Notre Input est lancé :

Juniper SSG140

De même que pour les autres inputs, voici la configuration d'un input pour un pare-feu juniper SSG140 :

ESXi

De même que pour les autres inputs, voici la configuration d'un input pour un ESXi :

Configuration des clients

Maintenant que notre serveur Graylog est prêt à recevoir des messages pour nos équipements grâce à ses inputs et extracteurs, nous allons pouvoir configurer ces hôtes pour envoyer leurs logs à notre serveur.

Hôtes rsyslog (ex.: OS Debian)

« Rsyslog » est très modulable : pour transférer ses logs à notre serveur graylog, une ligne à ajouter dans « /etc/rsyslog.conf » suffit (@@=>TCP / @=>UDP) :

*.* @@IP:PORT

Néanmoins, afin d’augmenter la lisibilité et éviter de configurer des extracteurs sur Graylog, nous allons mettre en place un Template pour envoyer le message selon le format souhaité (RFC5424).

Il faut donc ajouter dans « /etc/rsyslog.conf » (le port choisis pour les messages rsyslog étant le 1520) :

#GRAYLOG TEMPLATE

$template GRAYLOGRFC5424,"<%PRI%>%PROTOCOL-VERSION% %TIMESTAMP:::date-rfc3339% %HOSTNAME% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%\n"

*.* @@10.138.224.55:1520;GRAYLOGRFC5424

Ce qui donne :

On reload le daemon rsyslog (capture sur une version de Debian inférieure à la 8 – Jessie) :

Les logs commencement à arriver :

Remarque :

Afin de retourner toutes les commandes lancées par user/service, etc ; on peut installer le package « snoopy » ; puis redémarrer juste le service à auditer si l’on ne peut pas redémarrer tout le serveur pout tout auditer :

Les logs arrivent :

Pour enlever cette fonctionnalité :

Switches/Coeurs Huawei (info-center config)

Le système de traitement des logs est géré par l’ « info-center », sur les switches HUAWEI. Il permet l’envoi de logs via UDP uniquement, et il n’est pas possible d’en changer de port (514).

Pour un switch d’extrémité :

info-center loghost xxx.xxx.xxx.xxx channel loghost facility local4

Pour un cœur de réseau :

info-center loghost xxx.xxx.xxx.xxx channel loghost facility local7

« Facility » de local0à7, filtre la séverité des logs qui seront donc transmis ou non.

Tous les messages de sévérité supérieure (et donc de valeur inférieure) ou égaux à la « facility » mise en place seront transmis.

Les bonnes pratiques veulent qu’on mette local4 pour un switch de base et local7 pour un cœur.

Règles de sortie par défaut (tous les modules sont actifs par défaut) :

Juniper SSG140

  • En ligne de commandes :

    set syslog config "IP_GRAYLOG"

    set syslog config "IP_GRAYLOG" facilities local0 local0

    set syslog config "IP_GRAYLOG" port 1530

    set syslog config "IP_GRAYLOG" log traffic

    set syslog src-interface ethernet0/0

    set syslog enable

  • Depuis l'interface WEB

ESXi

Activation du syslog loghost :

Autorisation du port sur le pare-feu via activation de la règle prédéfinie :

Nous sommes donc sur une transmission TCP via le port 514.

Remarque :

Nous aurions pu faire passer le traffic Syslog par un autre port, il aurait fallu l’ouvrir sur le pare-feu de l’ESXi aussi. Or, il n’est possible d’éditer les profils de sécurité de l’ESXi uniquement en ligne de commandes (ESXi Shell).

Les Extracteurs

On remarquera alors une fois les switches configurés que les messages arrivent mal interprétés car Huawei ne respecte pas la même RFC que graylog (la source n’est pas bonne, etc.) :

(http://docs.graylog.org/en/latest/pages/extractors.html)

Nous allons donc paramétrer des extracteurs, afin de réécrire les champs correctement dès réception d’un message.

Les extracteurs se placent sur un input, et traitent tous les messages arrivant sur cet input (System>Inputs).

On va donc cliquer sur « manage extractors » dans le champ concernant notre input pour les switches HUAWEI :

On entre alors un message ID récupéré depuis la recherche, et l’index d’où provient le message, puis on charge le message :

Le message est chargé, nous allons cliquer sur le champ « full message » afin de créer notre extracteur à partir de ce champ :

Le choix d’extracteur est alors proposé :

Nous allons commencer par réécrire le champ « source » afin qu’il contienne le bon nom, avec un extracteur « split&index ». On clique ensuite sur Next Step :

La page de création s’ouvre, On va donc faire un split by « » (espace), et renseigner « 5 » dans « Target index », puis cliquer sur « try » afin de voir si cela nous convient :

On peut aussi mettre des conditions à l’application de l’extracteur (exemple : si le champ contient tel ou tel mot, ou telle ou telle REGEX) :

On choisit ensuite de le stocker avec le nom « source » afin d’écraser celui par défaut qui n’est pas bon :

On peut aussi en plus, faire en sorte d’ « enlever » (couper/ cut) l’expression extraite du champ depuis lequel on extrait (exemple : si on extrait « local » du champ « facility » qui contient « local4 », et que nous choisissont « cut » : le champ facility ne retournera plus que « 4 » ). Ici en revanche, cette option n’aura pas d’impact, car elle n’est pas prise en compte pour les extractions depuis les champs « message » ou « full_message » :

On donne un titre à l’extracteur, sous lequel il apparaitra dans « manage extractors » :

On peut aussi ajouter un ou plusieurs convertisseurs, afin de reformater comme nous le souhaitons le champ extrait en sélectionnant le convertisseur souhaité, puis en cliquant sur « add » (nous n’en utilisons pas):

On termine alors avec « create extractor » :

L’extracteur est créé et opérationnel, nous retournons alors dans la vue « manage extractor » de notre « Input » :

Ici on peut voir les détails de chaque extractor aves « Details », les modifier avec « Edit », les supprimer avec « Remove », ou réorganiser l’ordre d’exécution des extracteurs en faisant un « glisser-déposer » avec :

Nous pouvons aussi ajouter des extracteurs depuis la fenêtre de recherche (« Search »). Pour cela on clique sur le message depuis lequel tester l’extracteur afin de l’étendre, puis sur le bouton de déroulement en regard du champ souhaité (« full_message ») :

Ici nous allons donc créer un extracteur de type « Regex », qui sera appliqué sur l’input « Huawei Switches (Info-Center) », et qui extraira depuis le champ « full_message » (dans cet exemple nous allons extraire la date, et la mettre dans un nouveau champ que l’on choisit de nommer « Equipment_timestamp ») :

(Aide pour les REGEX : http://www.ocpsoft.org/opensource/guide-to-regular-expressions-in-java-part-1/ http://lumadis.be/regex/tuto_pcre.php http://forum.hardware.fr/hfr/Programmation/PHP/expression-capturer-occurrence-sujet_28367_1.htm https://www.lucaswillems.com/fr/articles/25/tutoriel-pour-maitriser-les-expressions-regulieres ).

Puis on renseigne le champ voulu et on nomme cet extractor avant de cliquer sur « Create Extractor » :

On retourne sur la page « manage extractors » :

Maintenant, si l’on reçoit un nouveau message de nos switches ; il ressemblera à cela :

On va ensuite créer 4 autres extracteurs REGEX sur cet input (notamment pour réécrire le message, etc.).

De plus, suite à un problème pour certains types de messages avec l’extracteur « Split&Index » du champ source, nous le passons en Regex.

En tout nous avons uniquement ces 6 Regex pour les switches Huawei :

  • regex to extract Equipment_Timestamp from full_message : ^<.{0,23}>(.{20})

  • regex to extract source from full_message : ^<.{0,23}>.{20}\s(.*)\s%?%?\d?\d?.{0,15}\D/\d/

  • regex to extract syslog_version from full_message : ^.*%%(..).*/\d/\D

  • regex to extract module_name from full_message : ^.*\ %?%?\d?\d?\ ?(.+)/\d/\D

  • regex to extract digest from full_message ( (l):log (t):trap (d):debug ) : ^.*\D/\d/(.{1,32})(?<!:.{1,15}):

  • regex to extract message from full_message : ^.*\D/\d/.{1,32}(?<!:.{1,15}):(.*)

Pour arriver à (on les a mis dans un ordre d’exécution suivant l’emplacement de l’extraction dans le champ) :

Ce qui nous donne :

Remarque : nous nous sommes basés sur la documentation Huawei de l’Info-Center afin de connaitre ce que les informations du message signifient :

Graylog supporte les deux RFC Syslog 5424 et 3164 (http://help.papertrailapp.com/kb/configuration/configuring-remote-syslog-from-embedded-or-proprietary-systems/) et parse ces messages automatiquement.

Malheureusement par exemple les ESXi (5.5 et +) ont un Syslog basé sur la RFC 5424 mais ne la suivent pas parfaitement, il faudra donc les adapter.

Import/export :

Il est possible d’exporter nos Extracteurs au format JSON, pour ensuite pouvoir les importer facilement, sans devoir tout recréer. Dans « notre Input > manage extractors », puis « Actions > Export extractors » :

La configuration des extracteurs apparait au format JSON, il suffit de la copier/coller :

On peut les importer : dans « notre Input dans lequel on veut importer les extracteurs > manage extractors », puis « Actions > Import extractors » en collant la configuration dans le champ correspondant :

Ils sont importés (dans le même ordre qu’exportés, la config est bien la même, etc.) :

Interface de recherche

Il s’agit de l’interface principale, la plus complète, et elle se présente ainsi :

Barre de recherche : Syntaxe

Elle permet de chercher selon un critère de temps et une expression.

Elle recherche dans tous les champs ; mais des syntaxes spécifiques existent :

Barre de recherche : Période / Histogramme

Elle permet de sélectionner un intervalle de temps, suivant une syntaxe :

  • “last month” searches between one month ago and now

  • “4 hours ago” searches between four hours ago and now

  • “1st of april to 2 days ago” searches between 1st of April and 2 days ago

  • “yesterday midnight +0200 to today midnight +0200” searches between yesterday midnight and today midnight in timezone +0200 - will be 22:00 in UTC

On peut aussi utiliser l’histogramme :

  • On sélectionne un intervalle de temps avec le curseur :

  • L’intervalle est transmis dans le champ recherche :

Remarque concernant l’histogramme :

Les points noirs représentent les messages ayant déclenchés des alertes :

Résultats de recheche et Champs (Fields)

« save search criteria » nous permet de sauvegarder la recherche pour la relancer plus tard :

« Fields » nous permet d’afficher/masquer des champs pour rendre l’affichage plus ou moins lisible sur la recherche effectuée selon les informations voulues, en cochant/décochant les cases souhaitées :

On peut aussi afficher différentes informations pour un champ sur la recherche effectuée (ici pour tous les messages) : exemple pour « source », et un « Quick Values » :

Astuce : en bas de la zone « fields » on peut cliquer sur « All fields » qui nous permettra d’afficher tous les champs, y compris ceux sytème (« gl_ » ; «timestanmp » ; etc.) :

Gestion des Utilisateurs, Droits, Flux, Alertes

Sous graylog, Il y a tout d’abord deux types d’utilisateurs :

  • Les administrateurs, qui ont tous les droits sur l’interface web ;

  • Les utilisateurs, qui n’ont que des droits (Lecture ou Modification) explicites sur des Streams ou des Dashboards, et ne peuvent pas utiliser la recherche globale.

Les Flux (Streams)

Les streams graylog sont un mécanisme permettant de créer un flux qui va récupérer uniquement les messages correspondant à certaines conditions.

On pourrait donc créer un Stream « HUAWEI NomdeVilleouSite » ne contenant que les messages des switches Huawei d'un site, et donner le droit sur ce Stream à un utilisateur de l'IT local qui ne travaillerait donc qu’avec des messages des Switches de ce site.

Mais aussi créer un Stream récupérant les messages dont le champ « message » contient « erreur » et lancer une alerte (notification ou mail) pour chaque message entrant dans ce Stream.

Exemple : nous avons plusieures sources :

Création d’un Stream qui ne contiendra que les messages relatifs aux HUAWEI (« Streams > Create Stream »):

On le nomme, puis on « Save » :

Il apparaît dans la vue globale des streams, mais est stoppé car non-configuré :

On va donc modifier les règles d’acceptation des messages :

On charge alors un message qui ne servira qu’à tester la règle (on le prend bien sur depuis notre input Huawei) :

Puis on clique sur « Add stream rule » :

Nous allons faire en sorte que ce Stream contienne tous les messages dont le champ (Field) « source » commence par SW-HUA (car nous avons nommé tous les switch HUAWEI selon cette convention), grâce à la Regex (SW-HUA*) :

On s’assure que la règle matche bien, sinon le message comme celui-ci ne serait pas routé :

  • Non-OK :

  • OK :

Puis on peut valider avec « I’m done ! » :

On est retournés à la page de vue d’ensemble des stream (on peut voir les règles appliquées à un Steam avec « Show stream rules »), on peut maintenant démarrer le stream avec « start stream » :

Dans la recherche globale on voit que l’on vient de recevoir deux messages d’un switch Huawei :

On va maintenant aller voir dans notre Stream en se rendant sur la page de vue d’ensemble de ceux-ci puis en cliquant sur notre Stream « HUAWEI STF » :

Nous avons donc une page de type « recherche » qui s’ouvre, elle est limitée à ce Stream. Cela à bien fonctionné on ne voit que les messages reçus par l’équipement HUAWEI :

Les Dashboards

Un Dashboard est une vue d’ensemble personnalisée, classée par widgets :

Elle permet de conserver une rapide vue d’ensemble, et de vérifier que tout fonctionne rapidement, ainsi que de s’organiser (par équipent, statistiques, ...) etc., ainsi que par exemple autoriser un utilisateur à voir certaines informations globales, tout en ayant accès qu’à quelques streams :

Nous allons par exemple commencer à créer un Dashboard Vide (on se rend dans « Dashboards > Create dashboard »), et on le nomme explicitement avec une bonne description. On peut ensuite cliquer sur « Create » :

Il apparait, mais n’affiche rien si on l’ouvre car il est vide :

Nous allons don le remplir. On va commencer avec les information HUAWEI : pour cela on se rends dans notre Stream HUAWEI (« Streams > HUAWEI STF »), puis on lance la recherche pour tous les messages.

On va donc ajouter le compte de tous les messages de cette recherche dans ce Stream au Dashboard (nous aurons donc un compteur qui affichera le nombre de tous les messages dont la source commence par « SW-HUA » depuis la création de ce Stream).

Nous le nommons avec un titre explicite, et cochons « display trend » pour un affichage des tendances, et « lower is better » pour afficher en vert une tendance négative et en rouge une tendance positive, puis cliquons sur « Create » pour valider :

Si nous allons dans notre Dashboard nous voyons le résultat :

Nous retournons sur notre Stream pour ajouter un widget qui nous informe des différents niveaux de messages reçus :

Puis dans notre recherche globale nous allons ajouter un compteur de messages les 5 derniers jours :

Si l’on retourne dans notre Dashboard, on remarque que l’affichage n’est pas très bien agencé :

Afin de repositionner les éléments on va cliquer sur « Unlock/Edit » :

Puis en « Glissant/Déposant » et en redimensionnant grâce à l’angle en bas à droite de chaque « Widget », nous arrivons à :

On peut aussi éditer les propriétés de chaque Widget avec le crayon en bas a droite ou le supprimer avec la corbeille.

Pour repasser en mode normal on clique sur « Lock » :

En mode lock on peut visualiser la configuration du widget avec le "i" en bas a droite de celui-ci, et aussi lancer la recherche correspondante pour voir de quels messages il s’agit par exemple (il faut avoir les droits sur le Stream/recherche globale correspondante) avec le bouton "lecture/play".

Exemple de Dashboard pour tous les flux (Nous avons créé un Stream « All » matchant tous les messages ; puis un Dashboard « All » à partir de ce Stream. Nous avons enfin créé un compte « Helpdesk » avec les droits en RO seulement sur ce Stream et ce Dashboard) :

Création d'un nouvel utilisateur

Comme expliqué plus haut, il y a deux types d’utilisateur :

  • Les administrateurs, qui ont tous les droits sur l’interface web ;

  • Les utilisateurs, qui n’ont que des droits (Lecture ou Modification) explicites sur des Streams ou des Dashboards, et ne peuvent pas utiliser la recherche globale.

Nous connaissons déjà le compte administrateur, nous allons donc nous intéresser à un compte utilisateur.

On va commencer par en créer un dans « System > Users » puis « Add new user » :

On va l’appeler « Service_Huawei » (on peut partir du principe qu’il s’agit d’un compte prestataire quelconque s’occupant uniquement des switches Huawei par exemple) :

  • Username : identifiant de connexion (case sensitive)

  • Full Name : Brève description

  • Password : on met le mot de passe de notre choix (case sensitive)

  • Il n’est pas Admin

  • Timeout : On choisit (ou non en cochant la case "do not timeout") un délai de fermeture de session.

  • Timezone : On met la bonne Timezone pour que les champs "datetime" affichés sur l'interface correspondent au décalage lié à l’emplacement de l’utilisateur.

L’utilisateur est créé :

On va l’éditer avec « Edit » afin de lui affecter ses droits sur les Streams et Dashboards souhaités :

On évite de mettre un Stream en écriture, car même si l’utilisateur ne peut pas ajouter de Stream, il pourra modifier celui en écriture, et donc potentiellement accéder à tous les messages (on pourrait utiliser l’écriture pour un compte de maintenance des Streams par exemple, qui servira aux personnes adaptant les streams lorsque des modifications sont faites sur l’infrastructure).

On peut mettre le Dashboard en écriture afin temporairement de mettre le Dashboard en page d’accueil pour la session, mais on évitera aussi de laisser ce droit (L’utilisateur pourrait supprimer des « Widget » qu’il n’aurait pas les droits de remettre, etc.). Il peut de toute façon créer ses propres Dashboard s’il le souhaite (on pourrait utiliser l’écriture pour un compte de maintenance des Dashboard par exemple, qui servira aux personnes des modifications sont faites sur l’infrastructure)

On valide avec « Update User » :

On se logue avec pour vérifier :

L’utilisateur à bien accès en Lecture uniquement au Stream, et peut faire des recherches dessus :

Il peut aussi le mettre en page d’accueil (ayant temporairement les droits sur le Dashboard en question) qui sera affichée à la connexion ou en cliquant sur :

La page d’accueil une fois les droits en écriture retirés :

L’utilisateur peut bien cliquer sur le bouton "lecteur/play" en bas à droite de chaque widget pour voir les messages concernés par ce widget, uniquement sur les streams dont il est autorisé (au moins en lecture).

  • Exemple après un clic sur ce bouton du widget « HUAWEI STREAM All Messages Count » (autorisé car basé sur le Stream « HUAWEI STF » dont l’utilisateur à les droits en lecture) :

  • Exemple après un clic sur ce bouton du widget « Global Last 5 Days Message Count » (non autorisé car recherche globale) (cela renvoie sur la page de vue globale des streams) :

Alertes Mail

Il est aussi utile d’utiliser des alertes mails, afin par exemple d’avertir le service informatique pour chaque message reçu de niveau 3 ou Inférieur afin d’être immédiatement informé d’un dysfonctionnement, etc.

Les alertes ne peuvent qu’être uniquement configurées sur un Stream. Pour pouvoir envoyer ces alertes mails, il est donc nécessaire de préalablement créer un Stream qui contiendra les messages sur lesquels déclencher les alertes.

Pour se faire nous allons donc créer un Stream contenant les messages de niveau (« level ») inférieur ou égal à 3 :

On le nomme et décris explicitement :

On va ensuite éditer les règles de capture des messages :

(On load si l’on veut un message de test) ;

Puis on va ajouter une règle de flux (« add a stream rule ») : Le contenu du champ « level » doit être inférieur à 4, puis « Save » :

(On pourrait aussi ajouter une règle afin de ne l’appliquer qu’aux switches huawei en filtrant depuis le « gl2_source-input » par exemple, afin de restreindre les messages de ce Stream à ceux provenant de l’input souhaité, etc.)

On clique donc sur « I’m Done » afon de valider nos modifications, puis on peut démarrer le Flux :

En cliquant sur le nom du Stream on l’ouvre, on voit donc avec une recherche que n’ont été capturés que les massages de niveau souhaité :

Il nous faut maintenant éditer le fichier de configuration du Graylog-server (vi /etc/graylog/server/server.conf) :

A la partie « Email transport » (par exemple) :

  • On active la fonctionnalité

  • On indique le protocole : smtp

  • On indique le serveur smtp

  • On indique le port smtp ouvert sur le serveur smtp (25)

  • On renseigne l’username : « [email protected]

  • On renseigne le préfixe souhaité pour le sujet du mail

  • On renseigne l’adresse d’envoi souhaitée

  • On active le lien vers le message dans le mail en saisissant l’adresse du serveur graylog dans « transport_email_web_interface_url »

On redémarre le serveur (attention cela va créer un nouvel indice, suivant comment est configurée votre rétention celà peut tout fausser !) :

On peut maintenant retourner sur notre interface web graylog, onglet «Streams » : Puis on va cliquer sur « Manage Alerts » :

On ajoute une condition d’alerte ; voici deux exemples qui fonctionneraient (car tous les messages dans ce Stream ont un « level » inférieur ou égal à 3), et on valide avec « Add alert condition » :

Notre condition apparait ici :

On peut aussi mettre en place un « CallBack » afin d’envoyer un mail avec une meilleure mise en forme, ou un post http (FACULTATIF) :

On ajoute nos destinataires (Un user graylog avec une adresse mail correcte dans son profil graylog, ou une adresse mail directement). Puis on envoie un mail de test afin de vérifier le bon fonctionnement :

Mail reçu :

Voilà, nos alertes sont configurées et fonctionnelles pour notre Stream :

Conclusion

Graylog est donc un outil puissant et modulable, qui permet de s’adapter à beaucoup d’équipements, et différentes infrastructures.

Il met en place une gestion des flux et des droits qui lui est propre, mais très puissante une fois prise en main.

Son interface est claire, et rapide à utiliser ; elle permet aussi de mettre en avant les informations jugées importantes (Dashboards, etc.).

Pour toute documentation : http://docs.graylog.org/

Notes de MAJ (Exemple)

MAJ du xx/xx/20xx

Mise à jour Elasticsearch : La version 2.x est sortie mais n’est pas compatible avec Graylog 1.x pour le moment !!

Mise à jour de MongoDB => pas de MAJ (depuis les dépôts Debian).

Mise à jour Graylog : La version 1.3.x est sortie

  • Les changelogs depuis la dernière version de production installée ainsi que les prérequis sont compatibles, la mise à jour se fera sans problème.

  • Mise à jour des sources grâce au paquet Debian fournit par graylog.org

  • Mise à jour de graylog 1.2.1 -> 1.3.2

Mise à jour des sources (apt-get update) => OK.

Mise à Jour Système (upgrade puis dist-upgrade) :

  • Liste des paquets mis à jour :

Modification des fichiers de configuration :

  • Graylog server (deux options ajoutées pour deux nouvelles fonctionnalités apparues depuis notre précédente version). Nous garderons donc notre ancienne version du fichier de configuration, et recopierons manuellement ces nouvelles lignes :

    On va modifier notre ancien fichier de configuration en ajoutant ces deux paragraphes (les valeurs par défaut nous vont bien) :

Puis, on redémarre si possible le serveur, pour redémarrer sur le nouveau noyau linux, et tester la nouvelle version de GRUB, ce qui nous permet d’être sûr que tout fonctionne correctement. Sinon nous redémarrons uniquement les services mis à jour, et planifions un redémarrage du serveur à un autre moment.

Erreurs rencontrées :

  • Le serveur n’a pas redémarré. La console de la VM affichait un écran noir. Coupure de l’alimentation de la VM et remise sous tension => Démarrage OK.

  • Toujours le même problème de permissions pour Java qui ne peut bind les ports protégés (en dessous de 1024), ce qui nécessite la commande :

    setcap 'cap_net_bind_service=+ep' /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java

    Puis un redémarrage des composants Graylog server puis web.

    AJOUT DE CETTE COMMANDE au fichier /etc/rc.local en rendant ce dernier exécutable pour que ce problème disparaisse.

Tests :

  • Connexion à l’interface Web => OK.

  • Arrivée des messages => OK.

  • Indices => OK.

  • Nodes Status => OK.

  • Logs de Graylog (server et Web), Elasticsearch, MongoDB => OK.

  • Tests avec l’équipe Admin => concluants.

Suppression du snapshot.

Succès de la Mise à jour.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels