Internet : Piwik : une alternative open source à Google Analytics
Posté par Johan Mathe. Modéré le 17 avril 2008.
La démonstration présente sur le site web est très prometteuse. Même si ce n'est actuellement qu'une version beta, elle est tout à fait utilisable. Un des atouts de Piwik est une API très riche et facilement utilisable (possibilité d'exporter les données dans des formats divers, d'exporter des graphes etc.)
![[en]](../images/en.png)
Piwik (2008 hits)-
Démonstration (2738 hits)
-
Documentation (263 hits)
![[fr]](../images/fr.png)
phpMyVisites (825 hits)
> Lire la dépêche (46 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #925960.
Run by 
Cette page a été générée par Templeet en 0.0772s (dont 0.0064 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Plastistik
J'ai commencé à bosser sur une alternative à BBCode/PhpMyVisites (que j'aime bien mais bon en production requêter du mySQL en live à chaque hit c'est suicidaire, mais cool le nouveau nom :) ), qui s'appelle Plastistik.
Le but est d'avoir un système qui permette de très nombreuses requêtes simultanées, mais en gardant un set de données exhaustif et complet. Pour ça le principe est simple : le compteur requête un script très léger qui va stocker les données brutes du visiteur dans un fichier texte (c'est très rapide donc même avec beaucoup de requêtes concurrentes on perds peu de données, mais on en perds un peu à cause des écritures concurrentes sur un même fichier, mais ça pourrait être amélioré en utilisant plusieurs fichiers différents), et un daemon ou un cron (selon le volume de stats que vous engrangez ou vous préférences) parse le fichier texte, interprète les données, et les insère correctement dans la base mySQL.
L'idée de base c'est que je voulais avoir des stats pour mes sites mais :
* webalyzer/awstats ça pue c'est moche c'est lent
* google machin/estat truc je veux pas qu'ils sachent des infos sur mes visiteurs, sans compter qu'ils pourraient foutre de la pub dans leurs marqueurs
* Phpmyvisites est pas adapté aux sites en production et mettra rapidement un serveur à genoux
Il me fallait donc un truc simple, léger, et qui sois puissant au niveau des possibilités de rapports perso. Pour la légèreté j'ai aussi pris en compte le temps de chargement du script et il est donc possible de recopier sans aucun problème le javascript du marqueur dans votre propre site voir au milieu du code html pour éviter de charger un élément externe.
Le code est ici :
http://svn.kd2.org/svn/misc/apps/plastistik/
Pour le moment seul le stockage des stats est fonctionnel, l'affichage je réfléchis encore à un système simple de créer des rapports personnalisé (plugins ? requêtes sql ?[1]). On stocke les données suivantes pour le moment :
Pour chaque visiteur :
* ip/hostname (ipv6 ready)
* pays
* navigateur, version, moteur de rendu (webkit/gecko/opera/trident/etc.)
* OS
* résolution écran
* heure de début de la visite
* heure de fin de la visite
* Langues acceptées par le navigateur
* Plugins acceptés par navigateur
Pour chaque hit :
* page visitée
* referrer
* temps de chargement de la page (facultatif)
* heure du hit
Voilà je pense c'est déjà bien comme données ça doit permettre pas mal de rapports sympas. On peux gérer plusieurs sites en mm temps et créer des marqueurs (tags) si on veux.
Si ça intéresse des gens, pour participer, critiquer, ou repiquer des idées, hésitez pas !
[1] l'idée c'est que les gens puissent créer leurs propres rapports comme ils le sentent et moi comme ça j'ai juste à en faire 2-3 bateaux et les autres les gens intéressés les feront :)
bohwaz.net
[^]Re: Plastistik
Je dis peut-être une ânerie, mais stocker les données selon le schéma de phpMyVisites permettrait de réutiliser leur interface, non?
[^]Re: Plastistik
C'est pas une ânerie :) J'y avais pas pensé mais je viens de regarder leur structure de table et je pense que leur schéma doit occasionner plus d'espace occupé que celui que j'ai choisi (le mien est sûrement encore améliorable mais il doit déjà limiter le stockage pas mal), mais ça aurait été une bonne idée si leur schéma était un peu mieux foutu.
bohwaz.net
[^]Re: Plastistik
et les logs apache ?
- ça éviterait du doublon de stockage ?
- ça a un format standard et utilisable ?
cela permet tout de même de découpler correctement la génération de données (efficacement en plus) / exploitation de ces données, non ?
[+] [^]Re: Plastistik
Alors alors les logs apache c'est cool mais t'y a pas accès en mutualisé, et c'est pas du tout un format standard ou utilisable, en fonction des versions d'apache le format est différent et chaque personne peut changer le format à sa guise... Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs. De plus ça stocke pas des informations très utiles pour certains comme : temps de chargement d'une page par le navigateur, résolution de l'écran, plugins installés, etc..
Sinon si tu veux juste utiliser les logs apache le petit soft qui s'appelle Visitors fait ça très bien. Mais là le but c'est pas ça, avoir un outil de stats indépendant permet des trucs bien plus intéressants (rien que par exemple avoir une archi distribuée sur plusieurs serveurs à la conf hétérogène) et apporte moins de contraintes.
bohwaz.net
[^]Re: Plastistik
Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs.
bin Piwik remplace l'activation des logs par des insertions en base MySQL, le même principe s'applique pour tuer un serveur non ? (en plus efficace)
avoir un outil de stats indépendant
Je ne vois pas ce qui empêche, d'avoir les logs apache au bon format et de demander aux gentils admins d'y pourvoir lorsque c'est possible.
En revanche, je vois très bien la charge ajoutée si,à chaque requête, des traitements applicatifs sont effectués. Comme contrainte sur le serveur, c'est un peu se tirer une balle dans le pied quand le site se fait /.er ou linuxfriser.
[^]Re: Plastistik
Mettre le service de stats sur la même machine que le site web c'est un peu une mauvaise idée :) Ca revient effectivement au même qu'activer les logs apache, et c'est pas une bonne idée. Les stats si ça marche pas c'est pas super grave, ça doit pas tuer ton service web pour autant, pour ça il faut séparer. Enfin ça part de la base que ton service web ne saturera pas avant le service de stats, ce qui n'est pas sûr du tout dans beaucoup de cas :)
bohwaz.net
[^]Re: Plastistik
Sans compter le petit problème qui est que les logs c'est MAL en production, ça tue tes serveurs.
Et si ton serveur se fait tuer, sans les logs, tu fais comment pour connaitre le coupable ?
[^]Re: Plastistik
Normalement, tu peux demander à syslog de transférer les logs à un autre serveur, non? Et tu dois pouvoir demander à Apache de logguer dans syslog. Et la boucle est bouclée. 'fin je crois.
[^]Re: Plastistik
Apache ne peut pas utiliser syslog pour les acces. Seulement pour les erreurs.
L'autre jour j'ai utilisé un wrapper perl pour faire ça et j'ai bien vautré tout un cluster :)
http://www.oreillynet.com/pub/a/sysadmin/2006/10/12/httpd-sy(...)
Avoir des access log est une obligation. Donc autant les utiliser pour faire des stats.
Mes deux cents.
[^]Re: Plastistik
Obligation ? Tu peux très bien les désactiver ça ne pose aucun problème, je comprends pas ce que tu veux dire là...
bohwaz.net
[^]Re: Plastistik
Il veut dire que lorsque au bout de 2 ans de services rendus, un serveur commence à déconner. Lorsque ton patron te demandera d'ou vient le problème tu lui répondra quoi ?
- Oh bah je sais pas.
Avoir des logs du serveur et les logs des acces est utile dans la mesure ou ça te permet d'identifier d'éventuels problèmes, au niveau du serveur, au niveau des accès de voir s'il y a des gens qui essayent de faire des DoS, tentent d'accèder à des endroits sur ton serveurs, font du crawling pour trouver des répertoires cachés (non indexés), requêtes mal forgées, que sais-je encore.
[^]Re: Plastistik
La loi t'oblige à conserver les logs d'acces un certain temps (1 ans) lorsque tu héberges des sites web en France.
http://www.ahinc.eu/files/CNIL_-_R_tention_des_donn_es_de_co(...)
Ensuite ne pas avoir de logs d'acces, c'est un peu comme ne pas traiter le cas d'une division par zéro. On peut toujours se dire que ça n'arrivera jamais.
[^]Re: Plastistik
Si tu te dis que conserver les access log d'apache suffit pour obéir à cette loi (dont je me fout totalement puisque j'habite pas en france) je te souhaite bon courage pour répondre à la requête "on voudrais l'ip et les infos du mec qui posté le billet machin disponible sur le blog http..." sur une plateforme ou tu gère des centaines (ou plus) de blogs... Ces infos doivent être stockées par l'application web elle-même, les requêtes judiciaires concernent les auteurs d'éléments publiés, pas les visiteurs (ou alors j'ai jamais vu le cas et je vois pas en quoi ça serait justifié). Si tu regarde du côté de la plupart des plateformes de publication qui ont une taille relativement importante, aucune ne stocke ni ne conserve les access logs (et pour cause, ça coûterait très cher).
Les logs d'accès ça peut se révéler utile sur une petite plateforme, des petits trucs, mais sinon y'a plein de raisons pour ne pas en avoir (surcharge machine, coûts de stockage, vie privée de tes visiteurs, utilité toute relative, etc.).
bohwaz.net
[^]Re: Plastistik
Je travaille sur des des machines à plusieurs millions de requêtes par jours qui font des access log.
On s'en sert pour débusquer les scripts plantés et toute sorte d'attaques (upload de script malicieux, utilisation de formulaires pour spammer) ...
Quand tu ne maîtrise pas le code des sites que tu héberge, il n'y a guère d'autres solutions qu'une analyse rigoureuse des access_log, maillog et ton ami netstat.
Par ailleurs, j'ai déjà eu a répondre a des requêtes judiciaires. Un gros grep leur suffit. Ils ont des gens capables d'analyser ça.
>> bzgrep -i viagra access_server.Tuesday.bz2 | wc -l
31
[^]Re: Plastistik
Voila la config que j'ai dans httpd.conf:
CustomLog "|/usr/bin/logger -p local1.info" debugdebug étant un format particulier de log. Et syslog redirige vers une autre machine.
Et aucun souci pour logger plus que quelques millions de hits par jour.
[^]Re: Plastistik
J'avais franchement été refroidis par le wrapper en perl que je cite plus haut.
Je vais essayer ça.
[^]Re: Plastistik
Question peut-être stupide (je ne connais pas la politique de développement du projet), mais pourquoi tu n'as pas fait tout ça dans le cadre du projet phpMyVisites au lieu de créer un nouveau projet?
Parce que maintenant on a 2 projets: Piwik et Plastistik, et quelque chose me dit que les 2 ont plutôt vu des évolutions complémentaires qu'incompatibles, non?
Un rapprochement des deux te paraît-il plausible?
(ça éviterait de choisir entre "bien" et "bien aussi"...)
[^]Re: Plastistik
Oh c'est juste que j'avais besoin d'un truc efficace dispo rapidement, et surtout fallait tester en vrai l'idée du fichier "tampon" pour voir si c'était réaliste (pas trop de perte de données, rapidité, efficacité).
C'est pas un vrai projet suivi comme peut l'être phpMyVisites, juste un petit truc comme ça, plus utile pour ses idées et concepts que son implémentation.
Mais effectivement ça serait bien que ça puisse servir à Piwik/phpMV si ça les intéresse tout du moins :)
bohwaz.net