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.)
Aller plus loin
- Piwik (57 clics)
- Démonstration (35 clics)
- Documentation (25 clics)
- phpMyVisites (54 clics)
# Piwik semble prometteur
Posté par daemontux . Évalué à 5.
Par contre, le site n'a pas l'air accessible en ce moment.
[^] # Re: Piwik semble prometteur
Posté par djibb (site web personnel) . Évalué à 4.
[^] # Re: Piwik semble prometteur
Posté par bichenoubi . Évalué à 5.
[^] # Re: Piwik semble prometteur
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: Piwik semble prometteur
Posté par Johan Mathe . Évalué à 1.
[^] # Re: Piwik semble prometteur
Posté par guix77 . Évalué à 2.
C'est joli Piwik.
Un des gros problèmes de PhpMyVisites était le gonflement de la base de données avec le temps, est-ce que c'est résolu sous Piwik ?
[^] # Re: Piwik semble prometteur
Posté par Maillequeule . Évalué à 1.
Si il y a eu quelques modifications à ce sujet en plus de la (superbe) nouvelle interface, je ne les trouve pas sur le site, et je suis preneur de l'information.
[^] # Re: Piwik semble prometteur
Posté par matthieu_aubry . Évalué à 4.
Concernant la taille de la DB, l'architecture rend possible le developpement d'un plugin pour supprimer des anciens enregistrements afin de purger les donnees non utilisees. Il reste a implementer :)
[^] # Re: Piwik semble prometteur
Posté par guix77 . Évalué à 1.
# Piwik
Posté par Christie Poutrelle (site web personnel) . Évalué à 3.
[^] # Re: Piwik
Posté par Fabien Engels . Évalué à 1.
[^] # Re: Piwik
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
[^] # Re: Piwik
Posté par Fabien Engels . Évalué à 0.
[^] # Re: Piwik
Posté par Christie Poutrelle (site web personnel) . Évalué à 1.
Et pourtant c'est pas faute de leur poster des patchs
(rien à voir avec la licence en fait)
[^] # Re: Piwik
Posté par Professeur Méphisto . Évalué à 1.
?? bah elle a quoi leur licence ? C'est du GPL tout à fait classique, non ?
# Plastistik
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 6.
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 :)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par Larry Cow . Évalué à 1.
[^] # Re: Plastistik
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par BAud (site web personnel) . Évalué à 4.
- ç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
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à -1.
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.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par BAud (site web personnel) . Évalué à 3.
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
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par erwan (site web personnel) . Évalué à 6.
Et si ton serveur se fait tuer, sans les logs, tu fais comment pour connaitre le coupable ?
[^] # Re: Plastistik
Posté par Larry Cow . Évalué à 1.
[^] # Re: Plastistik
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
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
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par lfmarante . Évalué à 3.
- 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
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
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
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 1.
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.).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Plastistik
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
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
Posté par lud77 . Évalué à 1.
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
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je vais essayer ça.
[^] # Re: Plastistik
Posté par Maclag . Évalué à 3.
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
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 2.
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 :)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
# Ça c'est cool
Posté par Snarky . Évalué à 10.
[^] # Re: Ça c'est cool
Posté par FabienC . Évalué à 1.
[^] # Re: Ça c'est cool
Posté par lfmarante . Évalué à 3.
[^] # Re: Ça c'est cool
Posté par Johan Mathe . Évalué à 5.
# Quid de piwik jobs
Posté par thibault jouannic . Évalué à 1.
Quelqu'un a des infos ? Combien de places ? Combien de temps ? Combien d'argent ? Etc ?
# Statistiques sur de longues durées
Posté par thibault jouannic . Évalué à 1.
Sur une journée, ça passe, sur une semaine, memory ou time limit. Et je vous dis pas pour une durée d'un mois.
(Pour les sceptiques, je vous met le lien vers les stats de mon site qui sont en accès public : http://visites.palsambleu.fr/)
Pour piwik, le problème semble persister, puisque tout déraille quand je sélectionne une période d'une semaine sur le site de démo :
http://piwik.org/demo/index.php?module=Home&action=index(...)
Suis-je le seul à avoir ce problème ?
(Sinon, c'est le seul truc que je reproche à phpmv. J'adore ce programme)
# Comparaison Google Analytics
Posté par goofy . Évalué à 2.
Mais comparer ton scipt php tueur de serveur ;) a google analytics c'est pas connaitre google analytics. A moins qu'il y est des plugins mais la demo est vraiment pauvre niveau fonctionnalités ...
Et mis à part le flash kicool lol je vois pas qu'elle est la valeur ajouté face à Awstats qui utilise les log d'apache.
Enfin bon je dis ça je dis rien hein ... :oD
[^] # Re: Comparaison Google Analytics
Posté par jve (site web personnel) . Évalué à 6.
Entre faire des requetes SQL qui défoncent les perfs à chaque hit et réutiliser les capacités de logs d'une architecture multithreadé dont la puissance a fait ses preuves, ya pas photos....
Après, rien n'empeche celui qui veut s'amuser d'enrichir les logs, de les insérer dans une base de données et de faire ses corrélations la dessus, mais pas sur un serveur de prod qui se prend 40mbps de traffic dans la tronche.
[^] # Re: Comparaison Google Analytics
Posté par Émilien Tlapale . Évalué à 2.
[^] # Re: Comparaison Google Analytics
Posté par Stéphane Gully (site web personnel) . Évalué à 2.
Ceci vient du faite que piwik utilise la méthode du tracker javascript (comme GA), ceci permet entre autre d'enregistrer des données comme la résolution des écrans (ou toute autre données décrivant le client que l'on peut récupérer en JS) qu'il est impossible de faire figurer dans les logs Apache.
Par ailleurs, tout comme google analytics le fait, rien ne vous empêche de dédier un serveur pour la gestion des stats. Votre serveur de prod est alors libéré, et votre porte monnaie plus léger ;-)
[^] # Re: Comparaison Google Analytics
Posté par eupalynos . Évalué à 2.
Ceci vient du faite que piwik utilise la méthode du tracker javascript (comme GA), ceci permet entre autre d'enregistrer des données comme la résolution des écrans (ou toute autre données décrivant le client que l'on peut récupérer en JS) qu'il est impossible de faire figurer dans les logs Apache.
awstats permet :
- de faire figurer ces informations dans les logs Apache
- d'effectuer des statistiques sur celles-ci
Voir : http://awstats.sourceforge.net/docs/awstats_faq.html#SCREENS(...)
[^] # Re: Comparaison Google Analytics
Posté par matthieu_aubry . Évalué à 2.
- vous controlez vos donnees et ne les cedez pas a google ou microsoft ou yahoo ou autre
- l'architecture a plugins permet d'ajouter les fonctionnalites souhaitees
- la presence d'apis completes et simple d'utilisation est unique et permet de reutiliser tres facilement les donnees calculees par piwik
- interface customizable, possibilite d'exporter les graphiques flash dans votre site/blog, etc..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.