Chapril DokuWiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Métrologie via Collectd ======

<note important>
Cette page est issue du brouillon [[https://pad.chapril.org/p/chapril_influxdb_collectd_grafana|Métrologie Chapril]] dans l’Etherpad de l’April.
Une partie des informations reste à vérifier.
</note>

Le Chapril a choisi [[:services:grafana.chapril.org|Grafana]] comme outil de consultation de données de métrologie, et [[https://docs.influxdata.com/influxdb/v1/|Influxdb]] comme format de stockage des données.

Initialement la métrologie est obtenue par une instance [[:admin:monitoring:base-deployment|Icinga]] du superviseur.

===== Configuration d’InfluxDB =====

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 [[https://collectd.org/|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 :
<file ini /etc/influxdb/influxdb.conf>
[[collectd]]
  enabled = true
  bind-address = ":25826"
  database = "collectd"
  security-level = "encrypt"
  auth-file = "/etc/influxdb/collectd.auth_file"
</file>

<note>La version majeur actuelle semble être InfluxDB 1.</note>

===== Ajout classique =====

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.).

<code bash>
apt install --no-install-recommends collectd libgcrypt20
</code>
<file apache /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>
</file>

<note>Le greffon ''rrdtool'' n’est pas exploité en plus de générer beaucoup d’accès disque.
Mieux vaut désactiver son chargement en commentant ainsi :
<file apache /etc/collectd/collectd.conf>
#LoadPlugin rrdtool
</file>
Penser à supprimer le contenu inutile présent dans ''/var/lib/collectd/rrd/*'' après redémarrage du service.
</note>

On termine en redémarrant le démon :
<code bash>
systemctl restart collectd
</code>

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

===== Ajout des fichiers =====

Pour tenir compte des fichiers modifier le champ ''ReportInodes''.
<file apache /etc/collectd/collectd.conf>
<Plugin "df">
  ReportInodes true
</Plugin>
</file>

===== Ajout d’Apache =====

Dans le cas où la VM dispose d’[[https://httpd.apache.org/|Apache HTTP Server]] le greffon ''apache'' peut être chargé ainsi :
<file apache /etc/collectd/collectd.conf.d/apache.conf>
LoadPlugin apache
<Plugin "apache">
  <Instance "apachewiki">
    URL "http://localhost/server-status?auto"
  </Instance>
</Plugin>
</file>

Une configuration supplémentaire est aussi nécessaire pour le serveur Apache :
<code apache>
ExtendedStatus on
<IfModule mod_status.c>
  <Location /mod_status>
    SetHandler server-status
  </Location>
</IfModule>
</code>

===== Ajout de scripts =====

==== Bash ====

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

<file apache /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>
</file>

Exemple de script Bash qui compte le nombre d'utilisateurs UNIX connectés :
<file bash /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
</file>

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 à ''[[https://collectd.org/documentation/manpages/collectd-exec.html|collectd-exec(5)]]''.

==== Python ====

Penser à installer le paquet ''libpython3.xx''.

Se référer à ''[[https://collectd.org/documentation/manpages/collectd-python.html|collectd-python(5)]]''.

===== Expérimental =====

==== Ré-échantillonnage ====

Le ticket [[https://agir.april.org/issues/5466|#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 :
<code sql>
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;
</code>

===== Questions fréquentes =====

==== Stockage ====

> 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.

==== Version d’InfluxDB ====

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

==== Fréquence ====

> 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 [[https://grafana.chapril.org/d/VcqDKU8Gz/pitchums-test-dashboard?viewPanel=6&orgId=1&from=1615647600000&to=now&refresh=5m|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.

==== Redondance ====

> 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.

==== Gestion d'alertes ====

> 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.

==== Nouvelles mesures ====

> Actuellement, Icinga contient 1 005 sondes.
> Quels sont les points de mesure manquants dans Icinga ?
Toutes celles ajoutées dans [[https://grafana.chapril.org/d/97P8IXUGk/xmpp?orgId=1|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)//.

==== Top-down vs Down-top ====

> 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 ?

==== ChaprilInfos ====

> 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 [[https://stats.chatons.org/|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 [[https://chatons.org/|CHATONS]].