Comment les développeurs de logiciels comprennent-ils quelles parties de leur logiciel sont utilisées et s'ils fonctionnent comme prévu*? La réponse moderne est la télémétrie, ce qui signifie qu'un logiciel envoie des données pour répondre à ces questions à un serveur de collecte.
Je pense que les projets de logiciels open source doivent explorer de nouvelles conceptions de télémétrie qui aident les développeurs à obtenir les informations dont ils ont besoin pour travailler de manière efficace et efficiente, sans collecter de traces invasives de l'activité détaillée des utilisateurs.
J'ai écrit une courte série d'articles de blog sur une telle conception, que j'appelle la télémétrie transparente, car elle collecte le moins possible (kilooctets par an à partir de chaque installation) et publie ensuite chaque élément qu'elle collecte, pour inspection et analyse publiques.
J'aimerais explorer l'utilisation de la télémétrie transparente, ou d'un système similaire, dans la chaîne d'outils Go, qui, je l'espère, aidera les développeurs de projets Go et les utilisateurs. Pour être clair, je suggère seulement que l'instrumentation soit ajoutée aux outils de ligne de commande Go écrits et distribués par l'équipe Go, tels que la commande go, le compilateur Go, gopls et govulncheck. Je ne suggère pas que l'instrumentation soit ajoutée par le compilateur Go à tous les programmes Go dans le monde : c'est clairement inapproprié.
La télémétrie transparente possède les propriétés clés suivantes :
- Les décisions concernant les mesures à collecter sont prises dans le cadre d'un processus public ouvert.
- La configuration de la collecte est automatiquement générée à partir des métriques activement suivies : aucune donnée n'est collectée qui n'est pas nécessaire pour les métriques.
- La configuration de collecte est servie à l'aide d'un journal transparent inviolable, ce qui rend très difficile la fourniture de différentes configurations de collecte à différents systèmes.
- La configuration de la collecte est un module Go mis en cache et proxy, de sorte que tout proxy Go local améliorant la confidentialité déjà utilisé pour les modules ordinaires sera automatiquement utilisé pour la configuration de la collecte. Pour atténuer davantage les inquiétudes concernant les systèmes de suivi par le téléchargement de la configuration de collecte, chaque installation ne se soucie que de télécharger la configuration chaque semaine avec une probabilité de 10%, de sorte que chaque installation ne demande la configuration qu'environ cinq fois par an.
- Les rapports téléchargés n'incluent que le nombre total d'événements sur une semaine complète, pas n'importe quel type de suivi d'événements classés dans le temps.
- Les rapports téléchargés n'incluent pas les ID utilisateur, les ID machine ou tout autre type d'ID.
- Les rapports téléchargés contiennent uniquement des chaînes déjà connues du serveur de collecte : noms de compteur, noms de programme et chaînes de version répétées à partir de la configuration de collecte, ainsi que les noms des fonctions dans des programmes de chaîne d'outils Go spécifiques et non modifiés pour les traces de pile. Les seuls types de données autres que des chaînes dans les rapports sont le nombre d'événements, les dates et les numéros de ligne.
- Les adresses IP exposées par la session HTTP qui télécharge le rapport ne sont pas enregistrées avec les rapports.
- Grâce à l'échantillonnage, seul un nombre constant de rapports téléchargés est nécessaire pour atteindre un objectif de précision spécifique, quel que soit le nombre d'installations existantes. Plus précisément, seuls 16 000 rapports environ sont nécessaires pour une précision de 1 % à un niveau de confiance de 99 %. Cela signifie qu'à mesure que de nouveaux systèmes sont ajoutés au système, chaque système signale moins souvent. Avec une estimation prudente de deux millions d'installations Go, environ 16 000 rapports chaque semaine correspondent à un taux de rapport global bien inférieur à 2 % par semaine, ce qui signifie que chaque installation téléchargerait un rapport en moyenne moins d'une fois par an.
- Les métriques calculées agrégées sont rendues publiques sous forme graphique et tabulaire.
- Les données brutes complètes collectées sont rendues publiques, de sorte que les responsables du projet n'ont aucun avantage ou aperçu exclusif dans leur rôle de collecteur direct de données.
- Le système est activé par défaut, mais la désactivation est simple, efficace et persistante.
Partager