82. pepsi-telemetry-client

L’agrégateur de télémétrie de fonctionnalités par hôte : collecte les événements locaux d’utilisation des fonctionnalités et soumet des agrégats anonymes au collecteur central.

82.1. Rôle

pepsi-telemetry-client est le côté producteur de la télémétrie de fonctionnalités anonyme de Pepsi ; le collecteur central est pepsi-telemetry. Il est livré dans le paquet Pepsi principal et s’exécute comme un petit démon sur chaque déploiement où la télémétrie est activée — et, en sommeil, sur un déploiement où elle ne l’est pas mais qui souhaite que la console du navigateur puisse l’activer. Lancez-le avec pepsi-telemetry-client serve.

Les programmes Pepsi de l’hôte (les workers d’étape et pepsi-ingress) signalent l’usage des fonctionnalités par un appel interne telemetry_update non bloquant qui transmet un nom court de fonctionnalité à ce démon par une socket UNIX locale — l’étape appelante n’attend jamais le réseau. Le démon agrège ces événements et les soumet à TELEMETRY_SERVER sous le SYSTEM_ID anonyme du déploiement.

82.2. Fonctionnement

  • Socket locale. Le démon écoute sur [pepsi-telemetry-client] UNIXPATH (par défaut /run/pepsi-telemetry/socket, un répertoire dont cette unité est seule propriétaire — le collecteur, lui, écoute dans /run/pepsi-collector), partagée par le groupe avec les utilisateurs pepsi et pepsi-ingress. Chaque producteur conserve une connexion persistante pendant toute la durée de vie de son processus et se reconnecte si le démon redémarre ; les événements sont abandonnés (au mieux) tant qu’il est injoignable, de sorte qu’un producteur n’est jamais bloqué.

  • Agrégation en mémoire. Un décompte par intervalle est tenu pour chaque fonctionnalité, plus l’ensemble cumulé des noms de fonctionnalités vus depuis le démarrage (l’instantané des fonctionnalités activées). Le nombre de noms distincts est plafonné par MAX_FEATURES.

  • Soumission périodique. À chaque SUBMIT_INTERVAL (par défaut : au plus une fois par minute), le démon envoie en POST les décomptes par intervalle vers /telemetry/usage et l’ensemble cumulé de fonctionnalités vers /telemetry/features, puis remet à zéro les décomptes par intervalle. Une soumission d’usage qui échoue est conservée et réessayée à l’intervalle suivant plutôt que perdue.

  • Arrêt propre. Sur SIGINT/SIGTERM, il effectue une dernière soumission avant de sortir.

  • En sommeil tant qu’elle est désactivée. Télémétrie désactivée, il ne lie aucune socket et ne collecte ni ne soumet rien. Il relit le fichier de configuration à la notification telemetry_changed — envoyée, dans les deux sens, par quiconque réécrit l’interrupteur : pepsi-setup et la tâche write-config de la console —, sur SIGHUP, et chaque minute, puis se réveille ou se rendort. En se mettant en sommeil, il abandonne ce qui a été collecté et pas encore envoyé. La notification ne fait pas autorité ; seul le fichier décide.

  • Ligne d’état. Il tient une ligne dans pepsi.telemetry_client (en cours d’exécution, activé, en train de soumettre, si un SYSTEM_ID utilisable est configuré — un booléen, jamais l’identifiant — et un battement de cœur), supprimée lors d’un arrêt propre. pepsi-httpd la lit pour décider si la console de configuration peut proposer d’activer la télémétrie.

Le démon estampille chaque soumission avec la version de release Pepsi avec laquelle il a été construit, de sorte que le collecteur compte l’usage des fonctionnalités par release.

82.3. Configuration

L’interrupteur principal est [pepsi] SHARE_TELEMETRY, et il est désactivé par défaut : la télémétrie se fait sur consentement explicite, de sorte qu’une installation qui n’a jamais répondu à la question ne fait aucune télémétrie. Tant qu’il n’est pas réglé sur yes, le démon reste en sommeil et les appels telemetry_update intra-processus sont sans effet et n’ouvrent aucune socket — tout le chemin est inerte, que l’unité de service soit activée ou non. [pepsi] SYSTEM_ID (généré par pepsi-setup, mais seulement une fois l’interrupteur activé) et TELEMETRY_SERVER (par défaut telemetry.pepsi.taler.net) complètent la configuration globale. Le listener et les réglages de cadence propres au démon sont dans [pepsi-telemetry-client] : UNIXPATH (par défaut /run/pepsi-telemetry/socket), UNIXPATH_MODE (par défaut 0660), UNIXPATH_GROUP (par défaut pepsi-telemetry, le groupe auquel pepsi et pepsi-ingress sont ajoutés), SUBMIT_INTERVAL (par défaut 60 s, qui doit employer les unités h/m/s et ne peut être nul) et MAX_FEATURES (par défaut 4096). Voir pepsi-telemetry-client(1) et pepsi.conf(5) pour la liste complète.

82.4. Activer le service

L’unité n’est délibérément pas démarrée par pepsi.target, contrairement aux démons propres du pipeline (elle est PartOf= la cible, de sorte qu’arrêter ou redémarrer la cible l’atteint bien) : la cible est l’unique interrupteur qui démarre le pipeline, et une unité qui y serait nommée tournerait sur chaque déploiement quelle qu’ait été la réponse de l’opérateur. À la place, pepsi-setup run arme l’unité à la fin d’une exécution réussie lorsque l’interrupteur est activé (systemctl enable --now) ; lorsqu’il est désactivé, il laisse l’unité dans l’état où l’opérateur l’a laissée — sans jamais la démarrer, et sans plus l’arrêter, car un démon en cours d’exécution est en sommeil et c’est ce dont la console a besoin. Dans les deux cas, il envoie ensuite telemetry_changed, de sorte que désactiver la télémétrie prend effet aussitôt. Avec l’interrupteur activé et sans SYSTEM_ID valide, l’unité est armée malgré tout ; le démon reste en sommeil et en indique la raison. Sur un hôte sans systemd, rien n’est fait (il n’y a aucune unité à armer) ; lorsque systemd ne connaît pas l’unité, setup ne le signale que si la télémétrie est activée ; sans root, il journalise l’unique commande systemctl à exécuter.

82.4.1. L’activer depuis la console

La console de configuration du navigateur ne propose « yes » que tant que le démon s’exécute et qu’un SYSTEM_ID est configuré ; sinon, la question est désactivée avec des indications, et une requête d’API visant à l’activer est refusée (409 telemetry_client_not_ready). La console ne génère jamais d’identifiant. Pour qu’elle propose l’interrupteur, ajoutez sur le serveur SYSTEM_ID = suivi de 64 caractères hexadécimaux (par exemple openssl rand -hex 32) à [pepsi] et exécutez systemctl enable --now pepsi-telemetry-client.service. Un enregistrement depuis la console conserve un identifiant existant, quelle que soit la réponse.

82.5. Confidentialité

Aucune information permettant d’identifier une personne ne quitte l’hôte. La seule identité est le SYSTEM_ID aléatoire de 256 bits ; les charges utiles sont des noms de fonctionnalités et des décomptes. Rien n’est partagé à moins qu’un opérateur ne le demande : l’interrupteur est désactivé par défaut, l’assistant de configuration pose la question avec no comme réponse par défaut, et aucun identifiant n’est généré pour un déploiement qui n’a pas consenti. Un opérateur qui a consenti peut cesser de partager en réglant SHARE_TELEMETRY = NO — dans la console, ou dans le fichier suivi de pepsi-setup run (ou d’un SIGHUP, ou d’une minute d’attente) : le démon se met alors en sommeil et abandonne ce qu’il n’avait pas envoyé — ou en arrêtant/désactivant directement le service pepsi-telemetry-client.

82.6. Voir aussi

pepsi-telemetry (le collecteur), pepsi-setup, pepsi-telemetry-client(1), pepsi.conf(5).