ChatonsInfos version 0.4, en avant les métriques!

Groupes de travail stats.chatons.org
1

Le groupe de travail stats.chatons.org a le plaisir de vous annoncer la sortie de la version 0.4 de ChatonsInfos.

Pour rappel, ChatonsInfos est un protocole de partage de données pour mesurer l’activité du collectif, de ses membres et leurs services. Basé sur des fichiers properties, ChatonsInfos permet de générer le site https://stats.chatons.org/. La participation est volontaire, tous les membres du collectif sont encouragés à participer. Le but est de pouvoir dire montrer combien nos services sont utilisés et utiles :smiley_cat:

La grande nouveauté est la mesure de l’activité des services des membres. Jusqu’ici, avec ChatonsInfos, chaque membre définissait 1 fichier properties pour son organisation et 1 fichier properties par service. Maintenant, en plus, il lui est possible de créer 1 fichier properties pour les métriques d’un service. Chaque fichier nomduservice.properties référencera alors le fichier nomduservice-metrics.properties.

L’objectif : faire exploser les stats dans les graphiques :star_struck:
image

La liste des métriques et leur définition ont représenté un long et conséquent travail du groupe. Merci Angie, Mrflos, Jeey, Antoine et Cpm. Le résultat évoluera en fonction de nos remarques, besoins et retours d’expériences. Vous trouverez la liste des métriques supportées dans le fichier modèle des métriques.

Toujours en s’appuyant sur notre convention des properties, les données peuvent être quotidiennes, hebdomadaires ou mensuelles. Extrait :

metrics.http.visits.humans.2021.months=,73,33,10
metrics.http.visits.humans.2021.weeks=,55,18,12,6,8,5,5,5,2
metrics.http.visits.humans.2021.days=,32,23,3,2,0,13,6,1,1,2,1,1,0,1,3,1,0,1,2,1,0,1,0,4,2,0,1,1,1,0,2,0,0,1,1,0,1,1,1,0,1,2,2,0

Par où commencer ? Assurément, le plus facile est de commencer par les métriques HTTP. Certains rendus sur stats.chatons.org sont encore en travaux (vue quotidienne, par catégorie…) mais vous pouvez dès maintenant générer les fichiers de métriques. Et pour vous aider, découvrez le générateur de fichiers métriques statoolinfos.

D’autres changements mineurs (voir le fichier CHANGELOG) :

  • ajout de plusieurs champs organization.geolocation ;
  • service.url : changement de « Recommandé » à « Obligatoire ».

Nous invitons tous les membres du collectif à mettre à jour leurs fichiers properties ou à en créer si ce n’est pas déjà fait.

Résumé des liens :

3 « J'aime »
2

Merci pour ce travail initié il y a déjà plusieurs mois.

Je m’interroge sur certaines métriques et sur les risques associés à leurs publications pour des chatons ayant peu d’usagers sur un service. Je pense que la précision de certaines métriques peut désanonymiser certaines informations (ou poser d’autres soucis).

De façon général, il faudrait donc se méfier si le nombre de comptes actifs associés à un outil est inférieur à un certains nombre.

Principalement, le plus inquiétant me semble celles concernant les gestionnaires de facturation / paiement. Si il y a peu de structure qui utilisent l’outil d’un chaton, ces infos peuvent révéler des choses sur leurs activités. Hors ces structures n’auront peut être pas consciences que de tels stats sont publiées.

https://framagit.org/chatons/chatonsinfos/-/blob/master/MODELES/metrics.properties#L1232

Les métriques HTTP, si elles sont générées via le générateur risquent aussi de constituer une preuve du non respect des réglementations sur la rétention des logs. Sans que les chatons en aient vraiment consciences. A moins que l’outil limite son analyse à 1 an de logs ? (ce qui limite un peu le problème, bien qu’en théorie seules les requêtes d’ajout/édition/suppression de contenue devraient être logguée sur cette période)

Dans le même genre, en cas de litige sur les questions de retrait de contenus illégaux, avoir des stats sur les fichiers supprimés/comptes fermés + une indication à la semaine ou au jour pourrait se retourner contre un chaton dans une procédure de contentieux relatifs au délais de mise en œuvre (ou autre).

Ces risques me semblent modérés, mais vu qu’ils existent, je me permet d’en faire part.

3

Ces risques me semblent modérés, mais vu qu’ils existent, je me permet d’en faire part.

Houla, sujet pas facile mais nécessaire. Merci de ton aide, ça donne une opportunité de le traiter encore mieux.

Dans le groupe de travail, à chaque fois que nous nous sommes posé la question, nous avons mis en évidence les principes suivants :

  1. aucune métrique n’est une donnée personnelle ;
  2. tous les métriques sont des aggloméras de plusieurs utilisateurs donc on a en quelque sorte un anonymat ;
  3. participation volontaire : les membres décident librement des métriques qu’ils partagent, pas d’obligation et ils sont les mieux placés (en théorie) pour évaluer le niveau de sensibilité par rapport à leur contexte.

L’outil a deux modes de fonctionnement :

  1. mode « full » : analyse de toutes les logs disponibles, sans limite de durée. Normalement, on le fait une fois, la première fois avec le stock de logs disponible ;
  2. mode « previousdays » : mise à jour des valeurs sur une durée limitée, typiquement en remontant au jour précédent pour compléter le fichier au jour le jour.

Dans les deux cas, il est impossible de savoir si les valeurs du fichier properties de métriques viennent de logs anciennes conservées ou de mises à jour quotidiennes dont les logs ont disparues. Donc les fichiers properties de métriques ne révèlent pas grand chose d’intrusif de la politique de rétention des logs.

À noter que j’ai renoncé à générer des valeurs annuelles de métriques justement parce que ça nécessite d’avoir jusqu’à plus d’une année de logs pour avoir un résultat cohérent. Là, les valeurs générées sont mensuelles, hebdomadaires et journalières et donc seulement 6 semaines max de logs sont nécessaires pour générer les stats du mois en cours.

Donc j’espère que sur ce point nous sommes ok.

Dans le même genre, en cas de litige sur les questions de retrait de contenus illégaux, avoir des stats sur les fichiers supprimés/comptes fermés + une indication à la semaine ou au jour pourrait se retourner contre un chaton dans une procédure de contentieux relatifs au délais de mise en œuvre (ou autre).

Pfiouuuu, ça va loin mais la démarche est bonne. Besoin de plus de temps pour l’explorer :thinking:

4

Bonjour l’équipe stats.chatons.org,

Déjà, je souhaite à tous tout plein de voeux de metrique et de statistiques pour 2022 :slight_smile:

Je ne sais pas si c’est une bonne résolution, mais j’ai intégré la mesure des metrics http sur quasiment tout mes services.
C’est interessant déjà, de voir ce que l’on a comme volume personnel.
Vivement que pas mal de CHATONS fassent de même pour que l’on se rend contre du volume collectif :sunglasses:

Si j’ai bien compris l’interface de « Metriques » de stats.chatons.org, les infos suivantes à travailler vont se trouver dans l’onglet « Générique » (ex: service.users, service.accounts, service.database.bytes, service.files.bytes, …).
Soit des informations que l’on va retrouver dans les SGBD ou sur le File-System de nos services.

Par contre, dans beaucoup des cas, on aura pas facilement la possibilité de récupérer des valeurs autres que le jour même (ou la veille en première aproximation): contrairement aux logs, on n’aura pas vraiment de trace sur l’évolution.
Sur 2020 et 2021, ces données risquent d’être extrapolé. C’est les données 2022 calculé « en live » qui seront les plus justes.
J’espère que je ne me trompe pas trop dans mon analyse.

Super boulot en tout cas, je suis fan :wink:

5

Je ne sais pas si c’est une bonne résolution, mais j’ai intégré la mesure des metrics http sur quasiment tout mes services. C’est interessant déjà, de voir ce que l’on a comme volume personnel.

Oui \ooooooooooooo/

Si j’ai bien compris l’interface de « Metriques » de stats.chatons.org, les infos suivantes à travailler vont se trouver dans l’onglet « Générique » (ex: service.users, service.accounts, service.database.bytes, service.files.bytes, …).

Oui, les métriques génériques sont potentiellement communs à tous les services. Du coup, c’est intéressant de les regrouper et notamment de pouvoir les cumuler pour tous les services d’un membre ou tous les services de tous les membres.

La liste des métriques génériques est consultable ici dans le fichier modèle dédié (à la ligne « # [Metrics génériques] ».

Par contre, dans beaucoup des cas, on aura pas facilement la possibilité de récupérer des valeurs autres que le jour même

Absolument, par exemple la taille d’une base de données, c’est vraiment un instantané. La solution est de lancer la mesure des statistiques une fois par jour. Comme ça le fichier des métriques est alimenté au fur et à mesure. Et du coup, il faut accepter de ne pas pouvoir recalculer d’anciennes valeurs.

De toute façon, comme la plupart des politiques de rétention des logs pose une limite dans le temps (souvent 3 mois), on voit que c’est bien la mise à jour régulière qui est la solution. Alors bien sûr, voir des stats de 2020, c’est cool, mais bon, le plus intéressant ça va être les stats 2022 :smiley:

Super boulot en tout cas, je suis fan

Merci pour tes encouragements et ton enthousiasme :star_struck:
Il reste encore beaucoup de travail mais petit à petit nous avançons :smiley_cat:

6

Bonsoir,

Je regarde un peu les metriques génériques qu’il y aura à mettre en place.

J’ai du mal à bien comprendre la différence entre ses deux métriques :

# Nombre d'utilisateur⋅ices du service.
metrics.service.users.name = Nombre d'utilisateur⋅ices du service
metrics.service.users.description = 
metrics.service.users.* =

# Nombre d'utilisateur·ices du service ayant un compte.
metrics.service.accounts.name = Nombre d'utilisateur·ices du service ayant un compte
metrics.service.accounts.description = 
metrics.service.accounts.* =

Les utilisateurs/utilisatrices ayant un compte, je vois à peut pret: c’est gloablement le nombre de « compte » lié à un système d’autentification.

Par contre, la notion d’utilisateurs/utilisatrice indépendament de compte, j’ai un peu de mal.
Où alors, s’il n’y a pas de compte, on n’a pas d’identifiant du coup et donc sauf à ce la jouer GAFAM en mettant des cookies, on ne peut pas savoir que c’est la même personne.

Est-ce que quelqu’un pourrait illustrer par des exemples ces notions ?
Genre, en reprenant des services classique: etherpad, nextcloud, email, jitsi-meet , blog (wordpress), …

Merci

7

Par contre, la notion d’utilisateurs/utilisatrice indépendament de compte, j’ai un peu de mal.

Prenons par exemple MyPads. Il faut un compte pour créer un pad mais pas besoin de compte pour utiliser un pad créé par quelqu’un qui a un compte :yum:

Autre exemple : avec Wordpress, l’utilisateur qui crée un blog a un compte, l’utilisateur qui lit le blog n’en a pas :yum:

Autres exemples : Nextcloud, Cryptpad, Gitea, GitlabCE, Mastodon, Mobilizon, Peertube, Wordpress…

Donc 3 cas :

  • uniquement des comptes et donc « utilisateur = compte » : Minetest ;
  • des utilisateurs avec ou sans compte : MyPad ;
  • aucun compte donc uniquement des utilisateurs : Mumble.

Dans le troisième cas, le logiciel n’a pas de gestion de compte, alors pas besoin de chercher à construire des comptes, y a zéro et pis c’est tout :innocent:

8

Autre exemple : avec Wordpress, l’utilisateur qui crée un blog a un compte, l’utilisateur qui lit le blog n’en a pas

Je comprend, mais comment je l’identifie comme utilisateur ?
Juste avec son IP ? donc, ca reviens à reprendre la métrique metrics.http.visits.humans, non?

9

Je comprend, mais comment je l’identifie comme utilisateur ?
Juste avec son IP ? donc, ca reviens à reprendre la métrique metrics.http.visits.humans, non?

Hmmm, ça serait plutôt metrics.http.visitors.humans :thinking:

Alors, oui mais non, pas vraiment, en fait pas du tout mais ça dépend :blush:

D’abord, tous les services ne sont pas web. Ainsi, Minetest ou Mumble sont utilisables sans interface web et donc pas de log http disponible. Et donc on ne peut pas utiliser un metric http pour mesurer les fréquentations des utilisateurs. D’où la nécessité d’avoir un metric dédié : metrics.service.users.

Ensuite, dans le cas d’un service web, quand on veut comptabiliser les users, tous les visitors ne sont pas des utilisateurs. En effet, un visiteur peut très bien regarder la page d’accueil du service, lire sa doc, mais pour autant ne pas l’utiliser vraiment. Et puis il faut tenir compte des requêtes hors-sujet (tentatives de piratages, flood, erreurs, monitoring indélicat, de bots à l’UserAgent trompeur…). Or, dans les utilisateurs, a priori, ce que l’on veut, c’est dénombrer les vrais utilisateurs, c’est plus précis.

Ainsi pour PrivateBin, on peut considérer qu’un utilisateur créé un pad ou en lit un. Et pour Framadate, un utilisateur créé un sondage ou vote dans un sondage. Donc on va cibler dans les logs des URL spécifiques qui permettent de détecter certaines actions qui prouvent une utilisation active du service.

On pourrait croire que la différence est faible entre visiteurs et utilisateurs mais l’expérience montre qu’on peut atteindre des ratios de 3 à 9. Du coup, c’est énorme et ça vaut le coup d’essayer de mesurer la vraie utilisation du service.

Est-ce que cela est faisable pour chaque service ? Autant essayer de le faire pour le plus de service possible. Et dans le pire des cas ou par défaut, on peut recopier la valeur de metrics.http.visitors.humans dans metrics.service.users, ce n’est pas un problème que deux metrics aient la même valeur puisque leur fonction est différente :smiley:

10

Super, merci de ta réponse.

En effet, vu ainsi, on voit qu’il y a une nuance entre metrics.http.visitors.humans et metrics.service.users.
En mettre en oeuvre en la prenant en compte, donc.

Notons alors que la semaine, le mois et l’année ne peuvent donc se calculer qu’une fois entièrement effectuées pour ne pas compter un « user » plusieurs fois.

Je rajoute donc que dans le cas d’outil avec un compte obligatoire, on aura bien dans metrics.service.accounts le nombre de compte au total sur la période donné et metrics.service.users sera plutot le nombre de ces comptes qui ont réellement utilisé le service (qui se sont donc connecté).
Là aussi, on peut avoir des différences notables dans les chiffres (certains comptes n’utilisant que très peu le service).

1 « J'aime »
11

Je me penche là, sur le metrique metrics.service.files.bytes

C’est simple quelque part, si la date de création du fichier n’est pas supérieur à la plage que l’on analyse (journée, semaine, mois ou année), on rajoute la taille du fichier.
Par contre, ce n’est pas tout à fait just: en effet, on a pas les fichiers qui ont existé et qui ont été supprimé depuis le moment où on scan nos répertoires.

Sur une plage d’une journée, l’erreur est très faible.
Par contre, sur une plage plus grande (mois ou année), la différence est loin d’être négligeable.

Est-ce que quelqu’un aurait un aglorithme qui permettrait de « corriger » un peu cette metrique en analysant les variations +/- des différentes journées déjà observé et mémorisé?

  • Est-ce que l’on note alors la valeur mesuré à l’instant T ?
  • Est-ce que l’on prend un sorte de valeur moyen de la période ?
  • Est-ce que l’on ajoute juste les delta positif d’un jour sur l’autre pour « mesurer » une période plus grande ?

Les idées sont ouvertes

12

Notons alors que la semaine, le mois et l’année ne peuvent donc se calculer qu’une fois entièrement effectuées pour ne pas compter un « user » plusieurs fois.

Alors non, ils sont calculables à tout moment de la période mais à condition de reprendre toutes les logs concernées (donc prévoir 6 semaines de rétention de log pour du mensuel). Et effectivement, le calcul est incomplet tant que la période n’est pas finie. Il est intéressant de mesurer où l’on en est à différent moment de la période. Par expérience, c’est trop frustrant de devoir attendre la fin de la période pour avoir les chiffres, il vaut mieux les voir monter doucement, ça rassure :wink:

Là aussi, on peut avoir des différences notables dans les chiffres (certains comptes n’utilisant que très peu le service).

Tout à fait, Mastodon en est un exemple flagrant :

13

Je me penche là, sur le metrique metrics.service.files.bytes

C’est typiquement un métrique « instantané » et « non re-calculable ». Impossible de reconstituer sa valeur, contrairement aux métriques calculables depuis les logs.

Quelle mesure de la période conserver ? De toute façon, aucune valeur ne sera absolument exacte mais ce n’est pas grave car la mesure est une évaluation qui permet d’estimer l’activité. Et dans cette optique, la dernière valeur est la plus intéressante car quand on regarde une période, ce que l’on veut estimer c’est la situation à sa fin :slight_smile:

Si l’on tient vraiment avoir une vision plus fine alors il faut multiplier les points de mesures. Avec StatoolInfos, on s’arrête à la journée car on veut rester dans l’estimation de l’activité et non pas faire de la métrologie comme avec Grafana :yum:

Et sinon, ce qui est bien avec les moyennes, c’est qu’elles sont calculables à partir des metrics collectés, donc autant les générer sans les stocker :innocent: