[TUTO] Monitoring réseau (Telegraf + InfluxDB 1.8 + Grafana)

[.Shad.]

Je ne sais pas vous, mais j'ai eu une grosse augmentation de consommation mémoire d'InfluxDB (1.8).
Au point que même en limitant la mémoire dans le conteneur, cela bouffe toute la mémoire disponible sur mon VPS.

Je crois que ça va être l'occasion de tester InfluxDB 2.0

[MilesTEG1]

@.Shad. Je t'avoue que je n'ai pas vraiment de point de comparaison à avant, mais là j'ai cette consommation :

 

Par contre, c'est de loin celui qui m'en consomme le plus :

Même PMS n'en consomme pas autant alors qu'il est en train d'envoyer un flux vidéo vers un client.

[bruno78]

Bonjour @MilesTEG1, @.Shad.,

je suis sous Influxdb2 depuis plusieurs mois, .... et je n'ai vu aucune amélioration sur la consommation mémoire, toutes choses égales par ailleurs.

Par ailleurs, je suis jaloux de la conso mémoire de @MilesTEG1. De mon côté, j'ai certes beaucoup (trop ?) de graphes et dashboards, mais ma conso mémoire est plutôt de l'ordre de 3.5GB !!

Du coup j'ai été obligé de prendre une VPS à 8GB RAM, ce qui financièrement parlant ne tient pas la route. Je vais surement migrer influxdb2/grafana sur un RPI4 à 8GB ...

[Jeff777]

Bonjour  @bruno78

Cela ne m'incite pas à passer sous influx 2.0. Voilà ce que j'ai avec influx 1.8 (dsm7 RC) :

[.Shad.]

il y a 22 minutes, bruno78 a dit :

Par ailleurs, je suis jaloux de la conso mémoire de @MilesTEG1. De mon côté, j'ai certes beaucoup (trop ?) de graphes et dashboards, mais ma conso mémoire est plutôt de l'ordre de 3.5GB !!

Attention que la consommation d'InfluxDB dépend aussi du nombre de périphériques que tu supervises.
Perso j'en ai 6.
Tu peux aussi réduire la fréquence d'acquisition de Telegraf, je suis passé à 1 minute.
Et j'ai aussi découvert qu'il y a un réglage qu'on peut faire pour réduire la consommation mémoire d'InfluxDB (1.X, ça marche peut-être sur la v2 aussi je ne sais pas). Il faut changer le type d'indexation, il suffit d'ajouter une ligne dans influxdb.conf dans le conteneur :

docker exec -it influxdb bash
echo '  index-version = "tsi1"' >> /etc/influxdb/influxdb.conf 

On quitte le shell du conteneur et on le redémarre. Pour ma part j'ai gagné presque 800 Mo de la sorte. 

[bruno78]

Bonjour @Jeff777,

ça me laisse rêveur ! je dois avoir mal configuré quelque chose ....

mais je n'ai rien gagné au passage Influxdb => Influxdb2. J'avais déjà cette consommation mémoire avant.

Pour info, 21  dashboards avec une quinzaine de graphes par dashboard, et en général une période de refresh de 1mn. Période de retention des données de 90j.

il y a 3 minutes, .Shad. a dit :

Il faut changer le type d'indexation, il suffit d'ajouter une ligne dans influxdb.conf dans le conteneur :

docker exec -it influxdb bash
echo '  index-version = "tsi1"' >> /etc/influxdb/influxdb.conf 

On quitte le shell du conteneur et on le redémarre. Pour ma part j'ai gagné presque 800 Mo de la sorte.

@.Shad., je vais tenter le coup.

Cependant la doc Influxdb2 indique : et je suis bien en V2.0.4.

quay.io/influxdb/influxdb   v2.0.4    4be70a587e97   4 months ago   227MB

v2.0.4 General Availability [2021-02-04]

Docker

ARM64

This release extends the Docker builds hosted in quay.io to support the Linux/ARM64 platform.

2.x nightly images

Prior to this release, competing nightly builds caused the nightly Docker tag to contain outdated binaries. This conflict is fixed, and the image tagged with nightly now contains 2.x binaries built from the HEAD of the master branch.

Breaking Changes

inmem index option removed

This release fully removes the inmem indexing option, along with the associated config options:

• max-series-per-database
• max-values-per-tag

The startup process automatically generates replacement tsi1 indexes for shards that need it.

[Jeff777]

il y a 23 minutes, bruno78 a dit :

21  dashboards avec une quinzaine de graphes

Ah oui ! Je m'incline je n'en ai que 5 😂

[bruno78]

@Jeff777,

en fait je ne suis pas sûr que le nombre de graphes soit le problème, a priori cela concerne plutôt Grafana ?

Par contre la quantité de données rapatriées vers Influxdb doit être le vrai problème. En regardant rapidement, j'ai plus de  3G de données dans la db influxdb2. Si il met tout en mémoire  ......

PS : idem en passant à la dernière version (2.0.7) d'influxdb2.

Faut que je regarde comment "compacter" les données anciennes, par exemple supérieure à 1 mois. Pas forcement besoin de garder 1 échantillon par minutes sur 90j ? Je faisais ça sous Influxdb1 (retention policy et continuous query), mais je ne l'ai pas reconduit sous influxdb2, le mécanisme a changé ...

[.Shad.]

@bruno78 Ok pour le réglage inmem vs tsi1, donc visiblement la version 2.X impose le paramètre.
Maintenant je joue pas mal avec la rétention des données en effet, 2 semaines pour ce qui est le plus gourmand.
Généralement s'il y a un souci je mets moins de deux semaines pour m'en rendre compte.

Ca doit forcément exister sous InfluxDB 2.X

Modifié le 28 juin 2021 par .Shad.

[bruno78]

il y a 9 minutes, .Shad. a dit :

Ca doit forcément exister sous InfluxDB 2.X

@.Shad. oui je suis sûr que ca existe, faut juste prendre le temps. Je me disais qu'en ne gardant les données brutes de moins de  90j cela suffirait, mais apparemment non.

C'est mon prochain chantier ....

[.Shad.]

Alors j'ai un peu investigué hier, j'ai pu remarquer que le conteneur InfluxDB s'arrête à 6h et quelques secondes du matin.
Ca correspond à un envoi instantané d'une vingtaine de fois le même paquet de données de la part de pfSense.

J'ai désactivé le monitoring de ce dernier pour voir comme ça va se comporter dans les jours qui viennent.

Au passage, j'ai gagné environ 300Mo de mémoire en passant l'intervalle d'acquisition de 30s à 60s.

Modifié le 1 juillet 2021 par .Shad.

[bruno78]

Bonjour @.Shad.,

j'ai déjà une période d'acquisition de 60 secondes. Par contre, en passant la durée de conservation des données de 90j à 30j , je gagne bien environ 66% de consommation mémoire 🙂 .

Quant à la production de graphes long terme, Influxdb2 repose sur le principe de "task", qui permettent de faire du "down sampling" , finalement assez facilement. Du coup je garde des graphes sur 1 an, avec une periode de 15min. Pour le moment ça a l'air de bien fonctionner.

Curieux de voir pourquoi le monitoring du pfsense ferait planter influxdb .....

[.Shad.]

Pour l'instant je n'ai pas cherché plus que ça, j'essaie déjà d'établir le lien de cause à effet, mais oui c'est étrange.
Après pfSense a subi (subi est le mot au vu des soucis qui ont émergé) une mise à jour majeure, le paquet Telegraf a été mis à jour également, et moi je suis resté sur la version antérieure, tout en ayant mis à jour le paquet, ceci explique peut-être cela.

Pour la rétention je suis à 4 semaines pour les graphes, 2 semaines pour les speedtest.

[.Shad.]

En ramenant la politique de rétention à une durée de 2 semaines pour les périphériques, et 2 jours pour le speedtest, je suis passé à 1 Go de mémoire pour InfluxDB, ce qui est beaucoup² plus raisonnable.
Ca n'explique pas les envois multiples de pfSense, que je vais réactiver pour vérifier s'il influe beaucoup (c'est lui qui remonte le plus de données je pense). Normalement Telegraf stock les données dans une mémoire tampon le temps qu'InfluxDB soit prêt à les recevoir. Il ne fait pas d'envois successifs. Après Telegraf tourne en tant que paquet tiers sur pfSense, et ce n'est pas mis à jour tous les quatre matins, peut-être que l'implémentation n'est pas optimale...

A suivre 🙂 

[oracle7]

@.Shad.

Bonjour,

Si je te suis bien, je comprends que tu as une BD influx pour tes périphériques et une spécifique pour Speedtest et que tu as réglé la durée de rétention des données en ajoutant manuellement une commande de modification de cette politique juste après avoir créée/recréée chaque BD influx. J'ai bon ?

Cordialement

oracle7😉

[MilesTEG1]

C'est comment qu'on règle la durée de rétention des données ?
Là j'ai le dossier monitoring qui fait 8 Go, je pourrais peut-être l'alléger un peu 🙂 

[oracle7]

@MilesTEG1

Bonjour,

Regardes la réponse de @.Shad. à @Kramlech dans ce post.

Cordialement

oracle7😉

[.Shad.]

@oracle7 @MilesTEG1 J'ai ajouté cette variable dans mon conteneur InfluxDB depuis quelques temps :

INFLUXDB_META_RETENTION_AUTOCREATE=false

Ca ne permet de ne plus créer automatiquement la politique de rétention "autogen" (durée de 1 an, shards de 1 semaine).
A la place je crée manuellement mes politiques de rétention pour chaque base de données InfluxDB, par exemple :

CREATE RETENTION POLICY "2w" ON "nas_telegraf" DURATION 2w REPLICATION 1 DEFAULT

Ici c'est deux semaines, pour deux jours c'est "2d", etc... Plus d'info ici pour la manipulation des politiques de rétention des données : https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#create-retention-policies-with-create-retention-policy

Je garde deux semaines pour les périphériques, et deux jours pour les speedtests, qui sont effectivement sur des instances InfluxDB séparées.

Modifié le 5 juillet 2021 par .Shad.

[oracle7]

@.Shad.

Bonjour,

Merci de ta réponse rapide qui est on ne peut plus claire et précise ! 👍👏

De façon pratique, si cela peut aider voici ce que j'ai fait (sur la base des infos de @.Shad.):

Citation

• Prérequis :
  • Modifier le conteneur « influxdb » (fichier docker-compose.yml) pour y ajouter la variable d’environnement « INFLUXDB_META_RETENTION_AUTOCREATE=false » pour que la politique de rétention par défaut « autogen » ne soit plus créée (durée 1 an, shards 1 semaine).

  • Une database dédiée configurée sous influxdb, avec son user/pwd dédié.

root@MonNAS:/volume1/docker/speedtest# docker exec -it influxdb influx -username admin -password admin

> show databases

> use speedtest

> show retention policies

name         duration shardGroupDuration replicaN default

----         -------- ------------------ -------- -------

autogen      0s       168h0m0s           1        false

•        Créer une nouvelle politique de rétention :

> CREATE RETENTION POLICY "Retention" ON "nas_speedtest" DURATION 1d REPLICATION 1 DEFAULT

> show retention policies

name         duration shardGroupDuration replicaN default

----         -------- ------------------ -------- -------

autogen      0s       168h0m0s           1        false

Retention15j 336h0m0s 24h0m0s            1        true

 

• Si besoin de modifier ensuite la politique :

> ALTER RETENTION POLICY "Retention" ON "nas_speedtest" DURATION 3w SHARD DURATION 2h DEFAULT

 

• Si besoin de supprimer la politique :

> DROP RETENTION POLICY "Retention" ON "nas_speedtest"

> exit

 

• Recréer le conteneur « influxdb » :

o    cd /volume1/docker/scripts_instal/monitoring

o    docker-compose down

o    docker-compose up -d

 

• Recréer le conteneur « speedtest2 » :

o    cd /volume1/docker/scripts_instal/speedtest2

o    docker-compose down

o    docker-compose up -d

Cordialement

oracle7😉

Modifié le 5 juillet 2021 par oracle7

[Dimebag Darrell]

Merci pour l'info concernant la rétention des données.

depuis Avril, j'ai environ 8Go de log... 😕
Je viens de lire la marche à suivre,

Est-on obligé de recréer les containeurs après l'applications de la nouvelle politique de rétention ?

 

[oracle7]

@Dimebag Darrell

Bonjour,

Il y a 4 heures, Dimebag Darrell a dit :

Est-on obligé de recréer les containeurs après l'applications de la nouvelle politique de rétention ?

Oui cela me parait préférable ...

Cordialement

oracle7😉

[.Shad.]

Il y a 6 heures, Dimebag Darrell a dit :

Est-on obligé de recréer les containeurs après l'applications de la nouvelle politique de rétention ?

Ca dépend.
Si :

• d'une part Telegraf utilise sa configuration de base (pas de précision concernant quelle politique de rétention il faut utiliser dans InfluxDB)
• d'autre part la nouvelle politique de rétention que tu as créée a été taggée comme politique par défaut

alors tu n'as rien à faire, ni redémarrer ni recréer.

Si en revanche Telegraf taggait ses données pour une politique en particulier, et que celle-ci n'est pas la politique par défaut pour la base de données en question dans InfluxDB, alors tu dois adapter ton fichier telegraf.conf

[oracle7]

@.Shad.

Bonjour,

Il y a 11 heures, .Shad. a dit :

Si en revanche Telegraf taggait ses données pour une politique en particulier, et que celle-ci n'est pas la politique par défaut pour la base de données en question dans InfluxDB, alors tu dois adapter ton fichier telegraf.conf

Pour bien comprendre, du coup cela veut dire qu'il faut renseigner avec le nom de la politique particulière, le champ :

  retention_policy (actuellement vide) dans [[outputs.influxdb]] ?

Cordialement

oracle7😉

[.Shad.]

Oui si et seulement si la nouvelle politique de rétention dans InfluxDB n'a pas été taggée comme celle à utiliser par défaut.

[oracle7]

@.Shad.

Ok Merci c'est plus clair maintenant !

Cordialement

oracle7😉