InfluxDB : Migration vers la version 2, procédure

Introduction

Un précédent article, publié en février 2020, portait sur "InfluxDB v2, prise en main. Préparation de la migration de la version 1.7".

InfluxDB v2 était dans sa phase beta dans cet article. InfluxDB v2 est sorti officiellement en novembre 2020. C’est l’heure de migrer depuis la version 1.8.

Avant de migrer, résumons.

À propos de la stack TICK (Telegraf - InfluxDB - Chronograf - Kapacitor) : dans la version 2, Chronograf et Kapacitor sont intégrés dans InfluxDB, seul Telegraf demeure un composant à part entière.

Dans cet article, une migration est effectuée d’InfluxDB v1.8 vers InfluxDB v2. Le serveur InfluxDB est installé sur Ubuntu 18.04.

Les changements majeurs à noter :

• Une base de données/politique de rétention est un bucket dans la version 2. Une organisation est obligatoire et initialisée à l’upgrade.

  

• Le langage Flux remplace InfluxQL (SQL-Like).
• Les Continuous queries doivent être migrées en tâches Flux.
• Les protocoles Opentsdb/Graphite/Collectd ne sont plus supportés nativement par le moteur InfluxDB, Telegraf doit être utilisé pour alimenter InfluxDB.
• La rétro-compatibilité ou Backward compatibility pour les users 1.x existants (requêtes InfluxQL, Kapacitor Tickscripts…) est garantie dans InfluxDB v2 si et seulement si l’authentification est activée pour ces utilisateurs (username/password).

Mesures et series, rappels rapides

Dans la base de données time series InfluxDB, le format d’un point est le suivant :

measurement[,tag=value[,tag=value]] field=value[,field=value] [<timestamp>]
cpu_measurement,location=france,host=vpsfrsqlpac1 value=25.08,desc="influx" 1580918550000000000
cpu_measurement,location=germany,host=vpsfrsqlpac2 value=76.07,desc="postgres" 1580918550000000000

Les séries sont les combinaisons mesure/tag keys possibles :

measurement, tag key1=value1, tag key2=value2 [,...]
cpu_measurement,location=france,host=vpsfrsqlpac1
cpu_measurement,location=germany,host=vpsfrsqlpac2

• Les données sont écrasées si le point existe déjà.
• Le timestamp du serveur est utilisé si il est omis.
• Le type de données peut être forcé à l’écriture du premier point : value=25i pour un entier, statut=t|f pour un booléen.

Le serveur InfluxDB 1.8 à migrer vers la version 2

La distribution InfluxDB v 1.8 est installée sur Ubuntu dans le répertoire /opt/influxdb/influxdb-1.8. Le serveur InfluxDB v1.8 à migrer est démarré avec le user influxdb (uid : 10000, gid : 10000) et la ligne de commande ci-dessous :

/opt/influxdb/influxdb-1.8/usr/bin/influxd  \
      -config /opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf \
      -pidfile /opt/influxdb/dba/srvifxsqlpac/run/srvifxsqlpac.pid

• HTTPS est activé (certificat self-signed). InfluxDB écoute à l’adresse https://vpsfrsqlpac:8086.

  influxdb$ export INFLUX_USERNAME=dba
  influxdb$ export INFLUX_PASSWORD=****************
              
  influxdb$ influx -ssl -host vpsfrsqlpac
  Connected to https://vpsfrsqlpac:8086 version 1.8.3
  InfluxDB shell version: 1.8.3 >
  SHOW DATABASES;
  name: databases
  name
  ----
  _internal
  netdatatsdb
  telegraf
  aggtsdb
  SHOW USERS;
  user     admin
  ----     -----
  dba      true
  netdata  false
  grafana  false
  telegraf false
  SHOW GRANTS FOR netdata;
  database    privilege
  --------    ---------
  aggtsdb     ALL PRIVILEGES
  netdatatsdb ALL PRIVILEGES
  SHOW GRANTS FOR grafana;
  database    privilege
  --------    ---------
  netdatatsdb READ
  aggtsdb     READ

• Les bases de données du serveur (metadata + data + wal) sont dans le répertoire /sqlpac/influxdb/srvifxsqlpac.
• Des Continuous queries existent.
• Le langage Flux est activé.
• Un endpoint opentsdb écoute sur le port 4242. Netdata (outil de collecte de métriques de performance) envoie les données via cet endpoint avec le protocole OpenTSDB.
• L’outil de reporting Grafana se connecte au serveur InfluxDB avec le user grafana, compte en lecture seule dans la base de données netdatatsdb.

Dans le fichier de configuration :

/opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf

[meta]
  dir = "/sqlpac/influxdb/srvifxsqlpac/meta"
  retention-autocreate = true

[data]
  dir = "/sqlpac/influxdb/srvifxsqlpac/data"
  wal-dir = "/sqlpac/influxdb/srvifxsqlpac/wal"

[http]
  bind-address = "vpsfrsqlpac:8086"
  auth-enabled = true
  
  https-enabled = true
  https-certificate = "/var/ssl/VPSFRSQLPAC.crt"
  https-private-key = "/var/ssl/VPSFRSQLPAC.key"

  flux-enabled = true
  flux-log-enabled = true

[continuous_queries]
  enabled = true
  log-enabled = true
  query-stats-enabled = false
  run-interval = "60s"
  
[[opentsdb]]
  enabled = true
  bind-address = ":4242"
  database = "netdatatsdb"

Vérification d’InfluxDB v1 pour l’upgrade, auth-enabled

InfluxDB 2.0 nécessite une authentification et ne prend pas en charge l’option de configuration auth-enabled = false d’InfluxDB v1.

Seuls les users 1.x avec "credentials" (username/password) sont migrés vers InfluxDB v2 et note importante : les users admin ne sont pas migrés.

Redémarrer le serveur InfluxDB avec l’option de configuration auth-enabled à true et migrer les outils existants, sources de données… vers des users authentifiés non admin, sinon les requêtes (InfluxQL…) seront silencieusement ignorées dans InfluxDB v2.

/opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf

[http]
auth-enabled=true

Chemin de migration

Le chemin de migration est le suivant :

• Les données sont migrées vers InfluxDB v2 dans le répertoire /sqlpac/influxdb/srvifx2sqlpac.
• La base de données bolt est également installée dans le répertoire /sqlpac/influxdb/srvifx2sqlpac. La base bolt est nouvelle dans la version 2, cette base de données key/value stocke les métadonnées (dashboards, permissions, tâches,…).
• Les Continuous queries sont migrées en tâches Flux (à préparer en avance si possible).
• Le port opentsdb est remplacé par Telegraf.

Migration vers InfluxDB v2

Étape 1 : Installation d’InfluxDB v2

InfluxDB 2.0.3 est installé dans le répertoire /opt/influxdb/influxdb-2.0, ce répertoire contient seulement les exécutables influx (client) et influxd (serveur influxd). Il est ajouté dans la variable $PATH :

influxdb$ export PATH=/opt/influxdb/influxdb-2.0:$PATH

Avant de migrer, lancer influxd upgrade --help pour obtenir une description complète de l’option upgrade :

influxdb$ influxd upgrade --help

L’upgrade réalisera les étapes suivantes :

1. Lecture du fichier de config 1.x et création d’un fichier de config 2.x avec les options correspondantes. Les options 1.x non supportées sont remontées.
2. Copie des fichiers de bases de données 1.x.
3. Création des configurations influx CLI.
4. Export des Continuous queries 1.x dans un fichier.

L’espace disponible est vérifié avant l’upgrade.

Vérifier que la version utilisée est à présent la v2 :

influxdb$ influxd version
InfluxDB 2.0.3 (git: fe04d346df) build_date: 2020-12-15T01:00:16Z

Étape 2 : Arrêt et sauvegarde des bases de données du serveur InfluxDB v1

Arrêter le serveur InfluxDB v1 et sauvegarder toutes les données 1.x :

influxdb$ ps -ef | grep 'bin/influxd'
influxdb 18824     1  1 01:28 pts/2    00:00:18 /opt/influxdb/influxdb-1.8/usr/bin/influxd
           -pidfile /opt/influxdb/dba/srvifxsqlpac/run/srvifxsqlpac.pid
           -config /opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf        
influxdb$ kill -s TERM 18824

influxdb$ cd /sqlpac/influxdb
influxdb$ cp -R srvifxsqlpac srvifxsqlpac_backup

Étape 3 : Préparation de la ligne de commande de migration

influxdb$ influxd upgrade \
            --bolt-path="/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt" \
            --engine-path="/sqlpac/influxdb/srvifx2sqlpac" \
            --config-file="/opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf" \
            --continuous-query-export-path="/opt/influxdb/dba/srvifx2sqlpac/scripts/cs.sql" \
            --influx-configs-path="/sqlpac/influxdb/srvifx2sqlpac/configs" \
            --v2-config-path="/opt/influxdb/dba/srvifx2sqlpac/cfg/srvifx2sqlpac.toml" \
            --log-path="/opt/influxdb/dba/srvifx2sqlpac/log/upgrade.log" \
            --bucket="masterts" \
            --org="sqlpac" \
            --username="dba" \
            --password="************"

Dans la ligne de commande ci-dessus :

Le paramètre --v1-dir spécifie le chemin vers les bases de données 1.x source (sous répertoires meta, data et wal) mais il n’est pas nécessaire si le paramètre --config-file est donné, ils s’excluent mutuellement :

Error: only one of --v1-dir or --config-file may be specified

Supprimer tout fichier déjà généré par une migration précédente en échec (fichiers de bases de données, *.toml…). Si un fichier existe déjà, une erreur est levée et la migration n’est pas réalisée :

Error: file present at target path for exported continuous queries '/opt/influxdb/dba/srvifx2sqlpac/scripts/cs.sql'
Error: upgraded 2.x engine directory '/sqlpac/influxdb/srvifx2sqlpac' must be empty

Quand la migration démarre (la sortie est allégée par souci de concision) :

"upgrade/upgrade.go:376","msg":"Starting InfluxDB 1.x upgrade"
"upgrade/upgrade.go:379","msg":"Upgrading config file","file":"/opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf"
"upgrade/upgrade.go:383","msg":"Config file upgraded.","1.x config":"/opt/influxdb/dba/srvifxsqlpac/cfg/srvifxsqlpac.conf","2.x config":"/opt/influxdb/dba/srvifx2sqlpac/cfg/srvifx2sqlpac.toml"
"upgrade/upgrade.go:393","msg":"Upgrade source paths","meta":"/sqlpac/influxdb/srvifxsqlpac/meta","data":"/sqlpac/influxdb/srvifxsqlpac/data"
"upgrade/upgrade.go:394","msg":"Upgrade target paths","bolt":"/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt","engine":"/sqlpac/influxdb/srvifx2sqlpac"
"bolt/bbolt.go:67","msg":"Resources opened","service":"bolt","path":"/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt"
…
"migration/migration.go:241","msg":"Migration \"Create TSM metadata buckets\" started (up)","service":"migrations"
…
Welcome to InfluxDB 2.0 upgrade!
Please type your retention period in hours.
Or press ENTER for infinite.:

You have entered:
  Username:          dba
  Organization:      sqlpac
  Bucket:            masterts
  Retention Period:  infinite
Confirm? (y/n): y

Une période de rétention infinie par défaut est choisie. La mise à niveau effective démarre.

"upgrade/setup.go:154","msg":"CLI config has been stored.","path":"/sqlpac/influxdb/srvifx2sqlpac/configs"
"upgrade/database.go:37","msg":"Checking space"
"upgrade/database.go:53","msg":"Disk space info","Free space":"4.0 GB","Requested space":"466 MB"
"upgrade/database.go:67","msg":"Upgrading databases"
"upgrade/database.go:75","msg":"Skipping _internal "
…
"upgrade/database.go:80","msg":"Upgrading database ","database":"netdatatsdb"}
"upgrade/database.go:99","msg":"Creating bucket ","Bucket":"netdatatsdb/autogen"}
"upgrade/database.go:110","msg":"Creating database with retention policy","database":"dd2b762103a1d94c"}
"upgrade/database.go:128","msg":"Creating mapping","database":"netdatatsdb","retention policy":"autogen","orgID":"4dec7e867866cc2f","bucketID":"dd2b762103a1d94c"}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1577059200}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1578268800}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1578873600}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1579478400}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1580688000}
"upgrade/database.go:141","msg":"Creating shard group","database":"dd2b762103a1d94c","retention policy":"autogen","time":1581292800}
"upgrade/database.go:156","msg":"Copying data","source":"/sqlpac/influxdb/srvifxsqlpac/data/netdatatsdb/autogen","target":"/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen"}
"upgrade/database.go:171","msg":"Copying wal","source":"/sqlpac/influxdb/srvifxsqlpac/wal/netdatatsdb/autogen","target":"/sqlpac/influxdb/srvifx2sqlpac/wal/dd2b762103a1d94c/autogen"}
"upgrade/database.go:208","msg":"Exporting CQ","db":"netdatatsdb","cq_name":"cq_metrics"}
…
"upgrade/database.go:80","msg":"Upgrading database ","database":"telegraf"}
"upgrade/database.go:99","msg":"Creating bucket ","Bucket":"telegraf/rp72h"}
"upgrade/database.go:110","msg":"Creating database with retention policy","database":"7538d4ef709d1715"}
"upgrade/database.go:128","msg":"Creating mapping","database":"telegraf","retention policy":"rp72h","orgID":"4dec7e867866cc2f","bucketID":"7538d4ef709d1715"}
…
"upgrade/security.go:48","msg":"User is admin and will not be upgraded.","username":"dba"}
"upgrade/security.go:105","msg":"User upgraded.","username":"grafana"}
"upgrade/security.go:105","msg":"User upgraded.","username":"netdata"}
"upgrade/upgrade.go:463","msg":"Upgrade successfully completed. Start the influxd service now, then log in","login_url":"https://vpsfrsqlpac:8086"}

Démarrage du serveur InfluxDB v2

Les bases de données sont maintenant migrées. Le fichier de configuration srvifx2sqlpac.toml créé avec le paramètre --v2-config-path durant l’upgrade contient les informations essentielles (chemin de la base de données bolt, répertoire des bases de données, addresse…). Les paramètres HTTPS/SSL sont également copiés de la configuration v1 et définis.

/opt/influxdb/dba/srvifx2sqlpac/cfg/srvifx2sqlpac.toml

bolt-path = "/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt"
engine-path = "/sqlpac/influxdb/srvifx2sqlpac"
http-bind-address = "vpsfrsqlpac:8086"
storage-series-id-set-cache-size = 100
tls-cert = "/var/ssl/VPSFRSQLPAC.crt"
tls-key = "/var/ssl/VPSFRSQLPAC.key"

Pour démarrer le serveur InfluxDB v2, définir la variable INFLUXD_CONFIG_PATH (fichier de configuration du serveur v2) et lancer influxd avec l’option run :

influxdb$ export INFLUXD_CONFIG_PATH=/opt/influxdb/dba/srvifx2sqlpac/cfg/srvifx2sqlpac.toml
        
influxdb$ nohup influxd run >> /opt/influxdb/dba/srvifx2sqlpac/log/srvifx2sqlpac.log 2>&1 &

$LOG/srvifx2sqlpac.log

ts=2021-01-29T08:12:21.185163Z lvl=info msg="Welcome to InfluxDB" log_id=0S1VoPlG000 version=2.0.3 commit=fe04d346df build_date=2020-12-15T01:00:16Z
ts=2021-01-29T08:12:21.186172Z lvl=info msg="Resources opened" log_id=0S1VoPlG000 service=bolt path=/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt
ts=2021-01-29T08:12:21.194448Z lvl=info msg="Checking InfluxDB metadata for prior version." log_id=0S1VoPlG000 bolt_path=/sqlpac/influxdb/srvifx2sqlpac/srvifxs2qlpac.bolt
ts=2021-01-29T08:12:21.194543Z lvl=info msg="Using data dir" log_id=0S1VoPlG000 service=storage-engine path=/sqlpac/influxdb/srvifx2sqlpac/data
ts=2021-01-29T08:12:21.194607Z lvl=info msg="Compaction settings" log_id=0S1VoPlG000 service=storage-engine max_concurrent_compactions=1 throughput_bytes_per_second=50331648 throughput_bytes_per_second_burst=50331648
ts=2021-01-29T08:12:21.194620Z lvl=info msg="Open store (start)" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open op_event=start
ts=2021-01-29T08:12:21.603908Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/75 duration=395.206ms
ts=2021-01-29T08:12:21.620382Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/15 duration=16.413ms
ts=2021-01-29T08:12:21.653303Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/22 duration=32.865ms
ts=2021-01-29T08:12:21.696091Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/26 duration=41.242ms
ts=2021-01-29T08:12:21.724205Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/47 duration=28.064ms
ts=2021-01-29T08:12:21.744825Z lvl=info msg="Opened shard" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open index_version=inmem path=/sqlpac/influxdb/srvifx2sqlpac/data/dd2b762103a1d94c/autogen/58 duration=20.583ms
ts=2021-01-29T08:12:21.745069Z lvl=info msg="Open store (end)" log_id=0S1VoPlG000 service=storage-engine op_name=tsdb_open op_event=end op_elapsed=550.449ms
ts=2021-01-29T08:12:21.745094Z lvl=info msg="Starting retention policy enforcement service" log_id=0S1VoPlG000 service=retention check_interval=30m
ts=2021-01-29T08:12:21.745111Z lvl=info msg="Starting precreation service" log_id=0S1VoPlG000 service=shard-precreation check_interval=10m advance_period=30m
ts=2021-01-29T08:12:21.745165Z lvl=info msg="Starting query controller" log_id=0S1VoPlG000 service=storage-reads concurrency_quota=10 initial_memory_bytes_quota_per_query=9223372036854775807 memory_bytes_quota_per_query=9223372036854775807 max_memory_bytes=0 queue_size=10
ts=2021-01-29T08:12:21.745699Z lvl=info msg="Configuring InfluxQL statement executor (zeros indicate unlimited)." log_id=0S1VoPlG000 max_select_point=0 max_select_series=0 max_select_buckets=0
ts=2021-01-29T08:12:22.039074Z lvl=info msg=Starting log_id=0S1VoPlG000 service=telemetry interval=8h
ts=2021-01-29T08:12:22.039344Z lvl=info msg=Listening log_id=0S1VoPlG000 transport=https addr=vpsfrsqlpac2:8086 port=8086

Lancer influx ping pour vérifier la connectivité :

influxdb$ influx ping --host https://vpsfrsqlpac:8086
OK

Connexion et lancements de commandes avec le client influx

Le token de l’admin (dba) est alors stocké dans le fichier /sqlpac/influxdb/srvifx2sqlpac/configs, section default, fichier créé durant la migration (--influx-configs-path) :

/sqlpac/influxdb/srvifx2sqlpac/configs

[default]
  url = "https://vpsfrsqlpac:8086"
  token = "K2YXbGhIJIjVhL_FjmDN_Dl3CdOIgAPi4CwHhp6SrSFOEvfm62ziYOZ15W4kySH7dc6Hlx0BhBKRvH9IXgja6g=="
  org = "sqlpac"
  active = true

Définir la variable $INFLUX_CONFIGS_PATH (chemin du fichier configs) et la variable $INFLUX_ACTIVE_NAME (nom de la section) :

influxdb$ export INFLUX_CONFIGS_PATH=/sqlpac/influxdb/srvifx2sqlpac/configs
influxdb$ export INFLUX_ACTIVE_NAME=default

Les commandes du client influx requièrent --host si localhost (par défaut) n’est pas utilisé, définir la variable $INFLUX_HOST, cela évitera de répéter le paramètre --host :

influxdb$ export INFLUX_HOST=https://vpsfrsqlpac:8086

Les commandes d’admin sont alors autorisées (buckets, users, authorizations, tasks…) avec le client influx :

influxdb$ influx bucket list --org sqlpac
        ID                      Name                            Retention       Organization ID
a67ea95f68df447c        _monitoring             168h0m0s        4dec7e867866cc2f
e6b47fdfbbe80d57        _tasks                  72h0m0s         4dec7e867866cc2f
18c073a588127f79        masterts                0s              4dec7e867866cc2f
dd2b762103a1d94c        netdatatsdb/autogen     0s              4dec7e867866cc2f
7538d4ef709d1715        telegraf/rp72h          72h0m0s         4dec7e867866cc2f

influxdb$ influx auth list
ID                  Description     Token        User Name    User ID             Permissions
06f9d7a7c0856000    dba's Token     nDWNhwb…     dba          06f9d7a7a1856000    [read:authorizations write:authorizations
                                                                                   read:buckets write:buckets
                                                                                   read:dashboards write:dashboards…]

Pour utiliser l’outil graphique (Chronograf, …), lancer tout d’abord influx user password pour initialiser un mot de passe pour le compte admin (dba) :

influxdb$ influx user password --name dba
Please type your new password:
…

Le GUI est disponible à l’adresse http(s)://<host>:8086 : https://vpsfrsqlpac:8086 dans ce cas pratique.

Maintenant que Chronograf est intégré, la construction de requêtes, plus particulièrement avec le langage Flux, est plus aisé, influx query en ligne de commandes est trop peu pratique :

Pour apprendre le langage Flux, les 2 publications ci-dessous peuvent aider :

• SQLPAC - InfluxDB v2 : langage Flux, aide-mémoire
• SQLPAC - InfluxDB, Passer du langage InfluxQL au langage Flux

Étapes post migration

Users

influxd upgrade migre les users 1.x et leurs permissions, mais pas les admin users.

Pour vérifier la migration des users 1.x et permissions, utiliser influx v1 auth list :

influxdb$ influx v1 auth list

ID        Description  Name / Token    User Name       User ID     Permissions
07017e…   …            grafana         dba             07017e…     [read:orgs/4dec7e867866cc2f/buckets/dd2b762103a1d94c]
07017e…   …            netdata         dba             07017e…     [read:orgs/4dec7e867866cc2f/buckets/dd2b762103a1d94c
                                                                    write:orgs/4dec7e867866cc2f/buckets/dd2b762103a1d94c]

influxdb$ influx bucket list
ID                      Name                    Retention       Organization ID
a67ea95f68df447c        _monitoring             168h0m0s        4dec7e867866cc2f
e6b47fdfbbe80d57        _tasks                  72h0m0s         4dec7e867866cc2f
18c073a588127f79        masterts                0s              4dec7e867866cc2f
dd2b762103a1d94c        netdatatsdb/autogen     0s              4dec7e867866cc2f
7538d4ef709d1715        telegraf/rp72h          72h0m0s         4dec7e867866cc2f

La rétro-compatibilité (Backward compatibility) est assurée. Le user grafana utilisé par Grafana est migré : le compte se connecte bien au serveur v2 et peut lancer les requêtes InfluxQL définies dans les dashboards Grafana.

Les permissions peuvent être gérées avec influx v1 auth [create|delete|set-active…], mais garder à l’esprit qu’avec l’option v1, seules les permissions read/write sur les buckets peuvent être définies. La gestion complète des permissions (buckets, tasks, endpoints, dashboards…) est disponible uniquement pour les users v2 créés avec les commandes influx user et influx auth.

Migration des Continuous queries en tâches Flux

Malheureusement, les continuous queries ne sont pas facilement migrées et doivent être converties manuellement en tâches Flux. Ce travail devrait être préparé avant la migration. Le code source des Continuous queries est sauvegardé dans le fichier spécifié par le paramètre --continuous-query-export-path lors du lancement de la migration (influxd upgrade).

/opt/influxdb/dba/srvifx2sqlpac/scripts/cs.sql

name: netdatatsdb
name                query
----                -----
cq_metrics CREATE CONTINUOUS QUERY cq_metrics ON netdatatsdb BEGIN SELECT mean(value) INTO netdatatsdb.autogen.backend_metrics FROM netdatatsdb.autogen."netdata.netdata.backend_metrics.sent" GROUP BY time(2m) fill(0) END

CREATE CONTINUOUS QUERY cq_metrics
ON netdatatsdb
BEGIN
 SELECT mean(value)
 INTO netdatatsdb.autogen.backend_metrics
 FROM netdatatsdb.autogen."netdata.netdata.backend_metrics.sent"
 GROUP BY time(2m)
 fill(0)
END

cq_metrics.flux

option task = {name: "cq_metrics", every: 2m}

data = from(bucket: "netdatatsdb/autogen")
 |> range(start: -task.every)
 |> filter(fn: (r) =>
	(r._measurement == "netdata.netdata.backend_metrics.sent"))
 |> aggregateWindow(every: 2m, fn: mean)
 |> fill(column: "_value", value: 0.0)
 |> set(key: "_measurement", value: "backend_metrics")
 |> to(bucket: "netdatatsdb/autogen")

Pour compiler la tâche, utiliser l’interface graphique ou le client influx :

influxdb$ influx task create --file cq_metrics.flux
ID                      Name            Organization ID         Organization    Status  Every   Cron
07018ed278d19000        cq_metrics      4dec7e867866cc2f        sqlpac          active  2m

Les logs des tâches sont disponibles dans l’interface graphique. Également disponibles avec le client influx en lignes de commandes, mais moins pratique :

influxdb$ influx task run list --task-id 07018ed278d19000

ID                  TaskID              Status   ScheduledFor            StartedAt                       FinishedAt                      RequestedAt
07019b0e30119000    07018ed278d19000    success  2021-01-29T11:14:00Z    2021-01-29T11:14:00.003607793Z  2021-01-29T11:14:00.026414732Z  0001-01-01T00:00:00Z
07019a9900119000    07018ed278d19000    success  2021-01-29T11:12:00Z    2021-01-29T11:12:00.003733373Z  2021-01-29T11:12:00.020218332Z  0001-01-01T00:00:00Z

Migration OpenTSDB vers Telegraf

Le support natif des protocoles OpenTSDB, Graphite, CollectD, UDP est supprimé dans la version 2. Un agent Telegraf doit être mis en place entre l’application et le serveur InfluxDB v2 pour gérer ces architectures.

Dans ce cas pratique, Netdata envoie ses métriques avec le protocole OpenTSDB vers le serveur InfluxDB version 1.8 / port 4242 :

netdata.conf

[backend]
        # host tags =
        enabled = yes
        data source = average
        type = opentsdb
        destination = tcp:vpsfrsqlpac:4242
        …

Les métriques sont envoyées avec la syntaxe OpenTSDB suivante :

put netdata.users.sockets.daemon 1579463790 0.0000000 host=vpsfrsqlpac1

Malheureusement, Telegraf ne dispose pas de plugin d’entrée (input plugin) pour OpenTSDB, seulement un plugin de sortie (output plugin), mauvaise nouvelle… Mais Netdata peut aussi envoyer les métriques avec le protocol Graphite et Telegraf supporte le format de données Graphite avec l’input plugin socket_listener.

Dans l’architecture cible, Netdata pousse les métriques au format Graphite à un agent Telegraf écoutant sur le port 14001.

Telegraf 1.17.1 est installé dans le répertoire /opt/influxdb/telegraf-1.17 et le fichier de configuration de l’agent est préparé (tgf_netdata.conf) :

• Input plugin : socket_listener
• Output plugin : influxdb_v2

influxdb$ telegraf --input-filter socket_listener --output-filter influxdb_v2 config > $TGF_CFG/tgf_netdata.conf

tgf_netdata.conf

[agent]
  omit_hostname = true
  
[[inputs.socket_listener]]
  service_address = "tcp://:14001"
  data_format = "graphite"

  templates = [
        "measurement.host.measurement*"
  ]
        
[[outputs.influxdb_v2]]
 urls = ["https://vpsfrsqlpac:8086"]
 token = "K2YXbGhIJIjVhL_FjmDN_Dl3CdOIgAPi4CwHhp6SrSFOEvfm62ziYOZ15W4kySH7dc6Hlx0BhBKRvH9IXgja6g=="
 organization = "sqlpac"
 bucket = "netdatatsdb/autogen"
 insecure_skip_verify = true

• Dans la configuration générale [agent], le paramètre omit_hostname est défini à true, sinon le tag host est automatiquement ajouté par l’agent Telegraf, écrasant le tag host envoyé par NetData.
• Le plugin d’input est configuré : port 14001 et format de données Graphite. Un template est appliqué ("measurement.host.measurement*"), en effet quand NetData envoie les données au format graphite, le format est le suivant :

  netdata.vpsfrsqlpac1.users.cpu.postgres 0.0000000 1579463970

  Mais on veut le host en tag (host=vpsfrsqlpac1) et non défini dans le nom de la mesure :

  netdata.users.cpu.postgres,host=vpsfrsqlpac1 0.0000000 1579463970

• Dans la configuration de sortie vers InfluxDB v2, ne pas oublier l’option insecure_skip_verify à true si https est implémenté avec des certificats auto-signés sans autorité de certificats. L’url, le token, l’organisation et le bucket sont donnés. Le token utilisé ici est le token de l’admin (dba), un autre user avec moins de privileges est bien entendu préférable.

La configuration Netdata est donc modifiée pour définir le format des données au format graphite et basculer sur le port de l’agent Telegraf :

netdata.conf

[backend]
        enabled = yes
        data source = average
        type = graphite
        destination = tcp:vpsfrsqlpac:14001
        …

L’agent Telegraf est démarré et le serveur NetData redémarré :

influxdb% nohup telegraf --config $TGF_CFG/tgf_netdata.conf \
                   --debug >> $TGF_LOG/tgf_netdata.log 2>&1 &

Quand tout est correctement défini :

2021-01-28T09:11:37Z I! Loaded processors:
2021-01-28T09:11:37Z I! Loaded outputs: influxdb_v2
2021-01-28T09:11:37Z I! Tags enabled:
2021-01-28T09:11:37Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:"", Flush Interval:10s
2021-01-28T09:11:37Z D! [agent] Initializing plugins
2021-01-28T09:11:37Z D! [agent] Connecting outputs
2021-01-28T09:11:37Z D! [agent] Attempting connection to [outputs.influxdb_v2]
2021-01-28T09:11:37Z D! [agent] Successfully connected to outputs.influxdb_v2
2021-01-28T09:11:37Z D! [agent] Starting service inputs
2021-01-28T09:11:37Z I! [inputs.socket_listener] Listening on tcp://[::]:14001
2021-01-28T09:11:46Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 167.920781ms
2021-01-28T09:11:46Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 14.633634ms
2021-01-28T09:11:46Z D! [outputs.influxdb_v2] Buffer fullness: 6000 / 10000 metrics
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 17.831348ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 15.655119ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 13.539954ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 17.757401ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 46.331055ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Wrote batch of 1000 metrics in 33.348918ms
2021-01-28T09:11:47Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics

Requêtes InfluxQL, endpoint /query

Le point de terminaison (endpoint) /query garantit la rétro-compatibilité pour les requêtes InfluxQL 1.x :

curl --request POST https://vpsfrsqlpac:8086/query \
 --user "netdata:********" \
 --header "Accept: application/csv" \
 --data-urlencode "db=netdatatsdb" \
 --data-urlencode "rp=autogen" \
 --data-urlencode "q=SELECT mean(value) FROM netdatatsdb.autogen.backend_metrics WHERE time >= now() - 1w GROUP BY time(5m) FILL(none)"
name,tags,time,mean
backend_metrics,,1612060200000000000,1347.2222222222224
backend_metrics,,1612061100000000000,1352.6666666666667
backend_metrics,,1612062000000000000,1355.8333333333333
…

Ajouter l’option --insecure pour des certificats auto-signés sans autorité de certificats.

Dans l’exemple ci-dessus, un user 1.x est utilisé : bien entendu un token d’un user v2 peut être utilisé :

curl --request POST https://vpsfrsqlpac:8086/query \
 --header "Authorization: Token K2YXbGhIJIjVhL_FjmDN_Dl3CdOIgAPi4CwHhp6SrSFOEvfm62ziYOZ15W4kySH7dc6Hlx0BhBKRvH9IXgja6g==" \
 --header "Accept: application/csv" \
 --data-urlencode "db=netdatatsdb" \
 --data-urlencode "rp=autogen" \
 --data-urlencode "q=SELECT mean(value) FROM netdatatsdb.autogen.backend_metrics WHERE time >= now() - 1w GROUP BY time(5m) FILL(none)"
name,tags,time,mean
backend_metrics,,1612060200000000000,1347.2222222222224
backend_metrics,,1612061100000000000,1352.6666666666667
backend_metrics,,1612062000000000000,1355.8333333333333
…

On pourrait conclure immédiatement : pour utiliser les commandes InfluxQL 1.x (SHOW MEASUREMENTS, SHOW SERIES…), doit-on utiliser curl et des requêtes HTTP vers /query ?

Temporairement, oui, mais les commandes InfluxQL SHOW seront probablement retirées dans de futures versions. Le package schema d’InfluxDB v2 devrait être utilisé à la place, ce sujet est abordé dans une prochaine section (Explorer les schémas).

L’option transpile du client influx traduit les requêtes InfluxQL en syntaxe Flux, pas complètement fiable mais un bon outil de départ pour les débutants dans le langage Flux et démarrer la migration du code InfluxQL vers Flux :

influxdb$ influx transpile \
           'SELECT mean(value) FROM netdatatsdb.autogen.backend_metrics WHERE time >= now() - 1w GROUP BY time(15m) FILL(none)'
package main
from(bucket: "netdatatsdb/autogen")
        |> range(start: 2021-01-22T10:34:54.39766715Z, stop: 2021-02-29T10:34:54.39766715Z)
        |> filter(fn: (r) =>
                (r._measurement == "backend_metrics" and r._field == "value"))
        |> group(columns: ["_measurement", "_start", "_stop", "_field"], mode: "by")
        |> keep(columns: ["_measurement", "_start", "_stop", "_field", "_time", "_value"])
        |> window(every: 15m)
        |> mean()
        |> map(fn: (r) =>
                ({r with _time: r._start}))
        |> window(every: inf)
        |> rename(columns: {_value: "mean"})
        |> yield(name: "0")

Écrire des données

Protocole ligne InfluxDB

À propos du protocole ligne InfluxDB, pas de changements dans la version 2, le format demeure le même. L’instruction InfluxQL INSERT est remplacée par la ligne de commande influx write pour écrire des points :

influxdb$ influx write --bucket=telegraf/rp72h \
                       --precision s 'customMeasure,host=vpsfrsqlpac1 cpupct=23.4,slot=1i,isdefault=true 1581321757' 

• Le timestamp du serveur est utilisé si il est omis dans la ligne.
• Le type Integer au lieu du type Float est forcé en ajoutant i après la valeur lors de l’insertion du premier point. Le suffixe u est utilisé pour spécifié des unsigned integers.
• Le type Boolean est appliqué en écrivant t|true ouf|false sans quotes ou double quotes lors de l’insertion du premier point.

Appliquer le bon type de données renforce l’intégrité des données et réduit la consommation mémoire et l’espace de stockage.

Error: Failed to write data: unexpected error writing points to database: partial write: series type mismatch: already Integer but got Float dropped=1.

endpoint /write

Le endpoint /write, comme le endpoint /query, est disponible pour les écritures pour rétro compatibilité avec les API 1.x :

curl \
  --request POST "https://vpsfrsqlpac:8086/write?db=telegraf&rp=rp72h" \
  --user "telegraf:**********" \
  --data-binary "measurement,host=host1 field1=2i,field2=2.0 1577836800000000000"

curl \
  --request POST "https://vpsfrsqlpac:8086/write?db=telegraf&rp=rp72h" \
  --header "Authorization: Token K2YXbGhIJIjVhL_FjmDN_Dl3CdOIgAPi4CwHhp6SrSFOEvfm62ziYOZ15W4kySH7dc6Hlx0BhBKRvH9IXgja6g==" \
  --data-binary "measurement,host=host1 field1=2i,field2=2.0 1577836800000000000"

Ajouter l’option --insecure pour des certificats auto-signés sans autorité de certificats.

Chargements en masse (Bulk loads)

Dans InfluxDB v2, les chargements en masse depuis des fichiers CSV sont maintenant réalisés en utilisant le package csv (encore expérimental ?) :

• Les formats CSV peuvent être des CSV annotés (Annotated CSVs) ou des protocoles ligne InfluxDB.
• Les sources peuvent être https, file, raw data (données brutes).

Les détails ne sont pas abordés ici, cet article se concentre sur la migration.

import "experimental/csv"

csv.from(file: "/sqlpac/data/netdata_20210128.csv")
  |> to(bucket: "netdatatsdb/autogen", org: "sqlpac")

SELECT INTO, fonction to()

Dans InfluxDB v1.x, les instructions SELECT INTO sont utilisées pour copier des données d’une mesure à une autre.

Avec InfluxDB v2, utiliser la fonction Flux to().

Dans l’exemple ci-dessous, des données calculées à partir de la mesure netdata.netdata.backend_metrics.sent sont écrites dans la mesure backend_metrics_perhour dans le même bucket (netdatatsdb/autogen). Cet exemple est choisi car il y a un manque de documentation sur la façon d’écrire des données dans le même bucket grâce à la fonction set.

from(bucket: "netdatatsdb/autogen")
  |> range(start: -10d)
  |> filter(fn: (r) => r._measurement == "netdata.netdata.backend_metrics.sent")
  |> filter(fn: (r) => r._field == "value")
  |> aggregateWindow(every: 1h, fn: mean)
  |> fill(column: "_value", value: 0.0)
  |> set(key: "_measurement", value: "backend_metrics_perhour")
  |> to(org: "sqlpac", bucket: "netdatatsdb/autogen")

La syntaxe InfluxQL de la requête aurait été :

SELECT mean(value)
INTO netdatatsdb.autogen.backend_metrics_perhour
FROM netdatatsdb.autogen."netdata.netdata.backend_metrics.sent"
WHERE time >= now() - 10d
GROUP BY time(1h) FILL(0)

Supprimer des données

Moins utilisé, mais il est parfois nécessaire de supprimer des données erronées impactant le reporting.

L’instruction InfluxQL DELETE est remplacée par la ligne de commande influx delete :

influxdb$ influx delete --bucket netdatatsdb/autogen \
  --org sqlpac \
  --start '1970-01-01T00:00:00Z' \
  --stop $(date +"%Y-%m-%dT%H:%M:%SZ") \
  --predicate '_measurement="cpu_measurement" AND location="spain"'

Les temps sont donnés avec le format RFC3339 format. Ne pas oublier les prédicats et start/stop.

--predicate '_measurement =~ /^netdata/'
Error: Failed to delete data: invalid request; error parsing request json:
operator: "=~" at position: 13 is not supported yet.

Exploration du schéma

Dans InfluxDB v1, on était habitués d’explorer les métadonnées et schémas avec les commandes SHOW.

Dans InfluxDB v2, des fonctions d’aide dans le packge schema remplacent les fonctionnalités des commandes SHOW, quelques exemples de traductions ci-dessous :

SHOW DATABASES
name
----
netdatatsdb
telegraf
…
SHOW RETENTION POLICIES ON telegraf
name  duration shardGroupDuration replicaN default
----  -------- ------------------ -------- -------
rp72h 72h0m0s  24h0m0s            1        true

buckets()

… name               … retentionPolicy  retentionPeriod
-------------------     ---------------  ----------------
netdatatsdb/autogen  … autogen                         0
telegraf/rp72h       … rp72h             259200000000000
…

SHOW SERIES
key
---
netdata.users.mem.mcs,host=vpsfrsqlpac1
netdata.users.mem.mcs,host=vpsfrsqlpac2
…

import "influxdata/influxdb/schema"

SHOW MEASUREMENTS ON netdatatsdb
name: measurements
name
----
cpu_measurement
netdata.apache_sqlpac.bytesperreq.size
…

schema.measurements(bucket: "netdatatsdb/autogen")
_value
------
cpu_measurement
netdata.apache_sqlpac.bytesperreq.size
…

SHOW MEASUREMENTS ON netdatatsdb
WITH MEASUREMENT =~ /postgres/

schema.measurements(bucket: "netdatatsdb/autogen")
  |> filter(fn: (r) => (r._value =~ /postgres/))

SHOW TAG KEYS ON netdatatsdb
FROM "cpu_measurement"
name: cpu_measurement
tagKey
------
host
location

schema.measurementTagKeys(
  bucket: "netdatatsdb/autogen",
  measurement: "cpu_measurement"
)
host
location

SHOW TAG VALUES ON netdatatsdb
FROM "cpu_measurement"
WITH KEY=location
name: cpu_measurement
key      value
---      -----
location france
location germany

schema.measurementTagValues(
  bucket: "netdatatsdb/autogen",
  measurement: "cpu_measurement",
  tag: "location"
)
_value
------
france
germany

SHOW FIELD KEYS ON netdatatsdb
FROM "cpu_measurement";
name: cpu_measurement
fieldKey    fieldType
--------    ---------
description string
value       float

schema.measurementFieldKeys(
  bucket: "netdatatsdb/autogen",
  measurement: "cpu_measurement"
)
_value
------
description
value

schema.measurementFieldKeys(
  bucket: "netdatatsdb/autogen",
  measurement: "cpu_measurement",
  start: -600d
)

Conclusion

La migration est assez facile. 2 choses à garder à l’esprit : une base de données + politique de rétention devient un bucket dans la version 2 et InfluxQL est remplacé par le langage Flux.

Inconvénients :

• La migration peut prendre du temps en fonction du volume de données à migrer. La disponibilité en espace disque doit être vérifiée avant la copie.
• Les Continuous queries doivent être migrées manuellement en tâches Flux : ce travail est à préparer en avance dans un environnement de test si possible.
• Les users admin ne sont pas migrés, seuls les users authentifiés sont migrés.
• Migration obligatoire vers Telegraf pour remplacer les protocols natifs OpenTSDB, Collectd… d’InfluxDB v1, composant qui ajoute un point d’échec supplémentaire.

Avantages :

• Rétro-compatibilités avec les endpoints /query et /write pour les outils existants (Grafana…) utilisant des users 1.x authentifiés (requêtes InfluxQL, scripts TickScript).
• Chronograf et Kapacitor sont intégrés dans InfluxDB v2.
• Tâches Flux et nouvelles fonctionnalités avec le langage Flux (join, pivot, packages, sql.from et beaucoup d’autres…).

Les outils existants peuvent dès lors être migrés en douceur vers InfluxDB v2 :

• Migration du langage InfluxQL vers Flux / InfluxDB v2 à partir de Grafana 7.1.
• Kapacitor / scripts TickScript en tâches Flux.