Projet

Général

Profil

Development #12961

enregistrement de données statistiques supplémentaires

Ajouté par Frédéric Péters il y a plus de 7 ans. Mis à jour il y a plus de 7 ans.

Statut:
Nouveau
Priorité:
Normal
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
26 août 2016
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Club:

Description

Il y a des statitistiques dont on aimerait bien suivre l'évolution, par exemple le nombre de comptes enregistrés (#12803), le nombre d'inscrits à une catégorie d'annonces, le nombre de comptes fédérés avec telle application, etc. Comment fait-on ?

Historique

#1

Mis à jour par Benjamin Dauvergne il y a plus de 7 ans

Je vois tout de suite une différence avec les stats sur les demandes: on est pas ici intéressé par la quantité sur une période mais sur le total depuis le début (on pourra éventuellement être aussi intéressé par l'évolution au mois mais ce n'est pas souvent qu'on présente les choses ainsi) suite à des créations ou suppression de truc (compte, abonnement, fédération).

Sans passer par un énième stockage du type graphite je me dis que chaque application pourrait exporter un document de cette forme (je mélange volontairement des données authentic avec du corbo, c'est pour l'exemple):

{
   'types': {
      'accounts': 'Comptes',
      'subscription': 'Abonnements aux listes',
   },
   'events': [ 
   {
       'date': '2016-08-26',
       'type': 'accounts'
       'created': 10,
       'deleted': 20,
   },
   {
       'date': '2016-08-26',
       'type': 'subscription',
       'kind': 'email',
       'category': 'Enfance',
       'created': 10,
       'deleted': 20,
   },
   {
       'date': '2016-08-26',
       'type': 'federation',
       'application': 'Mandaye Médiathèque',
       'created': 10,
       'deleted': 20,
   },
  ]
}

Ce serait utiliser pour utiliser des tables du type:

CREATE TABLE accounts_events (date DATE, added INTEGER, removed INTEGER);
CREATE TABLE subscription_events (date DATE, added INTEGER, removed INTEGER, category FK(subscription_categories), kind FK(kind));
...

Par un outil d'import à la wcs-olap et dans bijoe on aurait un cube par type d'évènement (chaque type d'évènement ayant des dimensions/métadonnées différentes pour les filtres, ici catégorie et type de l'abonnement pour corbo ou nom de l'application pour les fédération). Ã la différence de wcs-olap cet outil fonctionnerait en mise à jour incrémental, les données étant déjà aggrégées au jour par l'application qui la publie.

Il faudrait que chaque application conserve assez de données pour pouvoir publier ces stats, i.e. corbo doit conserver des abonnements supprimés avec leur date de suppression par exemple.

Dans le fichier *.model pour bijoe l'outil décrira les requêtes pour faire les totaux sur la durée, i.e.:

SELECT month, sum(added) over (order by month) FROM (SELECT extract(month from date) as month, sum(added) as added FROM account_events GROUP BY extract(month from date));

Je ne pense pas qu'il soit actuellement capable de faire des requêtes si compliqués (il y a deux aggrégats en cascade) ça ne me parait pas trop compliqué à ajouter.

Formats disponibles : Atom PDF