Comment ajouter des données dans InfluxDB : guide pratique détaillé

InfluxDB est un système de gestion de base de données spécialisé dans les séries temporelles - c’est-à-dire des données horodatées, comme les relevés de capteurs (température, humidité…), les métriques système, etc. Il est très pratique avec son langage de requêtes pour manipuler des flux de données dans le temps : interroger les dernières 24h, faire des moyennes sur des tranches horaires, etc.

Comprendre la structure des données Time-Series dans InfluxDB

Les données arrivant dans InfluxDB sont horodatées : un champ spécial time d’horodatage est automatiquement ajouté à la création de l’enregistrement. Un tag “device” (une métadonnée de l’enregistrement) est un élément indexé qui permet de filtrer ou regrouper les séries (par capteur, par localisation, etc.). Chaque combinaison différente de tags crée une série distincte : le capteur de température de la chambre, le capteur de température du salon, le capteur de pression dans le jardin, etc.

“temperature” et “humidity” sont des fields pour stocker les valeurs mesurées. Ce point qui fait partie d’une série va être enregistré dans un measurement. InfluxDB est une base de données chronologique axé autour du TimeStamp. Le TimeStamp indique le nombre de secondes écoulées depuis le 1er Janvier 1970.

Les éditions et versions d’InfluxDB : impact sur l’ingestion

InfluxDB se décline en deux éditions : une édition communautaire open source, et une édition d'entreprise dotée de fonctionnalités plus avancées en matière de sécurité et de haute disponibilité. InfluxData commercialise en parallèle InfluxDB sous la forme d'un service cloud managé. InfluxDB v1 est toujours disponible sur le site d’InfluxData, mais la maintenance est minimale. Le langage de manipulation des données est InfluxQL, un langage simple qui se veut proche de SQL. InfluxDB v2 utilise le langage Flux, un langage de script fonctionnel puissant. InfluxDB v3 a opéré un revirement stratégique avec un retour au langage SQL, finalement bien plus familier des développeurs.

Encore et toujours avec un wagon de retard, je travaille actuellement avec la version 2.7.11, bien suffisante pour mes petits besoins, et toujours d’actualité, même si InfluxData recommande évidemment aujourd’hui le passage à InfluxDB v3. Il y a beaucoup de changements entre les versions chez InfluxDB, ça va faire le troisième changement. Sur InfluxDB 1, on avait un langage d'interrogation proche du SQL, qui était changé sur InfluxDB 2 pour un langage qui s'appelle Flux, qui ressemble plus à un langage fonctionnel, et maintenant, sur InfluxDB 3, on revient sur le langage SQL d'origine, amélioré par demande surtout des clients et des utilisateurs.

Lire aussi: Modifier Activité Kbis Auto-Entrepreneur

Prérequis et installation rapide

Je pars du principe que votre système d’exploitation est déjà installé avec une configuration IP valide ainsi qu’un service SSH fonctionnel (Optionnel). Pour disposer de la version la plus récente d'InfluxDB, il est recommandé de télécharger directement la base de données depuis le site d'InfluxData. InfluxDB est disponible pour FreeBSD, Linux, macOS ou encore Windows. Aux côtés de ses déclinaisons pour macOS et Windows en 64 bits, InfluxDB est disponible pour les distributions Linux openSuse, Red Hat, CentOS, Ubuntu et Debian.

Il faut ajouter les miroirs de InfluxData dans votre liste de miroirs afin que InfluxDb se mette à jour en même temps que les autres paquets. Le fichier de configuration d’InfluxDb se situe dans /etc/influxdb/influxdb.conf. La console Data Explorer d’InfluxDB propose une interface de gestion visuelle de la base de données. Une fois InfluxdDB installée en local, la commande influx permet d'activer l'interface de pilotage en lignes de commande (CLI) et de se connecter à l'instance InfluxdDB. Pour créer une première base de données, il suffit ensuite de saisir la commande CREATE DATABASE <db-name>.

Architecture recommandée pour collecter les données : Telegraf, InfluxDB, Grafana

Nouvel présentation et tutoriel autour de trois outils se combinant ensemble pour offre une solution de supervision complète. Telegraf, c’est un agent qui sera installer sur les machines que nous allons monitorer et qui inscrira via une requête HTTP les données qu’il récupèrera. A l'instar d'InfluxDB, Telegraf est aussi édité par InfluxData. La page Github de Telegraf recense toutes les données qu’il est possible de faire remonter.

Comme c’est Telegraf qui va envoyer les données vers notre serveur et non le serveur qui va récupérer les données de l’agent, cela permet d’éviter d’être bloquer par les pares feus dans le cadre de réseau distants. De plus avec une simple redirection de port, on peut contourner le filtrage en sortie sur le port 80 et 443 uniquement. Avant de pouvoir visualiser les données, il faut installer et paramétrer l’agent Telegraf sur les machines que nous souhaitons superviser. La variable interval indiquera le temps entre chaque récupération de données. La variable hostname vous permettra de différencier toutes vos machines. Nous allons maintenant créer un utilisateur qui aura le droit d’écrire et de lire dans la base, ce sera cet utilisateur que nous renseignerons dans le fichier de configuration de l’agent chez le client.

Grafana, permet de visualiser les données stockées dans InfluxDb et d’organiser le tout dans des dashboards à votre convenance. Grafana va tout simplement effectuer des requêtes sur le serveur InfluxDb et récupérer les informations qu’il souhaite. Le champ Name permet de donner un nom à la source de données. Cochez Default si vous souhaitez faire de cette source de données la source par défaut et ainsi gagner du temps lors du paramétrage des graphiques.

Lire aussi: INPI et Micro-Entreprise : Démarches

Comment écrire des données dans InfluxDB (méthodes)

Il existe plusieurs méthodes pour ajouter des données dans InfluxDB :

  • Via l’API HTTP d’InfluxDB en envoyant des points au format Line Protocol.
  • Avec des agents collecteurs comme Telegraf configurés pour écrire dans InfluxDB.
  • Via les bibliothèques client (SDK) pour divers langages qui encapsulent l’écriture.
  • À la main depuis la CLI (commande influx) ou via la console Data Explorer.

Line Protocol : format simple et efficace

Le Line Protocol est le format d’écriture texte natif d’InfluxDB. Chaque ligne représente un point :

measurement,tag1=val1,tag2=val2 field1=valval1,field2=valval2 timestamp

Exemple concret pour une sonde SHT31 (température et humidité) :

lora_data,device=capteur_1 temperature=23.5,humidity=45.2 1625074800000000000

Lire aussi: Comment Calculer la TVA ?

Lors de l'insertion, un champ spécial time d’horodatage est automatiquement ajouté à la création de l’enregistrement si le timestamp n’est pas fourni.

Envoi via HTTP (API)

InfluxDB est équipé d'une API. Taillée pour interagir avec le serveur de données du même nom, elle prend en charge les codes de réponse et l'authentification HTTP, ainsi que les jetons JWT. Pour envoyer des données via HTTP, il suffit de poster des lignes au endpoint d’écriture en s’assurant d’inclure l’authentification et le bucket (ou database selon la version).

Écriture avec Telegraf

Telegraf va collecter les métriques et les écrire automatiquement dans InfluxDB selon la configuration. C’est l’agent recommandé pour remonter des métriques système, des logs ou des métriques d’applications. La variable interval indiquera le temps entre chaque récupération de données et la configuration de sortie vers InfluxDB précisera l’utilisateur et le bucket (ou database) cible.

Flux : requêtes et exemples pour manipuler les séries temporelles (InfluxDB v2)

Le langage fonctionnel Flux d’InfluxDB v2 est inspiré de la programmation fonctionnelle avec des opérateurs comme map(), filter(), reduce() ou aggregateWindow(). Le symbole |> dans Flux est l’opérateur de pipeline, et il fonctionne un peu comme le | en bash. Il permet de chaîner les opérations les unes après les autres, en passant les résultats d’une étape à la suivante.

Prenons comme base la configuration utilisée dans mon projet LoRaWAN, qui stocke les mesures de température et d’humidité relevées par une sonde SHT31. Décomposons cette requête Flux typique :

  1. from(bucket: "lora-ttn") : la source de données est le bucket “lora-ttn”.
  2. |> range(start: -2h) : la taille de la fenêtre temporelle est limitée, en demandant seulement les données des deux dernières heures.
  3. |> filter(fn: (r) => r._measurement == "lora_data") : filtre pour des mesures spécifiques.
  4. |> keep(columns: ["_time", "_field", "_value", "device"]) : réduire le nombre de colonnes à l’essentiel.
  5. |> aggregateWindow(every: 1h, fn: mean, createEmpty: false) : regroupe les données par fenêtres d’1 heure et calcule la moyenne.

La partie fn: (r) => ... correspond à des fonctions anonymes appliquées ligne par ligne. Avec map on applique une fonction pour chaque ligne r du tableau. Avec createEmpty: false, on ignore les tranches sans données. Avec l’option createEmpty: true et l’instruction fill(column: "_value", value: 0), on prend en compte les tranches sans données.

Comportement spécifique des bases temporelles : contraintes et bonnes pratiques

Une base de données chronologique (Time-Series Database) a pour vocation d’évoluer très rapidement, tandis qu’une base de données traditionnel aura plus de mal et occasionnera des temps de réponse plus long. Les données arrivent dans l’ordre chronologique et sont toujours enregistrés comme nouvel enregistrement, il est donc impossible de mettre à jour des enregistrements comme avec UPDATE en SQL.

Certaines fonctions sont propres à ce type de bases de données, comme les politiques de rétention qui mettent en place une règle pour supprimer tous les enregistrements de plus de X temps ou encore les requêtes continues qui sont des requêtes s’exécutant automatiquement et stockant le résultat dans un champ spécifique de la base. Il faudra recourir au NTP pour synchroniser l'heure entre les différents hosts supportant le serveur de données, InfluxDB se cale sur l'heure locale en temps universel (UTC) pour gérer l'horodatage des données.

Configuration côté serveur et réseau

Par défaut, la base de données utilise le port 8086 pour les communications client-serveur et le port 8088 pour les transactions RPC visant à gérer les sauvegardes et les restaurations. Une fois InfluxDB installée, vous pouvez accéder au panel d’administration via l’adresse IP de votre serveur sur le port 3000 (Grafana) si vous avez configuré l’interface de visualisation.

Il faut préciser une police de rétention, afin de supprimer automatiquement les données au bout de x heures, jours ou semaines. Nous allons maintenant créer un utilisateur qui aura le droit d’écrire et de lire dans la base, ce sera cet utilisateur que nous renseignerons dans le fichier de configuration de l’agent chez le client.

Visualisation et alerting dans Grafana

Sélectionnez en premier lieu votre source de données, puis créer votre requête afin de sortir uniquement les données qui vous intéresse. Dans la catégorie Legend, vous pouvez afficher la valeur minimale, maximale, la moyenne et celle à l’instant T. Dans la catégorie Display, vous pouvez choisir l’apparence de vos graphiques. Vous pouvez choisir de les afficher sous forme de barres, de lignes ou de points.

Les seuils visuels se paramètrent de la façon suivante : gt ou lt pour Greater than ou Lower than, suivi de la valeur et de la couleur du seuil. Dans la variable « password », le mot de passe que vous utilisez pour vous connecter au serveur smtp. Attention, si ce dernier contient des # ou des ; il faudra ajouter trois quottes au début et à la fin. Attention les alertes que vous allez configurer vont remplacer les seuils configurés auparavant. Une fois l’alerte bien configurée, si vous vous rendez dans Alert list vous pourrez la voir affichée.

Bonnes pratiques pour l’ingestion et la pérennité des données

  • Utiliser des tags pour les métadonnées fréquemment filtrées afin d’améliorer les performances de requête.
  • Choisir fields pour les valeurs numériques mesurées (temperature, humidity).
  • Mettre en place des politiques de rétention pour contrôler la croissance du stockage.
  • Synchroniser l’heure des hosts via NTP pour garantir des timestamps cohérents.
  • Préférer l’écriture en batch pour réduire l’overhead réseau et améliorer les performances.
  • Surveiller l’utilisation disque et configurer des backups réguliers (RPC port 8088 pour les transactions de sauvegarde/restore).

Ressources et documentation

InfluxData offre sur son site une documentation complète sur InfluxDB. De nombreux tutoriels portant sur InfluxDB sont disponibles sur Internet. Pour disposer de la version la plus récente d'InfluxDB, il est recommandé de télécharger directement la base de données depuis le site d'InfluxData. La page Github de Telegraf recense toutes les données qu’il est possible de faire remonter.

Composant Rôle Port par défaut
InfluxDB Stockage séries temporelles 8086 (API), 8088 (backup/restore)
Telegraf Collecte et envoi des métriques sortant HTTP/HTTPS
Grafana Visualisation et alerting 3000 (interface web)

InfluxDB est avant tout une base de données. Graphite s'articule, lui, autour d'un outil de data visualisation graphique conçu pour suivre en temps réel les performances d'un site web, d'une application ou d'une infrastructure de serveurs. Donc, où en sommes-nous sur InfluxDB ? La société qui publie, donc l'éditeur, s'appelle InfluxData. On peut dire ça change beaucoup ou on peut dire : ils n'ont pas peur d'améliorer leur moteur de façon assez radicale.

balises:

Articles populaires: