Development #37576
Configuration automatique de matomo des instances multi-collectivités
0%
Description
(parce que ça ne fonctionne pas encore, par exemple avec Chambéry en test #37297)
- Agrégation des statistiques de fréquentation de l'agglomération et des villes sur un seul "site" matomo.
C'est un effet de bord qui est constaté quand l'agglomération s'inscrit en premier et qui est finalement profitable puisqu'il permet d'avoir des statistiques globales mais également restreintes à condition de créer des "segments" pour filtrer sur les instances. (https://matomo.org/docs/segmentation/)
- Création d'un compte "utilisateur" matomo pour chaque instance pour bénéficier d'une variables "matomo_logme_url" sur chacun des sites.
Actuellement les nouvelles inscriptions écrasent le mot de passe de l'utilisateur matomo utilisé aussi par les autres instances.
- Pour les multi-collectivités configurées manuellement (ex: Tours), si on bascule sur la configuration automatique (pour ne plus à avoir à gérer les accès comme dans #37413) alors ils perdront les ancienne statistiques d'un des deux sites.
- Il existe un module service web "SegmentEditor" pour définir les segments.
Cependant, il n'est pas aussi souple que "SitesManager" et il faudrait alors récupérer tous les segments dans un XML via un premier appels webservice (https://developer.matomo.org/api-reference/reporting-api#SegmentEditor)
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Lié à Development #31778: intégration matomo ajouté
Mis à jour par Frédéric Péters il y a plus de 4 ans
C'est un effet de bord qui est constaté quand l'agglomération s'inscrit en premier et qui est finalement profitable
Je zapperais juste ça, que la configuration automatique soit un hobo = un matomo, ça me semble éliminer toute complexité.
Mis à jour par Thomas Noël il y a plus de 4 ans
Frédéric Péters a écrit :
C'est un effet de bord qui est constaté quand l'agglomération s'inscrit en premier et qui est finalement profitable
Je zapperais juste ça, que la configuration automatique soit un hobo = un matomo, ça me semble éliminer toute complexité.
Je crois qu'en faisant cela, on élimine la possibilité dans Matomo d'agréger les stats pour "une métropole + ses villes" (Matomo ne sait pas agréger plusieurs sites, me disait Nicolas, en parcourant l'interface rapidement j'ai l'impression que c'est effectivement impossible).
Mis à jour par Frédéric Péters il y a plus de 4 ans
Oui, et je pense que ce n'est pas bien grave. Que si jamais ça se trouve être demandé il est toujours temps de passer en configuration manuelle côté villes pour logguer vers les deux matomo. (et si la demande est récurrente, que ça deviennen une option standard des hobo secondaire : également logguer vers le matomo de l'hobo primaire).
Mis à jour par Thomas Noël il y a plus de 4 ans
Frédéric Péters a écrit :
Oui, et je pense que ce n'est pas bien grave. Que si jamais ça se trouve être demandé il est toujours temps de passer en configuration manuelle côté villes pour logguer vers les deux matomo. (et si la demande est récurrente, que ça deviennen une option standard des hobo secondaire : également logguer vers le matomo de l'hobo primaire).
Ça me va.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier 0001-matomo-manage-secondary-instances-37576.patch 0001-matomo-manage-secondary-instances-37576.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
- Ne traiter que les services primaires (sur un hobo secondaire, les services de la ville passent en primaire). D'une pierre deux coups, on récupère un tenant différent pour chaque instance (plus d'écrasement de mot de passe).
J'en ai profité pour décorréler l'ajout d'un site de l'ajout des URLS à monitorer afin de permettre l'ajout de nouveaux services en désactivant puis re-configurant matomo.
(mea cvlpa, j'ai traité ce second point dans ce ticket parce qu'avec ma première approche ça me bloquait pour tout agréger sur un seul site)
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Fichier 0001-matomo-manage-secondary-instances-37576.patch 0001-matomo-manage-secondary-instances-37576.patch ajouté
J'ai finalement déplacé le second point dans #37614, désolé pour le bruit.
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Si je comprends bien le soucis initial, c'est que get_tenant_name_and_public_urls, dans l'Hobo du Publik secondaire, pouvait retourner comme nom de tenant celui du portail usager du Publik primaire (et que donc Publik primaire et secondaire se trouvaient se marcher sur les pieds pour la "propriété" du Matomo), c'est bien ça ?
Mis à jour par Nicolas Roche il y a plus de 4 ans
Oui, get_tenant_name_and_public_urls renvoyait pour tenant_name toujours le nom de domaine de la première instance WCS enregistrée.
Cet identifiant étant ensuite utilisé pour récupérer le "site" matomo, les deux instances Publik pointaient systématiquement sur la même instance matomo.
Ce n'était pas voulu, le fonctionnement avec multi-publik n'avait pas alors été envisagé.
Mis à jour par Nicolas Roche il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit dc55cfa0909737cee05f830decaf6b4d5ca4da2d
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date: Tue Nov 12 20:49:22 2019 +0100
matomo: manage secondary instances (#37576)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
matomo: manage secondary instances (#37576)