81. pepsi-telemetry¶

Le collecteur central, anonyme et sur consentement explicite, de télémétrie de fonctionnalités.

81.1. Rôle¶

pepsi-telemetry collecte une télémétrie d’usage anonyme des installations Pepsi qui s’y inscrivent. C’est un petit serveur HTTP, délibérément séparé de pepsi-httpd et livré dans son propre paquet Debian, destiné à s’exécuter sur un seul hôte — par défaut telemetry.pepsi.taler.net — derrière un serveur frontal nginx ou Apache existant. Exécutez-le avec pepsi-telemetry serve.

Un nœud Pepsi qui remonte des données n’est identifié que par un system_id aléatoire de 256 bits (aucune information personnelle identifiante). Le collecteur se connecte au schéma PostgreSQL pepsi partagé sous le rôle pepsi-telemetry et stocke tout dans la table pepsi.telemetry, en comptant l’usage par version Pepsi remontée.

81.2. Fonctionnalités¶

Deux points de terminaison de soumission ouverts. POST /telemetry/features enregistre quelles fonctionnalités un déploiement a activées (un instantané : les fonctionnalités listées deviennent activées, celles omises désactivées, l’historique d’usage étant conservé), et POST /telemetry/usage cumule les compteurs d’usage par fonctionnalité (des deltas, sommés côté serveur). Les deux sont non authentifiés — la seule identité est le system_id anonyme — et bornés par MAX_BODY plus les limites de débit du serveur frontal.
Comptage par version. La version remontée dans chaque soumission fait partie de la clé de la table, de sorte que les événements d’usage sont attribués à la release Pepsi qui les a produits et qu’une mise à niveau accumule des lignes distinctes.
Rapport agrégé public. GET /telemetry/report renvoie des récapitulatifs par fonctionnalité (déploiements activés distincts et usages totaux) avec une ventilation par version, en JSON. Il n’expose jamais un system_id individuel et peut donc être servi ouvertement sans risque.
Aucun TLS propre. Il sert du HTTP en clair sur une socket UNIX (/run/pepsi-collector/pepsi-telemetry.sock, activée par socket via SERVE = systemd telle que livrée, ou liée par le démon lui-même avec SERVE = unix) pour un reverse proxy, ou du TCP en clair pour des tests locaux. Le TLS est terminé par le nginx/Apache frontal.

81.3. Table de stabilité des fonctionnalités¶

Le script compagnon contrib/update-feature-stability.sh récupère GET /telemetry/report et régénère Stabilité des fonctionnalités, attribuant à chaque fonctionnalité un palier d’après à la fois son ampleur de déploiement et l’intensité avec laquelle elle est exercée (une fonctionnalité doit franchir les deux seuils pour un palier) :

stable — déploiements ≥ 100 et usages totaux ≥ 100000
used — déploiements ≥ 10 et usages totaux ≥ 1000
experimental — sinon

Les seuils, l’URL source et le chemin de sortie peuvent être redéfinis par des variables d’environnement (voir l’en-tête du script).

81.4. Configuration¶

[pepsi-telemetry] : SERVE (unix/tcp/systemd) avec les options de transport correspondantes (UNIXPATH/UNIXPATH_MODE/UNIXPATH_GROUP, ou BIND_TO/PORT), MAX_BODY (par défaut 65536), MAX_CONNECTIONS (par défaut 128) et DB_POOL_SIZE (par défaut 2). La connexion à la base de données provient de la section partagée [pepsi-postgres]. Voir Configuration et pepsi-telemetry(1).

81.5. Déploiement¶

Le paquet Debian pepsi-telemetry livre une unité de service et une unité socket systemd (servant sur /run/pepsi-collector/pepsi-telemetry.sock), son fichier de configuration /etc/pepsi-telemetry/pepsi-telemetry.conf ainsi que des fichiers de site reverse-proxy pour nginx comme pour Apache, installés sous leurs noms de site canoniques :

/etc/nginx/sites-available/telemetry.pepsi.taler.net
/etc/apache2/sites-available/telemetry.pepsi.taler.net.conf

Ils arrivent complets et désactivés, pointant déjà vers la socket que les unités livrées lient ; activer l’un d’eux ne demande donc qu’un lien symbolique — il n’y a aucun chemin de proxy à renseigner, et donc aucun à se tromper :

# nginx
$ ln -s ../sites-available/telemetry.pepsi.taler.net /etc/nginx/sites-enabled/
$ systemctl reload nginx

# Apache (a2ensite makes the same symlink)
$ a2enmod proxy proxy_http ssl ratelimit headers
$ a2ensite telemetry.pepsi.taler.net
$ systemctl reload apache2

Provisionnez ensuite un certificat pour l’hôte, et installez le schéma à partir du fichier propre au collecteur, qui n’a besoin de rien d’autre que de sa section [pepsi-postgres]

$ pepsi-setup -c /etc/pepsi-telemetry/pepsi-telemetry.conf schema

Les mises à niveau du paquet mettent le schéma à niveau de la même façon, et le collecteur refuse de démarrer sur un schéma d’une autre version tant qu’elles ne l’ont pas fait (voir Mise à niveau). Les deux fichiers de site sont des conffiles, si bien que les modifications locales — un server_name différent, par exemple, pour un collecteur privé — survivent aux mises à niveau du paquet.

Changez le chemin de la socket et cela devient une même affirmation en quatre endroits : le ListenStream= de l’unité .socket, le RuntimeDirectory= du service et les deux fichiers de site (plus UNIXPATH dans la configuration propre au collecteur, si vous le basculez sur SERVE = unix). make check-telemetry-socket, que make check exécute, les compare et fait échouer la construction si deux d’entre eux divergent — utile, car une divergence est invisible aux tests et n’atteint la production que sous la forme d’un 502 renvoyé par le serveur frontal.

Le répertoire d’exécution du collecteur n’appartient qu’à lui seul, et c’est là tout l’intérêt. Ce n’est pas /run/pepsi (celui du pipeline de courrier, partagé par pepsi-ingress, pepsi-httpd et la sonnette setup-apply), et ce n’est pas /run/pepsi-telemetry (celui du client de télémétrie, dont la socket /run/pepsi-telemetry/socket appartient à pepsi). systemd attribue un répertoire d’exécution au User= de l’unité qui le déclare — en lui appliquant un chown, ainsi qu’à son contenu, à chaque démarrage — et, sans RuntimeDirectoryPreserve=, le supprime lorsque cette unité s’arrête. Un répertoire partagé entre des services tournant sous des comptes différents finit donc par appartenir à celui qui a démarré en dernier, et l’arrêt d’un service supprime les sockets que les autres ont encore liées.

Des noms de fichiers distincts dans un répertoire partagé ne constituent pas une protection. Si la socket du collecteur se trouvait dans le répertoire du client, un hôte faisant tourner les deux fonctionnerait jusqu’au démarrage suivant du client ; la socket du collecteur passerait alors à pepsi:pepsi, perdrait le groupe www-data par lequel se connecte le serveur frontal, et chaque requête deviendrait un 502 — avec un collecteur active, sain et silencieux, n’ayant jamais vu la moindre connexion. Faire tourner le collecteur sur un hôte dédié reste le déploiement prévu, mais ce n’est pas ce qui sépare les deux.

81.6. Voir aussi¶

pepsi-telemetry-client (le client par hôte qui soumet à ce collecteur), pepsi-httpd, pepsi-setup, Stabilité des fonctionnalités, pepsi.conf(5).