InfluxDB, shard, shard duration et retention policies


06/10/2021 influxdb timeseries influxdata shard shard duration retention policy shard group

CérénIT a été contacté pour mener l’audit d’une instance InfluxDB 1.8 OSS utilisée dans un projet IoT lié à l’énergie. L’audit avait plusieurs objectifs :

  • Comprendre la consommation mémoire de l’instance (48Go / 64Go de la VM)
  • Faire un état de santé de la plateforme et estimer sa capacité à stocker et procésser des données supplémentaires dans le cadre de l’ouverture d’une application métier
  • Expliquer la raison des problèmes observés par le passé et évaluer les solutions apportées
  • Etablir des recommendations et éventuellement les implémenter.

De l’audit, on notera que :

  • L’instance contient ~35.000 shards / ~36.000 tsm files pour environ 200 bases permanentes et des dizaines de bases éphémères permettant de calculer des indicateurs ou de recalculer des historiques de données suite à des changements de paramètres de l’application métier (plusieurs dizaines de milliers de bases temporaires par semaine, avec des profondeurs de données variables)
  • Les recommendations pour InfluxDB Enterprise sont d’avoir 30/40 bases par data nodes et 1.000 shards par data node

Avant d’aller plus loin, précisons un peu cette notion de shard et les notions liées pour bien appréhender le sujet :

  • Une instance InfluxDB peut contenir 1 à n bases de données (database),
  • A chaque base de données InfluxDB, on peut définir une “retention policy” qui est la période maximale de conservation des données. Avec une retention policy de 7 jours par ex, seules les données des 7 derniers jours sont conservées. Les données les plus vieilles seront alors supprimées au fur et à mesure que les nouvelles données arriveront via un mécanisme de compaction.
  • Les données d’une base de donneés InfluxDB sont réparties au sein de shards au niveau stockage ; chaque shard comprend les données sur une période de temps donnée. Si une base de données a une retention policy d’une semaine, alors chaque shard contiendra 1 jour de données. Nous aurons donc 7 shards pour cette base de données. Ce délai est appelé shard duration.
  • Au sein de chaque shard, nous allons retrouver les données sous la forme d’un ou plusieurs fichiers TSM, le fichier d’index pour le shard, ainsi que le fichier de WAL et de cache.

Nous pouvons représenter la logique instance > database > shard(s) > tsm files de la façon suivante :

InfluxDB - database / shard / tsm files

Par défaut, InfluxDB applique les shard duration suivantes en fonction des retention policy :

Retention policy Default shard duration
<= 2 days 1 hour
<= 6 months 1 day
> 6 months 7 days

Source : InfluxData - Shard group duration

Dès lors, une base de données avec une retention policy infinie aura une shard duration de 7 jours. Ainsi, si cette base contient 10 ans d’hisorique (soit 10 * 52 semaines = 520 semaines), elle contiendra 520 shards.

Du coup, InfluxData recommande les valeurs suivantes (au moins en 1.x ; on peut supposer que cela reste valable en 2.x):

Retention policy Default shard duration
<= 1 day 6 hour
<= 7 days 1 day
<= 3 months 7 days
> 3 months 30 days
infinite >= 52 weeks

Source : Shard group duration recommendations

Selon cette perspective, la base de données avec 10 ans d’historique ne contiendra plus 520 shards mais 10 shards en prenant une shard duration de 52 semaines. L’écart entre la valeur par défaut et la valeur recommandée est plus que significatif.

Pour bien dimensionner vos shard duration, InfluxData recommande :

  • La durée doit être égale à 2 fois la période d’analyse la plus longue et la plus fréquente ; si vos analyses les plus fréquentes portent sur 6 mois de données maximum, alors votre shard duration est d’un an
  • Chaque shard doit contenir au moins 100.000 points
  • Chaque shard doit contenir au moins 1.000 points par série (combinaison de measurement (~table) + combinaison des tags + clés des fields)

Pourquoi nous en arrivons là ? C’est assez simple :

  • InfluxDB au lancement va découvrir l’ensemble de ses shards et les périodes qu’ils recouvrent
  • InfluxDB cherche à mettre un maximum de données en mémoire par souci d’efficience et de performance
  • Une requête sur des périodes longues va nécessiter de monter en mémoire tous les shards correspondants à la période

Dès lors, un nombre important de shards va augmenter d’autant plus la consommation mémoire et le nombre de fichiers ouverts pour manipuler les données associées.

Si on recoupe ces données avec les recommendations pour InfluxDB Entreprise, à savoir 30/40 bases par data nodes et 1.000 shards par node, le bon réglage des retention policy et des shard durations n’est pas à négliger pour la bonne santé de votre instance.

En outre, s’il est possible de mettre à jour la retention policy et la shard duration en 1.x, cela ne s’appliquera que pour les nouveaux shards. Les anciens shards ne seront pas “restructurés” en fonction des nouvelles valeurs.

Pour mettre à jour les shards existants, il faut :

  • Arrêter les mécanismes d’ingestion de données
  • Exporter les données sous la forme de points au format InfluxDB Line Protocol via influxd inspect export
  • Supprimer les measurements (voir la base de données si vous voulez aller plus vite)
  • Modifier la retention policy et la shard duration de la base de données (ou créer une nouvelle base de données avec les bonnes valeurs pour la retention policy et la shard duration)
  • Importer les données par batch de 5000 à 10.000 points.
  • Valider le bon fonctionnement de l’instance et l’intégrité des données
  • Relancer les mécanismes d’ingestion et gérer le rattrapage.

Ultime question, la version 2.x OSS change-t-elle la donne sur le sujet :

En conclusion, ce qu’il faut retenir :

  • La retention policy et la shard duration de vos bases InfluxDB ne sont pas à négliger et les valeurs par défaut ne sont surement pas adaptées à votre cas d’usage
  • Il est possible de mettre à jour ses valeurs mais elles ne s’appliqueront qu’aux nouveaux shards - pour les anciens shards, il faut exporter les données sous la forme de points et les réimporter
  • Il faut trouver la bonne taille de shard duration adaptée à votre cas d’usage ; trop de shards ou des shards trop gros ont chacun leur limites et auront des effets différents sur la consommation CPU/RAM/IOPS
  • Pour InfluxDB (Entreprise), il est recommandé d’avoir maximum 1.000 shards et 30/40 bases par node.
  • La version 2.x OSS n’apporte pas grand chose de plus sur le sujet - la version 2.1 permet d’être à peu près au niveau de la 1.x.

Mise à jour : le client reporte les gains suivants post restructuration des bases pour le serveur de recette et production :

  • Les dashboards simples sont entre 15% et 30% plus rapides pour leur affichage
  • Les dashboards complexes sont entre 3 et 10 fois plus rapides pour leur affichage
  • La consommation mémoire reste stable autour de 6/8 Go
  • Des changements sur la shard duration de certaines bases ont permis de descendre jusqu’à 600 shards environ.

Web, Ops, Data et Time Series - Septembre 2021


29/09/2021 warp10 automl telegraf discovery anomalie python docker podman npm nodejs jvm adoptopenjdk questdb cloudflare aws s3 docker warp10 discovery tinygo circuitpython nrtsearch elasticsearch influxdb

Cloud

Container et Orchestration

  • Docker is Updating and Extending Our Product Subscriptions : TL;DR: Docker Desktop requiert un abonnement Pro/Team/Business si vous êtes une organisation de plus de 250 employés et 10 Millions de Chiffre d’affaires. L’abonnement commence à 5$/mois/utilisateur. Ce changement démarre au 31/08/2021 avec une période de grâce jusqu’au 31/01/2022. Si certains crient au scandale, il faut bien voir tout ce que Docker Desktop fourni et le travail d’intégration que cela représente. Il faut bien que la société Docker vive pour maintenir ses produits. Tout cela se retrouve dans The Magic Behind the Scenes of Docker Desktop.
  • Podman Release v3.3.0 : cette version apporte “podman machine” qui devrait notamment permettre un meilleur support de podman sous OSX avec une couche de virtualisation intermédiaire dans la même veine que Docker Desktop dans le but de proposer une intégration native. Cela ne semble pas fonctionner sur un Apple M1 à cause de l’incompatibilité actuelle de Virtual Box avec ces puces. Si Podman peut certes être une alternative à Docker (Desktop), cela montre aussi le travail d’intégration réalisé par Docker Inc notamment pour le support des Apple M1.
  • Podman on Macs Update : statut sur le support de Podman dans un context MacOS/Intel, Windows/Intel et le reste à faire pour MacOS/M1. En attendant, podman machine est supporté nativement sur Linux et MacOS/Intel et en remote client sur Windows/Intel.
  • How Docker broke in half : restrospective sur Docker de ses origines à aujourd’hui et quelques pistes pour le futur…
  • Docker Compose V2.0.0 : L’outil a été réécrit en go plutôt qu’en python et se veut accessible via la docker cli en tant que sous système (ie docker compose xxx). Pour Windows & OSX, il est fourni avec Docker Desktop.
  • Accelerating New Features in Docker Desktop où l’on parle de l’arrivée prochaine d’un Docker Desktop For Linux !!
  • No, we don’t use Kubernetes : un billet rafraichissant qui rappelle que Kubernetes n’est pas l’alpha et l’omega de l’infrasatructure.

IoT

JVM

Recherche

Sécurité

Time Series

Web, Ops, Data et Time Series - Aout 2021


25/08/2021 docker influxdb grafana timescaledb terraform kubernetes rook traefik consul consul-connect service-mesh hashicorp golang vector

Conteneurs et orchestration

  • Engineering Update: BuildKit 0.9 and Docker Buildx 0.6 Releases : diverses améliorations au niveau du format Dockerfile, de buildtkit et de docker-buildx. Le changement le plus visible et apprécié sera surement le support de la syntaxe “Here-Documents”
  • Rook v1.7 Storage Enhancements : Possibilité d’installer un cluster Ceph via un chart Helm (plutôt que via les manifests), des options d’amélioration de la résilience d’un cluster (file mirroring, resource protection from delettion, “stretch cluster” passe en stable) et d’autres améliorations diverses (mise à jour des CRD, etc). A noter que le driver flex va disparaitre en 1.8 au profit du driver CSI.
  • Announcing Traefik Proxy 2.5 : Support de Kubernetes 1.22 (et mise à jour des CRD associées, ainsi que des API dépréciées), support de Consul Connect (le service mesh fourni par consul), gestion des plugins locaux et possibilité de créer ses propres providers (dans la même veine que Docker, Kubernetes, etc), support expérimental d’HTTP/3 et enfin ajout des middleware au niveau TCP (et pas uniquement HTTP)
  • Integrating Consul Connect Service Mesh with Traefik 2.5 : ex d’intégration Traefik 2.5 avec Consul Connect.
  • Beta Support for CRDs in the Terraform Provider for Kubernetes : la resource kubernetes_manifest permet de définir ses propres manifests et donc permet d’utiliser des CRD non disponibles dans le provider officiel. Plus pratique que de générer les manifests via des templates et de faire du kubectl apply par dessus.

Go

  • Learning Go by examples : Les parties 4 à 7 sont arrivées avec du CLI, du Bot, du jeu, des app Desktop/GUI, etc.

Monitoring & Observabilité

  • Grafana Labs Raises $220 Million Round at $3 Billion Valuation : Grafana Labs continue sur sa lancée avec une 3ème levée de fonds de 220 M$ quasiment un an jour pour jour après leur série B. Soit un total de 295 M$ et une valorisation de 3 Mds $. Ils avaient annoncé il y a quelques années vouloir batir une solution à 360° de l’observabilité, c’est en train de se réaliser. Avec l’intelligence de pouvoir utiliser tout ou partie de leurs produits en fonction de nos besoins.
  • Vector v0.16.0 release notes : Ajout d’une source nats, support des proxys HTTP, amélioration du rate limiting des sinks faisant des appels HTTP, chart helm en beta et d’autres améliorations.

Time Series

Web, Ops, Data et Time Series - Juillet 2021


28/07/2021 kubernetes gitlab-ci buildah podman kaniko golang scaleway ia aws frenchtech euclidia vector sécurité opnsense wireguard katz facebook prophet arima sarima holt-winters lstm

CI/CD

Cloud

Container & Orchestration

Golang

IA

  • AI Days 2020 : la playlist youtube des AI Days 2021 est disponible, avec un angle industriel qui change de d’habitude.

Monitoring

  • Vector v0.15.0 release notes : de nouveaux sinks & sources, des transformations et de la visualisation. Vector s’améliore au fil des versions.

Sécurité

Time Series

WireGuard

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)

Nuage de tags

docker kubernetes timeseries influxdb warp10 grafana traefik python ansible elasticsearch kafka postgres aws sécurité terraform mysql redis telegraf dashboard docker-compose git ovh tick cassandra chronograf cloud hashicorp helm timescaledb flux iot podman ptsm swarm test vector kapacitor rancher résilience timescale cérénit gcp gitlab influxdata log machine-learning monitoring postgresql prometheus raspberrypi s3 spark sql vscode api architecture arm bilan comptabilité confluent devops gitlab-ci iac java ksql microservice nomad optimisation perspective serverless service-mesh angularjs bigdatahebdo cert-manager cli cncf consul container discovery dns flows gke graphql influxace ingress javascript npm opensource operator performance pipeline rook scaleway ssh stream vault warpscript windows audit containerd csp documentation elastic forecast geospatial golang hpkp jenkins json kafka-streams kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile mqtt nginx orientdb quasardb redhat registry rest rethinkdb reverse-proxy rgpd sauvegarde warpstudio wireguard agile anomalie apm arima automatisation azure bash big-data ceph certificat challenge ci/cd cio cluster co2 continous-delivery continous-integration cookie cto data datatask dataviz dbt deployment diff django edge esp32 facebook fec fluxlang framework gdpr google-analytics grav hsts http/3 https hypriot hébergement ia influxdays istio jq k3s lets-encrypt linux load-balancer longhorn meetup metabase molecule mongodb nosql nvidia openebs openhab openssh ovhcloud pandas parquet percona php pip questdb reaper replication rootless rpi rsyslog runc scale secrets société solr sre systemd tempo timezone tinygo tls virtualenv vitess vue.js wagtail warpfleet yarn accessibilité acme adoptopenjdk agpl akka alerte alertes alerting alibaba amazon-emr amqp anonymisation anthos apache-pulsar ara arduino arrow artefact asgi automation automl awstats banque bastion beam beat bi bme680 bootstrap bounded-context branche brigade browser buildah buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart check checklist chrome ci cilium circuitpython clever-cloud clickhouse cloud-init cloud-native cloud-storage cloudflare clusterip cnab cni cockroachdb code codeurs-en-seine commit confluence conftest consul-connect context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data-engineer data-pipelining data.gouv.fr databricks datacenter date date-scientist ddd debezium debian delta deprek8 desktop devoxx dig distributed-systems dive docker-app docker-hub docker-registry docker-swarm dockerfile dockershim documentdb dog dokcer données-personnelles draft dredd drop-in dsi duckdb duration déploiement développement-du-site e-commerce ebs ec2 elassandra electron elk engineering entreprise ergonomie etcd euclidia event-sourcing faas faisabilité falco falcor feature-policy fedora feed filebeat firebase firefox fish flash flask fleet flink flovea fluentd font formation foundation frenchtech frontend fsync fugue fullstack git-filter-repo github gitignore gitpod glacier glowroot go goaccess google google-cloud-next gpg gpu grep grid géospatial hacker hadoop haproxy harbor hdfs header holt-winters html html5 http httpx hue iaac ibm iiot immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jless jquery jvm jwt k3d k6 k8s k9s kaniko katz kotlin kubeadm kubecon kubectl label laravel leap-second lens letsencrypt libssh linky linter liste-de-diffusion lmap loadbalancer logstash logstatsh loi loki lstm mailing-list management matomo maturité mesh mesos message metallb micro-service minio mot-de-passe multi-cloud médecine métrique n8n nebula network newsletter nodejs nodeport notebook notifications nrtsearch null numérique object-storage observability observabilité opa opendata openmetrics openshit openstack openweb opnsense over-engineering packaging partiql password persistent-volume-claim pico pilotage pipenv pivot pod portainer portworx prediction prescience privacy-shield production promql prophet prévision psp ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quay queue quic ram rambleed raml react readme recaptcha recherche redistimeseries reindex reinvent reliability remote-execution repository responsive retention-policy revocation revue-de-code rexec rhel rkt robotframework rolespec root rpo rto rust rwd réseau résultat safe-harbor sarima scalabilité scanner schema scp sdk search select semiconducteur serverless-architecture service service-account service-worker setuptools sftp sha1 shard shard-duration shard-group sharding shell shipyard sidecar singer socket souveraineté-numérique spectre spinnaker spécifications sqlite sri ssh-agent ssl stabilité stash statistique stm32 storage sudo superset suse sympa sysdig syslog-ng sérénité task tavern template terracost terrascan test-unitaire thingspeak tidb tiers time timecale timer timestream training transformation travail trésorerie tsfel tsfr tsl ubuntu unikernel unit ux velero vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc vpn wasm web workflow yaml yield yq yubikey zip