Bonsoir à tous!

J’ai récemment eu a migrer ma plateforme GLPI sur un nouvel environnement, et par extension le serveur que j’utilisais pour Kibana, ES etc…

Voir les articles précédents sur l’utilisation de Kibana et Elasticsearch avec GLPI :
http://desaille.fr/kibana-glpi-dashboard-v2/
http://desaille.fr/elk-glpi-raspberrypi-tv/

Une fois la nouvelle plateforme GLPI en prod, je me suis attaqué au re-paramétrage du bouzin. J’ai relu les notes que j’avais prises et j’ai quand même trouvé ça un peu chiant à mettre en place.

Les articles sur Kibana et GLPI sont les plus consultés du site, toute proportions gardées, y’a pas non plus grand monde qui passe par ici, mais ça représente quand même 20% des pages sur les 6 derniers mois, je me suis donc dit qu’il pourrait être pas mal d’automatiser et surtout de simplifier un un peu tout ça.
Lire la suite de

Petite astuce, toujours dans l’écosystème Elasticsearch avec lequel je joue pas mal en ce moment…

J’ai pas mal galéré à créer un mapping personnalisé pour importer des données via un river JDBC (GLPI Dashboard), mes champs strings passaient automatiquement en « analyzed » et pour jouer avec dans Kibana, c’est pas la joie…

Je me suis rendu compte que quand on utilise logstash, par défaut il detecte automatiquement les champs, et pour ceux qui sont « analysés », il ajoute un « champ.raw » qui contient la donnée brute. J’ai donc cherché un peu de ce côté là et j’ai vu qu’il était possible de créer des templates de mappings en fonction des index!

Lire la suite de

Petit retour sur le précédent article GLPI-Dashboard :

EDIT : Nouvel  article, automatiser le paramétrage et la communication entre ES et GLPI : Kibana pour GLPI en 15 minutes!

Après avoir pas mal joué avec Kibana et les données en provenance de glpi je me suis rendu compte qu’il y avait pas mal de truc qui manquaient pour avoir des infos fiables et utilisables.

On va donc voir ici comment améliorer tout ça, et avoir encore plus de matière pour jouer!

1/ Les Demandeurs et Techniciens :

Dans la vue MySQL je remonte les champs users_id_recipient et users_id_lastupdater, concrètement ça récupère le nom de la personne qui ouvre le ticket et le nom de la dernière personne qui l’a modifié, les champs « Par » et « Dernière modification ».

glpilastupdater

Au début il m’a semblé pouvoir fonctionner comme ça, par souci de simplicité (voir de flemme 🙂 ), étant donné qu’une bonne partie de mes utilisateurs ouvrent leurs tickets  par mail, via un collecteur IMAP, ils sont donc identifiés comme « recipient », même combat pour les techniciens, ils sont généralement les derniers à modifier le ticket et donc considérés comme « lastupdater ».

J’ai vite déchanté!

Lire la suite de

EDIT : Nouvel  article, automatiser le paramétrage et la communication entre ES et GLPI : Kibana pour GLPI en 15 minutes!

Alors,

Dans la continuité des tests que je suis en train de mener autour de la stack ELK, j’ai pu tester la centralisation des logs (logstash/nxlog) la création de dashboards avec Kibana3, puis maintenant avec Kibana4 pour visualiser tout ça. C’est que du bonheur, je me suis bien amusé à jouer avec ça.

Il est temps de passer à la vitesse supérieure, l’idée maintenant et de pouvoir ajouter des données depuis des bases de données extérieures mySQL et SQL.

On va chercher à récupérer les infos de l’outil de ticketting (GLPI) utilisé quotidiennement dans ma boite, pour les injecter dans Elasticsearch à intervalles régulier et générer un ou des Dashboard Kibana4 dans ce genre là… Et surement bien mieux une fois l’outil maîtrisé! ci dessous, quelques essais fraîchement générés.

Kibana4_glpi

Lire la suite de