Le Chapril a choisi Grafana comme outil de consultation de données de métrologie, et Influxdb comme format de stockage des données.

Initialement la métrologie est obtenue par une instance Icinga du superviseur.

Pour pouvoir collecter des métriques de services qui ne font pas l'objet de supervision, une base InfluxDB a été ajoutée. Cette base est alimentée par le protocole Collectd. Elle a donc été nommée collectd.

L'injection de données dans cette base est restreinte. Les données doivent être chiffrées (d’où l’installation du paquet Debian libgcrypt20) et un mot de passe doit être défini dans le fichier /etc/influxdb/collectd.auth_file.

La base InfluxDB est configurée comme suit :

/etc/influxdb/influxdb.conf

[[collectd]]
  enabled = true
  bind-address = ":25826"
  database = "collectd"
  security-level = "encrypt"
  auth-file = "/etc/influxdb/collectd.auth_file"

Pour une métrique simple on installe et configure Collectd sur les machines qu’on veut observer. Par défaut on aura des métriques standard (Load, CPU, RAM, network etc.).

apt install --no-install-recommends collectd libgcrypt20

/etc/collectd/collectd.conf.d/influx.conf

LoadPlugin "network"
<Plugin "network">
  <Server "admin.cluster.chapril.org" "25826">
    SecurityLevel "encrypt"
    Username "chaprilvm"
    Password "XXXXXXXXXXXXX"
  </Server>
</Plugin>

On termine en redémarrant le démon :

systemctl restart collectd

Et c'est fini. Reste à jeter un œil dans l’instance Grafana pour voir les jolis graphes classiques. Si on veut ajouter des graphes moins classiques, lire la suite ci-dessous.

Pour tenir compte des fichiers modifier le champ ReportInodes.

/etc/collectd/collectd.conf

<Plugin "df">
  ReportInodes true
</Plugin>

Dans le cas où la VM dispose d’Apache HTTP Server le greffon apache peut être chargé ainsi :

/etc/collectd/collectd.conf.d/apache.conf

LoadPlugin apache
<Plugin "apache">
  <Instance "apachewiki">
    URL "http://localhost/server-status?auto"
  </Instance>
</Plugin>

Une configuration supplémentaire est aussi nécessaire pour le serveur Apache :

ExtendedStatus on
<IfModule mod_status.c>
  <Location /mod_status>
    SetHandler server-status
  </Location>
</IfModule>

Via le greffon exec des scripts de shell peuvent être exécutés.

/etc/collectd/collectd.conf.d/exec.conf

LoadPlugin exec
<Plugin exec>
  # if we want to override default's interval
  # Interval 60
  Exec "www-data:adm" "/usr/local/src/custom_collectd_scripts/test.sh"
  Exec "www-data" "/path/to/another/binary" "arg0" "arg1"
</Plugin>

Exemple de script Bash qui compte le nombre d'utilisateurs UNIX connectés :

/usr/local/src/custom_collectd_scripts/test.sh

HOSTNAME="${COLLECTD_HOSTNAME:-localhost}"
INTERVAL="${COLLECTD_INTERVAL:-60}"
 
while sleep "$INTERVAL"
do
    echo "PUTVAL \"${HOSTNAME}/unixusers/count\" interval=$INTERVAL $(date +%s):$(w | tail -n +3 | wc -l)"
done

Dans la base InfluxDB, la variable s'appellera unixusers_value. La boucle while est une astuce pour éviter de lancer un interpréteur shell à chaque exécution. Se référer à collectd-exec(5).

Penser à installer le paquet libpython3.xx.

Se référer à collectd-python(5).

Le ticket #5466 explique le problème lié au volume des données et la possible solution qui consiste à faire du ré-échantillonage (downsampling), soit la dégradation volontaire de la finesse des données collectées après un certain temps. Par exemple, on souhaite connaître à la minute près l'évolution de la charge du système sur les 7 derniers jours, et au delà, une précision à l'heure est suffisante.

Parmi les requêtes tentées :

CREATE RETENTION POLICY "1week" ON "collectd" DURATION 1w REPLICATION 1 DEFAULT;
CREATE RETENTION POLICY "1month" ON "collectd" DURATION 4w REPLICATION 1;
CREATE RETENTION POLICY "1decade" ON "collectd" DURATION 10y REPLICATION 1;
CREATE CONTINUOUS QUERY "downsample-1month-avg-1h"  ON "collectd" RESAMPLE EVERY 30m FOR 2h BEGIN SELECT mean(*) INTO "collectd"."1month".:MEASUREMENT FROM collectd."1week"./.*/ GROUP BY TIME(1h) END;
CREATE CONTINUOUS QUERY "downsample-1decade-avg-1w" ON "collectd" RESAMPLE EVERY 6h FOR 2w BEGIN SELECT mean(*) INTO "collectd"."1decade".:MEASUREMENT FROM collectd."1week"./.*/ GROUP BY TIME(1w) END;

Où sont stockées les données ?
Quel est le chemin du répertoire sur la VM Agir ?

Dans une base de donnée InfluxDB séparée et nommée collectd sur Admin.

Quelle version d’InfluxDB est installée en 2026 ?
InfluxDB 1.6 ?

Actuellement, Collectd semble sonder toutes les 10 secondes.
Quel volume de données cela va-t-il représenter ?
Est-ce compatible avec l'actuel espace de stockage ?

Aucune idée. À voir comment ça évolue dans le graphe d’essai de Grafana.

Les sondes système d’Icinga sont réglées à 5 minutes.
Quelle période envisager pour Collectd ?

Par défaut c'est 10 secondes. Pour les sondes personnalisées XMPP a une période d’une minute.

Quasiment tous les points de mesure affichés dans le test sont déjà mesurés via des sondes Icinga.
Du coup, Collectd, n'est-il pas redondant ?

Dans les mesures venant d'Icinga manquent des paramètres comme les entrées ou sorties de volume de stockage.

Les sondes Icinga, en plus de partager les données avec Grafana, gèrent des alertes.
Collectd ne fait que collecter des mesures et ne génère aucune alerte.
Y-a-t-il utilité à mesurer sans générer d'éventuelles alertes ?

Collectd est un outil de métrologie alors qu’Icinga est un outil de supervision. Le but de la métrologie est de collecter des informations pour analyser des évolutions de comportements dans le temps. Le but de la supervision est de réveiller les adminsys quand un problème est à résoudre immédiatement. Beaucoup d'outils font les deux à la fois, mais ce sont bien deux approches différentes pour des besoins différents. Les adminsys ont besoin de la supervision, les décideurs pressés s'intéressent plus à la métrologie.

Actuellement, Icinga contient 1 005 sondes.
Quels sont les points de mesure manquants dans Icinga ?

Toutes celles ajoutées dans un panneau de graphe pour XMPP en guise d’exemple (et ce n’est pas fini). On y trouve :

• XMPP Accounts :
  • Total,
  • Active,
  • Active (dedup) ;
• Federation :
  • Incoming s2s,
  • Outgoing s2s ;
• Group chat :
  • Total rooms ;
• HTTP Upload disk usage :
  • Per user avg (in MB) ;
  • Total (in GB).

Icinga sur la VM Agir est le déclencheur des mesures (à vérifier).
Collectd depuis une VM cliente, alimente directement Icinga (à vérifier).
Du point de vue de l’architecture, a-t-on une approche meilleure que l'autre ?

Quel futur pour le système de collecte ?

Un autre système de collecte en est en cours de développement : StatoolInfos. Il est exploité pour ChaprilInfos et ChatonsInfos. Le périmètre des données vise celles génériques pour HTTP et celles spécifiques au services (nombre de comptes, d'utilisateurs etc.). La fréquence est très réduites : une fois par jour au plus.

Quelques avantages de ChaprilInfos :

• Accès public ;
• Possibilité de calculs cumulatifs.

Par exemple dans un graphique le nombre de visiteurs du service pourra être cumulé entre tous les services du Chapril et même au niveau du collectif CHATONS.