Projet AQ - Mode d'emploi - Partie 3 : Présentation du tableau de bord de la qualité de l'air de DesignSpark

La plateforme Cloud fournit une puissante base de données de séries temporelles et d'analyses pour le projet sur la qualité de l'air.

Dans cet article, nous jetons un premier coup d'œil à la plateforme DesignSpark Metrics qui sera utilisée pour le stockage et la visualisation des données dans le cadre du projet Qualité de l'air. La plateforme cloud s'appuie sur la base de données de séries temporelles Prometheus pour le stockage, ainsi que sur Grafana pour l'analyse et la visualisation.

Prometheus

Prometheus est une base de données de séries temporelles, ce qui signifie que les données qui y sont écrites sont stockées sous la forme d'une série de valeurs ordonnées chronologiquement.

Une série dans Prometheus est identifiée par une combinaison unique d'un nom de métrique et d'une ou plusieurs étiquettes. Par exemple, il peut y avoir deux séries avec le nom métrique « température », mais l'une avec une étiquette « intérieur » et l'autre « extérieur ». Cela signifie que nous pouvons éviter d'avoir à trouver des noms de mesures globalement uniques tels que « indoortemp » (température à l’intérieur) et « outdoortemp » (température à l’extérieur), tout en séparant les mesures lors de leur écriture et en construisant des requêtes qui ne renvoient que les données qui nous intéressent.

Outre la sélection des données par un nom de métrique et une ou plusieurs étiquettes, le langage de requête Prometheus permet également de sélectionner des plages, des sous-requêtes, des fonctions et des opérateurs, etc. Une API de requête HTTP est fournie, mais nous utiliserons l'application web Grafana pour la visualisation, qui bénéficie d'une intégration transparente avec les sources de données Prometheus.

Écrire des données

Plutôt que d'être simplement une base de données passive, Prometheus emploie un modèle tiré et se trouve généralement configuré pour gratter des métriques sur HTTP. Ceci est particulièrement utile pour les infrastructures informatiques, où il peut y avoir de nombreux systèmes basés sur le web qui peuvent être interrogés pour collecter des métriques et les stocker en un seul endroit. Ou peut-être avec des systèmes de capteurs propriétaires, où il n'y a pas d'API exposée et où le micrologiciel ne peut pas être modifié, mais où il y a une interface web qui peut être récupérée.

Fragment de la définition des Protocol Buffers pour l'écriture à distance de Prometheus.

Dans notre cas, Prometheus est un service hébergé et, en tant que tel, il ne serait pas pratique qu'il se connecte sur Internet et récupère les mesures des appareils situés derrière un pare-feu. Cependant, Prometheus fournit également un mécanisme d'écriture à distance, qui utilise à nouveau HTTP, mais qui est cette fois-ci basé sur le format de fil binaire Protocol Buffers. Dans le cadre du projet Qualité de l’air, ce formatage est géré par l'application de qualité de l'air de l'appareil, qui lit les capteurs ESDK et, si un endpoint Prometheus est configuré, elle compile les lectures dans des messages sérialisés qui sont ensuite écrits dans le cloud Prometheus.

Une autre option consiste à utiliser Grafana Agent, qui est essentiellement une version réduite de Prometheus et qui peut être configuré pour récupérer des métriques à partir d'applications hébergées sur le réseau local, puis les écrire dans une instance Prometheus distante. C'est quelque chose que nous examinerons dans un prochain article et qui pourrait être utile si nous voulons collecter des données à partir d'un capteur tiers doté d'une interface web.

Que vous utilisiez l'application de qualité de l'air de l'appareil ou Grafana Agent, pour utiliser le mécanisme d'écriture à distance, il est nécessaire d’avoir un ID de l'instance Prometheus distante ainsi qu'une clé API.

Grafana

Grafana est une puissante application web d'analyse et de visualisation, dont la version open source a été utilisée dans divers projets qui ont fait l'objet d'articles sur DesignSpark ces dernières années. Cependant, la version hébergée fournie dans le cadre de DesignSpark Metrics est un service entièrement géré, ce qui signifie qu'elle est fréquemment mise à jour et sauvegardée, entre autres avantages.

Ci-dessus, nous pouvons voir une visualisation Grafana très simple, avec des tracés de lignes pour les données des séries de température, d'humidité, de TVOC et de CO2, générées par le matériel ESDK à trois endroits différents.

Si nous choisissons de modifier la configuration pour ce tracé de température, nous pouvons voir qu'une source de données Prometheus est utilisée et que la première série tracée (A) est la température où le friendlyname='abackhome'. La deuxième série (B) sélectionne la température avec friendlyname=’milnetowers’, avec également un « friendlyname » (nom convivial) unique pour la troisième ligne (C).

Heureusement, nous n'avons pas besoin de maintenir une liste de tous les noms de métriques et d'étiquettes, puisque Grafana propose un navigateur de métriques que nous pouvons activer, puis utiliser pour construire une requête en pointant et en cliquant.

Bien sûr, les données peuvent être visualisées de bien d'autres manières plus intéressantes que de simples tracés. Par exemple, avec de grandes valeurs statistiques + des sparklines, comme illustré ci-dessus. Ici, vous pouvez également voir sur la droite quelques-unes des autres options de visualisation disponibles.

Projet Qualité de l’air

Modèle de données

Les étiquettes Prometheus supplémentaires suivantes sont utilisées par le projet Qualité de l'air :

• hwid. Numéro de série du matériel.
• geohash. Une latitude et une longitude formatées de manière pratique.
• sensor. Type de capteur et version du matériel.

Le hwid est utilisé pour identifier de manière unique le matériel de l'ESDK et permet ainsi d'éviter les collisions de noms, qui pourraient se produire si nous nous appuyions uniquement sur un « friendlyname » configuré par l'utilisateur. Un geohash est simplement un moyen pratique d'encoder une latitude et une longitude. L'emplacement de l'appareil est important pour regrouper les données par zone, par exemple pour créer des « plans de chaleur » sur la qualité de l'air. La connaissance du type de sensor utilisé peut être importante pour l'interprétation des résultats, et il se peut même que la précision puisse être améliorée en combinant des données provenant de plusieurs capteurs et en appliquant des corrections.

Confidentialité

La plateforme DesignSpark Metrics sera utilisée pour héberger des tableaux de bord à usage privé, ainsi que des tableaux de bord publics pour les initiatives de l'ingénierie militante, telles que le projet sur la qualité de l'air. Dans ce dernier cas, les détails concernant les données stockées, la manière dont elles seront traitées, les personnes qui y auront accès, etc. seront effacés dans le cadre de la procédure d'inscription pour contribuer à un tableau de bord public.

— Andrew Back