CatégorieBase de donnéesLinuxMonitoring

La rétention de données sur Influxdb


Par défaut la rétention des données d’Influxdb est paramétré à “l’infini”. Ce qui fait qu’on ne peut pas vraiment parler de rétention… 😅

Nous allons voir comment paramétrer la rétention des données sur notre instance Influxdb.

Activer les règles de rétention sur Influxdb

Pour activer la possibilité d’avoir de la rétention sur notre instance Influxdb, il faut modifier le fichier de configuration contenu dans /etc/influxdb/influxdb.conf et décommenter les deux options “enabled” et “check-interval”.

[retention]
  # Determines whether retention policy enforcement enabled.
 enabled = true

  # The interval of time when retention policy enforcement checks run.
 check-interval = "30m"

L’option “check-interval” est paramétré à 30 minutes par défaut. Il s’agit de l’intervalle où Influxdb va exécuter les règles de rétention.

Il faudra redémarrer Influxdb après avoir modifier le fichier de configuration via la commande suivante :

systemctl restart influxdb

Création d’une règle de rétention

Pour créer une rétention, il faut le faire directement lors de la création d’une nouvelle base de données. Sinon si vous créer une rétention sur une base qui existe déjà, vous ne pourrez plus accéder aux anciennes données insérées dans la base de données avant la création de la rétention. Il est donc important soit de prévoir les rétentions qu’on devra appliquer à une nouvelle base de données, soit de voir plus loin dans la documentation comment faire pour modifier la règle de rétention par défaut d’une base de données.

Pour créer une base de données, on fait la commande suivante :

CREATE DATABASE "nom_de_la_bdd"

Avant d’écrire des données dans cette base de données, on fera la création de la rétention. On mettre le paramètre “REPLICATION” à 1 car nous avons qu’un seul nœud. Le paramètre “DEFAULT” est très important, sinon la règle de retention ne sera pas celle par défaut, les nouvelles données ne seront donc pas insérées dans la base de données en utilisant cette règle de rétention mais celle par défaut “autogen” lors de la création de la base.

CREATE RETENTION POLICY "four_weeks" ON "nom_de_la_bdd" DURATION 4w REPLICATION 1 DEFAULT

On pourrait aussi directement créer la base de données et la rétention via une seule commande, à vous de voir… (Il faut savoir qu’on ne peut pas modifier le nom d’une règle de rétention).

CREATE DATABASE "nom_de_la_bdd" WITH DURATION 4w REPLICATION 1 SHARD DURATION 7d NAME "four_weeks"

La création d’une règle de rétention est donc le meilleur choix pour une base de données qui n’existe pas encore ! Donc comment faire pour le cas d’une base de données déjà existante ?

Modification d’une règle de rétention

Vous avez donc déjà vos bases de données Influxdb et vous souhaiter modifier la rétention des données de celle-ci. La modification d’une règle de rétention n’est pas sans risque, puisqu’il s’agit de supprimer l’ensemble des données qui dépasse la rétention. Il ne faudra donc pas se tromper sur la durée de la rétention… 🙄

Pour info : La règle de rétention par défaut sur les bases de données Influxdb s’appelle “autogen”.

Donc on fera la commande suivante pour modifier la durée de rétention de la règle par défaut “autogen” d’une certaine base de données. Les règles de rétention étant associées aux bases de données, il faut le faire sur chaque base de données où vous souhaiter appliquer la rétention.

ALTER RETENTION POLICY "autogen" ON "nom_de_la_bdd" DURATION 14w SHARD DURATION 5d DEFAULT

Ici je modifie donc la règle de rétention “autogen” pour une durée de 14 semaines (3 mois) avec une durée d’expiration de 5 jours pour les shards. Je met cette règle de rétention par défaut par le paramètre “DEFAULT”.

Dans ma commande, je peux remplacer “autogen” par le nom de ma règle de rétention que j’ai choisi si j’ai créer une règle de rétention directement lors de la création de ma base de données.

Les shards

Avant tout, nous devons voir quelques définitions traduits depuis la documentation d’Influxdb.

Définition d’un shard :

Un shard contient les données réelles codées et compressées, et est représenté par un fichier TSM sur disque. Chaque shard appartient à un seul et unique groupe de shards. Plusieurs shards peuvent exister dans un seul groupe de shards. Chaque shard contient un ensemble spécifique de séries. Tous les points d’une série donnée dans un groupe de shards donné seront stockés dans le même shard (fichier TSM) sur le disque.

Définition des groupes de shards :

Les groupes de shards sont des récipients logiques pour les shards. Les groupes de shards sont organisés en fonction du temps et de la politique de conservation. Chaque politique de conservation qui contient des données est associée à au moins un groupe de shards. Un groupe de shards donné contient tous les shards avec des données pour l’intervalle couvert par le groupe de shards. L’intervalle couvert par chaque groupe de shards est la durée du shard.

Lors de la modification ou création de règle de rétention pour une base de données Influxdb, nous avons parler de “SHARD DURATION”… De quoi s’agit-il ? Il s’agit de l’intervalle à laquelle le groupe de shards couvre la durée du shard.

Donc si vous ne vous êtes pas encore endormi… et que vous êtes arrivé à ce point de la documentation, vous devinez que vous ne pouvez pas mettre le paramètre “SHARD DURATION” à une valeur plus élevée que la durée de rétention elle même.

La documentation d’Influxdb nous recommande de suivre le tableau suivant :

Durée de la règle de rétentionDurée du groupe de shards
<2 jours1 heure
>=2 jours et <=6 mois1 jour
>6 mois7 jours

Nous pouvons bien-sûr adapter celui-ci comme nous le voulons tant que nous respectons la logique que vous avez lu un peu plus haut…

Problèmes rencontrés

Pourquoi ne pas créer une nouvelle règle de rétention sur une base de données existante ?

Si nous créons une règle de rétention sur une base de données qui existe déjà, lorsque nous y accéderons depuis Grafana par exemple, nous n’aurons accès qu’aux données concernées par la nouvelle règle de rétention paramétré par défaut. Donc vous allez avoir une petite sueur froide en voyant que vos données ont disparues… (ça m’est arrivé).

Cela s’explique les données seront stockés dans des répertoires différents. Chaque règle de rétention différente à son répertoire dédié… Donc on accède plus au même répertoire pour requêter nos données.

Publié par Alexy DA CRUZ

Administrateur systèmes depuis maintenant plus de 2 ans et passionné par le développement, je partage mes connaissances sur mon portfolio.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *