Sébastien Warin

Désormais la maison est équipée d’une multitude de systèmes informatiques et d’objets connectés. Des serveurs, aux média-centers (XBMC/Kodi) et ordinateurs en tout genre, en passant par le thermostat connecté, la TV & ampli connectées, les capteurs météo connectés, système d’alarme connecté, lampes connectées, etc… La maison intelligente dispose d’un nombre impressionnant de capteur produisant beaucoup de données.

Par exemple un module intérieur NetAtmo produit des données sur la température mesurée, l’humidité, le taux de CO² mais aussi l’état de sa batterie, la puissance du signal, etc.. Sur un ampli Home-Cinéma on aura son état (allumé ou éteint), le niveau du volume, l’entrée sélectionnée, etc… Un micro-module Fibaro Z-Wave indiquera quant à lui l’état de ses relais et une zone du système d’alarme indiquera si elle est ouverte ou fermée, en alarme, en maintenance, etc…

Comme vous le savez en lisant ce blog, ma plateforme Constellation permet l’interconnexion des différents objets et services connectés. Que ce soit des ordinateurs ou serveurs, des services externes, des objets connectés du commerce ou que vous avez vous-même développé (à base d’Arduino, ESP8266, Gadgeteer, Raspberry, & co), vous pouvez les connecter sur la plateforme Constellation afin de pouvoir les faire dialoguer ensemble et créer ainsi de l’intelligence ambiante et des interfaces de pilotage universelle.

Dans cet article nous allons découvrir comment historiser l’ensemble des données qui circule dans la Constellation à des fins d’analyse et d’alerting.

Pour cela nous allons connecter Graylog à Constellation et utiliser ElasticSearch comme base de données et Kibana comme interface Web de visualisation.

Notion de base : les StateObjects Constellation

Dans la Constellation, chaque système connecté (un programme, un objet, un service, une page Web, un script) peut à la fois envoyer et recevoir des messages pour communiquer avec les autres systèmes connectés dans la Constellation dans une langue commune. Chaque système peut également publier des StateObjects.

Un StateObject, ou objet d’état, représente une variable ou une donnée produite par le système. Par exemple mon système d’alarme publie dans la Constellation un StateObject qui définit l’état de l’alarme et autant de StateObject que de zone. Le package NetAtmo produit un StateObject par module contenant les informations mesurées par le module (T°, humidité, CO², etc..).

Un objet DIY comme S-Energy produit des StateObject pour la consommation d’eau, un autre pour l’électricité, et enfin un dernier pour le gaz.

Une fois publié dans la Constellation, tout le monde peut interroger et s’abonner aux mises à jour des StateObjects ! Ainsi la porte de garage peut savoir en temps réel si l’alarme est activée, le système audio peut connaitre la consommation d’eau en temps réel de votre douche, un Arduino peut connaitre le taux de CO² ou une simple page Web peut être la base d’un dashboard des objets connectés de sa maison comme je vous l’ai déjà démontré avec l’alarme connectée,  S-Energy, S-Panel, S-Garage ou en encore S-Sound.

 

De la même façon, il est possible de créer un programme (= package en Constellation) qui s’abonne à la modification de tous les StateObjects de votre Constellation pour les enregistrer : “tel jour, telle heure, le StateObject XYZ de tel système était à tel valeur”.

Première expérience avec Windows Azure et Excel

Les StateObjects représentent l’état à un instant T des différents systèmes connectés sur votre Constellation. Chaque StateObject est mis à jour dès que le système à une nouvelle valeur ! Par exemple le package NetAtmo met à jour les S.O. des modules toutes les 10 minutes, un capteur de température Z-Wave mettra à jour son S.O. en fonction de sa configuration (par exemple, dès qu’il y a un changement de température de 0,1°C), une zone du système d’alarme sera mis à jour dès que son état change (ouvert ou fermé).

Il est facile de créer des interfaces en temps réel reflétant l’état actuel des S.O. mais pour analyser l’évolution des S.O. dans le temps il faut les enregistrer à chaque modification.

Mes premières expériences remontent à plus d’un an avec mon système d’alarme (voir l’article ici) puis avec mon système de comptage énergétique S-Energy (voir ici).

Dans les deux cas, j’ai écrit un package Constellation (en C#) qui s’abonnait aux mises à jour des S.O. de l’alarme et de S-Energy pour enregistrer chaque nouvelle valeur dans Windows Azure (en utilisant les Azure Tables).

Ensuite j’utilisais Excel et son module PowerQuery pour récupérer toutes les données de ma table Azure, les traiter et créer différents graphiques.

Par exemple sur la fréquentation des pièces de la maison en fonction des jours ou des heures, via l’analyse des StateObjects du système d’alarme (relire l’article ici) :

Ou bien sur ma consommation d’électricité, d’eau et de gaz via les StateObjects de S-Energy (relire l’article ici).

L’utilisation couplée du Cloud Windows Azure pour stoker l’ensemble des données produites par les objets et services de la maison et Excel comme interface de reporting était une solution facile à mettre en place mais après certain nombre de données, il commençait à être fastidieux de charger toutes ces données et pouvoir les exploiter convenablement.

Aussi, comme beaucoup de système de stat, il était difficile de changer la période d’analyse intuitivement. De plus, il fallait avoir un Excel à disposition avec le plugin PowerQuery.

Il me fallait alors trouver une interface Web accessible depuis n’importe où, permettant de créer des graphiques très facilement et concevoir des Dashboards personnalisés en quelques clics ! Et c’est là qu’intervient Kibana !

Graylog, ElasticSearch et Kibana : kézako

Il y a beaucoup de nom de produit, résumons :

• ElasticSearch : est un moteur de recherche et d’analyse distribué et open source basé sur Lucene
• Kibana : est une plateforme open source de visualisation des données pour ElasticSearch
• GrayLog : est une plateforme open source de managements des logs

Il faut voir les modifications de StateObjects comme un évènement qu’on va enregistrer comme un log. Les propriétés du StateObjects seront enregistrées comme métadatas du message dans ElasticSearch.

Graylog utilise ElasticSearch pour stocker et indexer les logs. La plateforme propose une interface de visualisation mais à mon gout bien moins puissante que Kibana.

Comme Graylog utilise ElasticSearch, il suffit d’installer Kibana pour profiter une plateforme Web très puissante de visualisation nous permettant de créer des graphiques pour tous vos systèmes connectés à Constellation : serveurs et informatique de manière générale, l’IoT, la domotique, etc…

Il est possible de se passer de Graylog et de le remplacer par Logstash mais Graylog a deux avantages : toute la configuration est réalisée depuis une interface Web, bien plus pratique, et Graylog a un système d’alerting intégré (l’équivalent de Watcher).

Grace à cela, on peut créer des règles d’alerting sur les S.O. de notre Constellation : par exemple si CPU de mon serveur chauffe trop, ou si je dépense trop d’eau, si  ma porte de garage est ouverte depuis plus de 30 minutes, si ma station NetAtmo ou mon système S-Energy ne sont plus connectés à ma Constellation, etc…

Envoyer vos StateObjects Constellation dans Graylog

Le fonctionnement de Graylog est assez simple. On définit des “Inputs” chargés de collecter les logs venant des applications (dans notre cas de la Constellation). Une fois les logs reçus sur ces “Inputs”, ils seront traités puis indexés et stockés dans ElasticSearch. MongoDB est utilisé pour le stockage de la configuration de GrayLog (input, stream, dashboard, etc…)

L’API REST de Graylog Server permet son exploitation depuis la “Web Interface” que nous utiliserons pour le pilotage et la configuration de Graylog !

Graylog définit également une notion de “Stream” permettant de classer les logs selon des conditions. Chaque Stream peut à son tour définir des “Outputs” pour envoyer les logs à d’autre endroits sous d’autre format.

Chaque Stream peut également définir des alertes. Par exemple si certain log respecte telle ou telle condition, envoyer un mail d’alerte. (Si la température du CPU dépasse un seuil, etc…).

On peut également ajouter des “Extractors” sur les messages en entrées pour extraire des informations comme nous le verrons plus tard.

Enfin la Web Interface permet également de découvrir/naviguer dans les enregistrement de la base ElasticSearch ou encore de créer des dashboards/graphiques. Pour cette partie, Kibana est bien meilleur comme nous le verrons également dans la suite de cet article

Créez un Input GELF dans Graylog

Pour l’heure créons une “Input” capable de recevoir les S.O. de la Constellation. Nous allons créer un “listener” GELF utilisant le protocole UDP en lui spécifiant un nom et un port d’écoute :

L’input est désormais démarré et il attend les traces au format GELF :

Créez un package Constellation pour envoyer les StateObjects en GELF par UDP

GELF pour “Graylog Extended Log Format” est format de log inventé pour pallier aux limitations du syslog. Chaque message est composé d’attribut et valeur et peut être compressé et envoyé par paquet sans limitation de taille.

La spécification 1.1 rend obligatoire la présence des champs “version”, “host” (nom de la machine qui émet le log), “short_message” (le texte du message) et “timestamp” (l’heure à laquelle se produit l’évènement décrit par le message). Vous pouvez optionnellement ajouter le niveau de criticité (level).

Mais le plus important est que le GELF est extensible comme l’indique le “E” dans GELF. Vous pouvez donc ajouter autant de champs que vous voulez ! Ces champs additionnels doivent simplement être préfixés d’un underscore.

De ce fait, à chaque fois qu’un StateObject dans Constellation est mis à jour nous pouvons créer un message GELF qui contiendra toutes les propriétés et valeurs du StateObjects dans des champs additionnels du message GELF.

Par exemple, quand la Vera Lite reçoit une mise à jour de l’état d’une prise AN158 (ici utilisée pour ma baie réseau), le package Vera met à jour le StateObject Constellation lié à cette prise. Cette mise à jour est “captée” par le package “Graylog” qui crée un message GELF et l’envoi dans Graylog par UDP.

Ainsi à chaque mise à jour d’état de ma prise AN158, je reçois sur Graylog le message suivant :

On retrouve les propriétés obligatoires du message GELF comme le message, la source, le Timestamp mais surtout toutes les propriétés additionnelles qui dans le cas d’un StateObject d’une prise AN158 sont : l’ID du device Z-wave, son état (allumé 1 ou éteins 0), sa consommation en Watts,etc…

Et comme tout est indexé par ElasticSearch, il sera par la suite très simple d’exploiter ces informations.

Le principe est donc le suivant : créer un package Constellation et s’abonner à tous les StateObjects que l’on souhaite historiser (Vera, NetAtmo, Nest, Google Traffic, infos sur les serveurs, les sites Web, la météo, etc.. etc…). A travers mes différents articles sur Constellation et notamment celui sur S-Panel vous avez une bonne idée du nombre d’information que je dispose dans la Constellation sous forme de StateObject.

Dès que les StateObjects sont mis à jours, le package Graylog convertie le StateObjects en un message GELF et l’envoie au serveur Graylog qui lui-même enregistre l’information dans la base ElasticSearch. Pour la consultation, nous utiliserons Kibana comme nous le verrons dans la suite de cet article.

Pour résumer dans le Package Constellation, ici écrit en C#, je viens m’abonner aux StateObjects produits par les packages qui m’intéressent comme la Vera, NetAtmo, S-Energy, etc.. etc…

Par exemple avec l’API C# on pourrait écrire :

Dans le handler levé à chaque mise à jour d’un StateObject je vais simplement construire un dictionnaire contenant toutes les informations de mon message GELF sur base du StateObject que je reçois ! La méthode “ExpandProperties” est une méthode récursive qui parcourt chaque propriété du StateObject pour l’ajouter dans le dictionnaire.

Ce qui nous donne :

Une fois le dictionnaire contenant toutes les informations de mon StateObject construit, je le convertie en JSON pour généré mon message final GELF que j’envoie ensuite en UDP à mon serveur Graylog :

Le principe de fonctionnement est donc extrêmement simple et ne nécessite que quelques lignes de C# grâce à Constellation pour envoyer en temps réel les informations de tous mes objets connectés de la maison dans Graylog/ElasticSearch.

Utilisez le package prêt à l’emploi “Graylog Connector”

Maintenant que vous avez compris la théorie, sachez qu’il existe un package Constellation prêt à l’emploi :

La version finale du package est un poil plus compliquée car tout est entièrement paramétrable dans la configuration du package.

Il est possible d’ajouter des exclusions (par exemple “je veux tous les devices Zwave de la Vera à l’exception d’un tel”) ou encore de créer des agrégations.

Par exemple, le package Constellation “HWMonitor” publie dans la Constellation les différents compteurs hardware d’une machine comme le CPU, la RAM, les températures du CPU, M/B, disque, etc

Ces StateObjects sont mis à jour par le packages toutes les 500ms ! Il y aurait donc deux mesures par seconde pour chaque compteur de chaque instance du package….

Beaucoup trop d’information à stocker/exploiter sans réellement d’intérêt ! L’agrégation permet de faire une moyenne sur une plage de temps définie (par exemple toutes les 30 secondes) afin de stocker un échantillon !

Au final, avec ce package, il suffit de l’activer dans ma Constellation :

Puis de configurer les SO que l’on souhaite enregistrer. Chez moi, la configuration est la suivante :

J’enregistre donc les StatesObjects :

• du package HWMonitor (consommation du CPU, RAM, la place utilisée par les disques durs, T° du CPU et mainboard, conso réseau) pour chaque machines sur lequel est déployé ce package (c’est à dire tous mes serveurs, laptops, The Mirror, les NUC de la maison) avec un échantillonnage de 30 secondes (agrégation par défaut)
• de S-Energy (consommation électrique, eau et gaz)
• de la station météo NetAtmo (T°, humidité, CO², niveau sonore, pression, pluviomètre pour plusieurs pièces et à l’extérieure)
• du thermostat Nest
• de l’ampli Pioneer
• de tous les devices Z-Wave de la Vera à l’exception du HEM
• des onduleurs (niveau de charge et temps estimé)
• des temps de réponse sur mes sites Web externes (script Powershell)
• des capteurs de luminosité avec un échantillonnage de 60 secondes pour la propriété “Light”
• des instances de  S-Sound
• de la balance Fitbit (analyse du poids de la masse graisseuse dans Kibana )
• de la météo Forecast
• des infos sur le trafic routier avec GMap
• de l’alarme Paradox

Une fois configuré, le package peut démarrer :

Et sur l’interface Web de Gray on peut constater les StateObjects arriver en temps réel :

Analysez vos données dans Graylog : recherche et extraction

Je ne vais pas trop m’attarder sur l’interface Graylog car je préfère à l’usage celle de Kibana. Graylog me permet surtout de gérer les alertes comme nous allons le voir plus bas.

Vous pouvez cependant rechercher vos StateObjects. Par exemple dans la capture ci-dessous je recherche les StateObjects dont le nom est “Baie Réseau” représentant ma prise Z-Wave AN158 qui mesure la consommation de ma baie.

Même avec 10 millions d’enregistrement dans ma base d’ElasticSearch, le résultat de ma requête est quasi-instantané. Dans le menu de gauche, j’ai sélectionné la propriété “Vera.Watts” me permettant de visualiser cette donnée dans la table des messages sans devoir ouvrir le détail de chaque message :

Vous pouvez également cliquer sur un message pour voir tout le détail :

La page “Source” vous indiquera le nombre de message reçu en moyenne et la répartition par “source”. On retrouve mes différents systèmes connectés à Constellation que ce soit des serveurs Windows ou Linux, des ESP8266, des Raspberry ou mes PC perso :

Ajouter des extracteurs

Une fonctionnalité intéressante sur Graylog : les “extracteurs” qui permettent d’extraire une information d’un message !

En principe la valeur d’un StateObject est un type simple (string, int, decimal) ou un objet complexe JSON. Comme montré ci-dessus, l’objet JSON est éclaté de manière récursive pour que ses propriétés deviennent des propriétés du message GELF !

Cela marche à une exception près : si la valeur du StateObject est un tableau d’objet ! Et c’est justement le cas du package “GoogleTraffic” qui pour un itinéraire donné publie dans un SO un tableau des routes possibles.

Ainsi si j’utilise le moteur de recherche de Graylog pour récupérer ces StateObject je trouve cela :

Comme vous le constatez le StateObject est bien enregistré avec ses différentes propriétés et métadatas mais comme la valeur est un tableau elle est inclue dans le message en JSON ! Résultat : impossible de l’exploiter dans des graphiques !

Deux solutions :

1. Changer le fonctionnement du package GoogleTraffic
2. Extraire les informations qui m’intéressent de ce StateObject depuis Graylog

Ce qui m’intéresse au final c’est : le nom de la meilleur route et le temps de trajet avec la trafic (propriété InfoTraffic).

Il existe plusieurs techniques d’extraction :

1. Substring
2. Regex
3. Split & Index
4. Copy
5. Grok

Comme la valeur est une chaine de caractère, je vais utiliser une regex pour extraire le temps de trajet : \[\{« Name »:[^\{]*, »InfoTraffic »: »(.*?) min »,.*

L’extracteur est donc configuré sur le champ “GoogleTraffic.value”, extrait le temps de trajet avec la regex ci-dessus, convertie la valeur en numérique et l’ajoute au message dans un nouveau champ “GoogleTraffic.BestTrafficRouteInMin”

J’en ai également créé un autre pour le nom de la route que je retrouve dans ma liste d’extracteurs (avec les stats) :

Maintenant si je visualise les nouveaux messages des StateObjects de GoogleTraffic, vous observerez que deux nouveaux champs sont ajoutés par les extracteurs que nous avons configurés :

Comme le champ “GoogleTraffic.BestTrafficRouteInMin” est une valeur numérique, nous pourrons l’utiliser pour créer des graphiques sur l’évolution du temps de trajet.

Ainsi même si la structure du message n’est pas exactement ce que vous aurez souhaité, vous pouvez utiliser les extracteurs pour extraire et/ou convertir des champs à vos messages.

Créez des alertes

Au-delà des extracteurs, Graylog offre une autre fonctionnalité très utile : les alertes ! Pour cela il faut d’abord créer des Streams :

Un Stream est un flux de message qui respecte des conditions, une sorte de “catégorie” pour vos messages entrants. Un message peut être “rangé” dans un ou plusieurs Streams. Ensuite les messages d’un Stream peuvent être envoyés autre part (Output) ou passer dans un moteur d’alerte.

Prenons un exemple très simple : je veux être notifié par mail si le CPU de mon serveur de virtualisation (nommé CEREBRUM) dépasse les 25% en moyenne sur les 5 dernières minutes.

Cette information est poussée par le package “HWMonitor” et le nom du StateObject de la consommation totale du CPU est “/intelcpu/0/load/0”.

Ainsi je crée un Stream “CPU CEREBRUM” avec trois conditions :

1. La Sentinel (source) doit être mon serveur CEREBRUM
2. Le package doit être HWMonitor
3. Le nom du SO doit être “/intelcpu/0/load/0”

Ensuite, en cliquant sur le bouton “Manage alerts” je peux éditer des règles :

Trois types de règle :

1. Message count condition : règle en fonction d’un nombre d’occurrence de message
2. Field value condition : règle en fonction de la valeur d’un champ
3. Field content condition : règle basé sur le contenu (string) d’un message

Dans notre cas, on va créer un “Field value condition” :

Il suffit de remplir le formulaire : si la propriété “HWMonitor.value” (comme le Stream filtre les SO “/intelcpu/0/load/0” du package HWMonitor du serveur CEREBRUM, on a donc la valeur numérique de la conso du CPU) est en moyenne (mean value) plus grand que 20% dans les dernières 5 minutes avec une période de grâce de 30 minutes, alors on lève la règle !

Dans l’interface vous pouvez ensuite soit définir des Callbacks (URL à appeler en cas d’alerte) ou des Receivers (pour l’envoi de mail en cas d’alerte).

Il est ainsi très facile de faire des règles sur l’ensemble de vos données produites par votre informatique ou IoT.

Un autre exemple : S-Energy mon système de consommation des ressources énergétique.  On peut bien sûr définir des règles en cas de surconsommation ou fuite d’eau par exemple !

Dans mon cas, j’ai eu un problème de transmission entre mon module Arduino et le Raspberry (revoir l’article ici). En effet, dans certain cas les paquets envoyés via le nRF24L01+ n’était pas reçu et donc aucun historique pendant quelques jours.

Pour être notifié en cas de problème, on peut très rapidement créer une règle qui pote sur l’absence de mises à jour de StateObject :

Premièrement, je crée un Stream pour récupérer les StateObjects nommés “Electricity” du package SEnergy :

Avec le déclencheur suivant : “Si moins d’un message reçu dans les 15 dernières minutes, alors on lève l’alerte !”

Créez votre “Home Analytics” avec Kibana

Pour résumer Graylog vous permet de créer facilement des entrées GELF, de configurer des extracteurs, de classer vos messages dans des Streams et d’ajouter des règles d’alerte.

Il permet aussi de créer des Dashboards mais le résultat est très moyen ! A la place je vous conseille d’installer Kibana, une plateforme de visualisation dynamique et très complète (vous trouverez la procédure d’installation à la fin de cet article).

Lors de la première connexion, vous devrez définir le nom de l’index dans ElasticSearch (dans notre cas: “graylog_0”) afin de “découvrir” les champs disponibles :

Kibana est découpé en 4 pages :

1. Discover : le moteur de recherche qui comme Graylog permet de découvrir et visualiser le détail de vos les messages dans votre ElasticSearch
2. Visualize : permet des créer des widgets de visualisation : des graphiques en barres, en courbes, en secteurs, en aires, des tableaux de données, des indicateurs clés et même des cartes.
3. Dashbaord : permet de concevoir des pages dynamiques avec les widgets de visualisation que vous aurez créés
4. Settings : configuration de l’index et des champs

Sur chaque page vous trouverez en haut à droite la période d’analyse. En cliquant dessus vous pourrez la changer en utilisant soit des périodes prédéfinies (aujourd’hui, hier, cette semaine, ce mois, etc…) soit en spécifiant une période relative (comme les X dernières secondes, minutes, heures, jours, semaines, mois, années) ou enfin de manière absolue en spécifiant la date et heure de début et de fin.

Découvrez vos données

Par exemple, recherchons la température de notre chambre. Celle-ci est mesurée avec un module NetAtmo.

Ma requête filtre tous les messages dont le nom du SO est “Chambre2.Temperature” en sélectionnant une période de 24h :

On a environ 3 messages par période de 30 minutes (car les valeurs des capteurs NetAtmo sont remontés toutes les 10 minutes).

Je peux également cliquer sur un message pour voir toutes les propriétés associés au message :

Sur le menu de gauche, je peux, comme sur Graylog, ajouter des champs à mon tableau de résultat. Sélectionnons le champ “NetAtmo.value” :

Si vous analysez le contenu des messages vous remarquerez que le type du StateObject (le champ stateobject.type) est “NetAtmo.TemperatureMeasurement”.

On va donc changer notre requête pour récupérer tous les messages de ce type et on va afficher dans notre tableau le nom du SO (stateobject.name) et la valeur du capteur (NetAtmo.value), dans notre cas, la valeur de la température.

On obtient ainsi un listing sur les 24 dernières heures des T° de chacun de nos modules NetAtmo (Chambre 1 et 2, salon et Jardin) :

Pour plus de détail sur la syntaxe des requêtes Lucene : https://lucene.apache.org/core/2_9_4/queryparsersyntax.html

Créez des widgets de visualisation

La page Discover est très pratique pour découvrir et rechercher les données stockées dans votre index.

Maintenant vous pouvez créer des widgets de visualisation : des tableaux, des graphiques en tout genre, des indicateurs clés, etc..

Commençons par afficher le nombre de litre d’eau consommée capté par mon système S-Energy (pour rappel un Raspberry qui prend une photo du capteur d’eau + OCR avec OpenCV depuis un package Constellation écrit en Python).

Commençons par créer une nouvelle visualisation de type “Metric” :

Le StateObjects publié par le package Python S-Energy est nommé “Water.Flow”. N’oubliez pas le mode Discover pour analyser les messages! Le Water.Flow contient les propriétés suivantes :

Dans mon cas ce qu’il m’intéresse c’est le “LiterDelta” qui indique le nombre de litre d’eau consommé entre deux captures. Il suffit donc de faire la somme de cette propriété pour connaitre le nombre de litre consommée pour une période donnée.

Revenons donc sur l’interface de création du widget “Metric”.

Il suffit d’écrire votre requête : ici je filtre les StateObjects nommés “Water.Flow” et de sélectionner sur le menu de gauche que je souhaite une somme (Sum) du champ “SEnergy.LiterDelta”, et voilà notre Widget créé.

Sur les 15 dernières minutes j’ai consommé 83 litres. Si je change la période pour la journée d’hier j’ai 347 litres !

Ce type de Widget est parfait pour vous donner des chiffres clés.

Maintenant analysons cette consommation d’eau dans le temps en créant un widget de type “Vertical bar chart”.

J’utilise la même requêtes (SO nommé Water.Flow) et l’axe des ordonnées (Y) toujours la somme des “LiterDelta”. Enfin sur l’axe des abscisses (X) la date en mode Auto (c’est à dire basée sur la période définie en haut à droite).

Par exemple sur les dernières 24 heures :

On peut également utiliser des Widgets de type “Line chart”. Par exemple les courbes de température pour mes capteurs NetAtmo mais également des capteurs Z-Wave (des ST814).

Comme nous l’avons vu les capteurs NetAtmo publie des SO de type “NetAtmo.TemperatureMeasurement” pour la T° et pour le package Vera, le type est “VeraNet.TemperatureSensor”.

De ce fait la requête sera

Sur l’axe des ordonnées j’ajoute deux métriques : la moyenne du champ “NetAtmo.value” et la moyenne du champs “Vera.Temperature”.

Sur l’axe des abscisses, toujours le temps et je précise également que je veux splitter les séries par le nom du StateObjects afin d’avoir une courbe par capteur.

On retrouve alors sur graphique l’ensemble des mes capteurs de T°, NetAtmo et Z-Wave en quelques clics que je vous propose de voir en vidéo:

Ce qui est super avec Kibana c’est le fait de pouvoir affiner la période d’analyse en la sélectionnant sur le graphique (et observez le temps de rafraichissement quasi instantané pour l’agréation et la visualisation du nouveau jeu de données après le changement d’une période)

Ainsi libre à vous de créer tout type de widget de visualisation en fonction de vos données.

Créez vos dashboards

Une fois vos widgets de visualisation créés, vous allez pouvoir les ajouter sur un dashboard. Plutôt qu’un long discours voici une démonstration dans laquelle je vais créer un dashboard “S-Energy” afin de retrouver ma consommation d’eau, gaz et d’électricité :

En résumé, un dashboard vous permet de disposer sur une page différents widgets de visualisation que vous avez créé. Vous pouvez créer autant de dashboards que vous souhaitez et encore une fois le fait de sélectionner une période sur un widget modifie la période d’analyse en haut à droite et donc tous les autres widgets s’actualiseront !

Conclusion

J’utilise le trio Graylog/ElasticSearch/Kibana depuis Juin 2015 après avoir écrit le connecteur pour Constellation.

En 4 mois déjà plus de 10 millions de StateObjects produits par les différents packages de ma Constellation sont consignés dans l’index ElasticSearch.

J’ai créé plus d’une trentaine de widgets de visualisation et quelques dashboards :

• Le dashboard principal avec un peu de tout dont l’activité des zones via les SO de l’alarme, les temps de réponse de mes sites Web, les temps de trajets, etc.. etc..

• Le dashboard “météo” (NetAtmo, capteurs Z-Wave, capteurs home-made à base d’ESP8266 et Raspberry Pi)

• Le dashboard S-Energy (consommation eau, gaz et électricité)

• Le dashbaord “Informatique” (consommation CPU, RAM, T° des CPU, occupation des HDD, état onduleur, etc …).

La plateforme Constellation permet d’agréer tous mes objets connectés (serveurs, prises, lampes, etc..) autour d’un bus accessible au développeur grâce aux différentes API : .NET, Arduino, Powershell, Lua, Python, Javascript, etc..

C’est grâce à cela que j’ai pu, en activant un simple connecteur, capter toutes ces données (les StateObjects) pour les envoyer dans un système de stockage. Au début avec Windows Azure & Excel, puis ensuite sur ElasticSearch & Kibana via Graylog.

Vous pouvoir aussi écrire votre propre package Constellation pour stoker et analyser les données de vos objets et services connectés dans un autres système sans rien changer à l’existant.

Personnellement, le trio présenté ici couplé à Constellation répond parfaitement à mon besoin : historiser l’ensemble des données produites dans la maison et de les restituer au travers une interface Web extrêmement simple, riche et puissante.

Annexe : installer un serveur Debian avec Graylog, ElasticSearch & Kibana

Tout d’abord il vous faut une machine Linux si possible en 64 Bits. Pour ma part j’ai créé une machine virtuelle Linux sur mon serveur Hyper-V.

Quatre cœurs avec 2GB de mémoire RAM. Prévoyez au moins 20 GB de place disque (10GB après l’installation et en fonction du volume du données que vous allez stocker).

Installez le système Debian

Pour le choix du système d’exploitation, je suis partie sur un Debian 8.

Vous aurez à définir le nom d’utilisateur et mot de passe, nom de machine ainsi que le partitionnement de votre serveur (pour ma part, une seule partition montée à la racine pour faire simple).

Pour le choix des packages à déployer, gardez votre serveur vierge, juste un serveur SSH pour se connecter à distance avec un client type Putty.

Il ne reste plus qu’à installer le bootloader …

… et votre serveur est prêt !

Vous pouvez maintenant revenir sur votre poste de travail et vous connectez sur votre machine Linux en SSH avec un client comme Putty sous Windows :

Installez les prérequis : Java et MongoDB

Sur Debian, commencez par installer sudo en donnant les droits à votre utilisateur :

Il faudra vous déconnecter et vous reconnecter sur le serveur pour prendre en compte le “sudo”.

Pour faire fonctionner ElasticSearch & co, il vous faudra la JRE (Java Runtime Environment) :

Pour finir Graylog a besoin de MongoDB pour le stockage de la configuration entre autre.

Puis créez une DB Mongo que nous nommerons “graylog” ainsi qu’un utilisateur associé à cette DB :
Et une fois dans la CLI mongo :
Pour lancer le service Mongo à chaque démarrage :

Installez ElasticSearch

Connectez-vous sur le site d’ElasticSearch pour connaitre la dernière version en date. A l’heure où j’écris ces lignes nous sommes en version 1.6.0 (à remplacer par la version plus récente).

Il suffit donc de télécharger le package Debian et l’installer :

Editez ensuite le nom du cluster ElasticSearch (propriété “cluster.name”) que nous nommerons “graylog” :

Pour lancer le service :

Installez le serveur Graylog

Comme pour ElasticSearch, rendez-vous sur le site officiel pour connaitre la dernière version en date.

Puis téléchargez l’archive et installez le serveur dans /opt/graylog-server :

Ensuite configurez le serveur en copiant la configuration par défaut dans le /etc et editez le fichier :

Les propriétés à personnaliser sont le suivante :

• password_secret : clé secrète aléatoire à générer avec la commande “pwgen -N 1 -s 96“
• root_password_sha2 : hash du mot de passe pour le compte administrateur. Pour créer le hash de votre mot de passe utilisez la commande suivante : “echo -n votre_mot_de_passe | shasum -a 256“
• root_username : admin
• root_timezone =  Europe/Paris
• rest_listen_uri : laisser par défaut sur le port 12900
• elasticsearch_index_prefix : nom du préfix à utiliser dans ElasticSearch (mettre ‘graylog’)
• elasticsearch_cluster_name : nom du cluster ElasticSearch (mettre ‘graylog’)

Une fois votre fichier proprement configuré, vous pouvez démarrer Graylog avec la commande :

Et vérifiez que tout démarre correctement en lisant le fichier de log suviant :

ou plutôt efficacement avec un tail :

Si tout est OK, vous devriez voir la ligne suivante :

Installez l’interface Web de Graylog

Afin de piloter Graylog très facilement, je vous recommande l’installation de “Graylog Web Interface”. Encore une fois, récupérez la dernière version sur le site officiel et déployez l’archive sur votre serveur Linux :

Dans le fichier de configuration, définissez la clé secrète générée ci-dessus et modifiez l’URI du serveur Graylog (par défaut sur le port 19200) et la timezone si besoin.

• graylog2-server.uris=http://127.0.0.1:12900/
• application.secret= le secret partagé avec le serveur (défini dans le fichier de configuration de Graylog-Server)
• timezone= »Europe/Paris »

Pour finir lancez le service par la commande suivante :

Si tout est OK, vous pouvez maintenant utiliser votre navigateur pour vous connecter en HTTP sur votre serveur Graylog sur le port 9000 (par défaut) : http://{votre server}:9000/

Utilisez le compte “root” configuré dans le fichier de configuration de Graylog-Server (dans mon cas, le compte “admin” avec le mot de passe hashé) :

Nous voilà dans Graylog !

Installer Kibana

Téléchargez la dernière version en date (voir ici) et déployez là sur votre serveur :

Ensuite, pour lancer Kibana en tant que service :
Il ne vous reste plus qu’à votre rendre sur l’interface web : http://{votre serveur}:5601 et voilà votre serveur Debian avec ElasticSearch, Graylog et Kibana prêt à l’emploi !