Bonjour, Vous utilisez quoi en dehors de Google Analytics pour analyser votre trafic web ? Pour un site web à assez fort trafic (environ 1000 à 2000 hits/s) j'ai des contraintes de perf et d'espace disque pour stocker les données, mais aussi des contraintes de tracker : access log uniquement. J'ai fais le tour des outils : - logstash + kibana : outils géniaux, un plaisir de travailler avec pour collecter les données, mais 60GB de data / jour, c'est trop. Et il faut configurer Kibana de A à Z pour avoir des stats du genre "nombre de visites sur tel URL, heure par heure, trié par referer (ou user agent)". Kibana est un super outil pour voir que ça marche, ou pour voir quelques stats, mais on ne peut pas en faire un dashboard accessible aux marketeux. - piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié - Acunu + cassandra : prometteur, mais long à installer et configurer. Peu de retours donc pas trop envie de perdre du temps ... - OpenWebAnalytics : ne permet pas de tracker les logs. Tracker JS ou PHP uniquement. - awstats/webalizer/visitors : pas de système de stockage permettant des requêtes dynamique, parser trop lent, ... Bref si vous avez des retours ce serait intéressant ;) Greg
Bonjour, Le 8 oct. 2013 à 18:12, Greg a écrit :
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases. Cordialement Emmanuel Thierry
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s Au niveau réplication par contre (c'est bien la redondance), si t'a BEAUCOUP de modifications par secondes, tu peux taper les limites de MySQL (ou plutôt de tes disques et de ton cpu) et c'est là que le bas blesse. Cette la 5.6 fait automagiquement de la réplication multi-coeur, mais je pense après quelques tests que la version/fonctionnalité est encore un peu jeune. Sinon certes c'est long a mettre en place pour faire un truc un peu chiadé, mais kibana ça fait le café. Je ne vois pas pourquoi est-ce que les marketteux ne pourraient pas lire les graphes? My 20 cents Le 8 oct. 2013 19:54, "Emmanuel Thierry" <ml@sekil.fr> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec
la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases.
Cordialement Emmanuel Thierry
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir, Le 08/10/2013 20:11, Nathan delhaye a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s
o_0 ! 4To !! La, je dis bravo ! "vindiou d'bo***l à c*l !!" :) Mais c'est quoi la conf pour gérer un truc pareil ? @+ Christophe.
Bonjour, intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ? Le 8 octobre 2013 20:11, Nathan delhaye <contact@nathan-delhaye.fr> a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s
Au niveau réplication par contre (c'est bien la redondance), si t'a BEAUCOUP de modifications par secondes, tu peux taper les limites de MySQL (ou plutôt de tes disques et de ton cpu) et c'est là que le bas blesse. Cette la 5.6 fait automagiquement de la réplication multi-coeur, mais je pense après quelques tests que la version/fonctionnalité est encore un peu jeune.
Sinon certes c'est long a mettre en place pour faire un truc un peu chiadé, mais kibana ça fait le café. Je ne vois pas pourquoi est-ce que les marketteux ne pourraient pas lire les graphes?
My 20 cents Le 8 oct. 2013 19:54, "Emmanuel Thierry" <ml@sekil.fr> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec
la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases.
Cordialement Emmanuel Thierry
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut, Le 9 oct. 2013 à 08:29, Greg <greg-frsag@duchatelet.net> a écrit :
Bonjour,
intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ?
Je me rappelle un jour d'avoir hébergé sur une de mes machines un base MySQL assez large (pas autant que 6To), qui allais plus vite sur un core 2 duo @1.8Ghz sur un FreeBSD 9.0 que un linux gentoo super optimizé par les soins d'un admin chevronné. Pour info cette bdd étais utilisé par des malades de site type joomla ou autre machin super optimize(sic) pour defoncer une base de donnée avec 5 pages lues par secondes.... A la de dire que l'OS hébergeant MySQL est aussi important, c'est un pas que je ne sauterais pas, mais quand je vois la stabilité d'un freebsd quand on lui bourrine la tronche vs un linux (meme en deadline), je ne suis pas très étonné... Xavier
On a des bases de 4,5T sur du Percona Server (XtraDB), sur du Dell R620, Perc H710 + SSD en RAID 10, 32 Go de ram Pour répartir la taille (les SSD c'est pas gros) et les performances on fait du sharding sur plusieurs couples Master+Slave Benjamin Le 9 octobre 2013 08:29, Greg <greg-frsag@duchatelet.net> a écrit :
Bonjour,
intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ?
Le 8 octobre 2013 20:11, Nathan delhaye <contact@nathan-delhaye.fr> a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un
peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s
Au niveau réplication par contre (c'est bien la redondance), si t'a BEAUCOUP de modifications par secondes, tu peux taper les limites de MySQL (ou plutôt de tes disques et de ton cpu) et c'est là que le bas blesse. Cette la 5.6 fait automagiquement de la réplication multi-coeur, mais je pense après quelques tests que la version/fonctionnalité est encore un peu jeune.
Sinon certes c'est long a mettre en place pour faire un truc un peu chiadé, mais kibana ça fait le café. Je ne vois pas pourquoi est-ce que les marketteux ne pourraient pas lire les graphes?
My 20 cents Le 8 oct. 2013 19:54, "Emmanuel Thierry" <ml@sekil.fr> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et
avec la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases.
Cordialement Emmanuel Thierry
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Anciennement un mix innodb/myisam qui est maintenant full innodb. On utilise les build percona. Coté matos c'est du r610 bi-x5650, 96G de ram et des disques sas. La RAM c'est surtout important pour les index et les buffers MySQL afin de s'assurer que les disques ne soient pas trop sollicités. Mais comme dit Benjamin, la config de l'os est tout aussi important que la config de MySQL. Quand on atteint ces chiffres, il faut premièrement commencer a sharder si c'est possible (ça c'est côté applicatif et ce n'est pas applicable au problème présent) et surtout tunner tout ce que l'on peut des couches les plus basses aux plus hautes, c'est a dire MySQL. Le principal soucis c'est vraiment la réplication. Par exemple avec 300 mo de binlog par 5 minutes, la volumétrie devient vite un problème si on veut pouvoir conserver suffisamment d'historique pour intervenir. Le 9 oct. 2013 08:30, "Greg" <greg-frsag@duchatelet.net> a écrit :
Bonjour,
intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ?
Le 8 octobre 2013 20:11, Nathan delhaye <contact@nathan-delhaye.fr> a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s
Au niveau réplication par contre (c'est bien la redondance), si t'a BEAUCOUP de modifications par secondes, tu peux taper les limites de MySQL (ou plutôt de tes disques et de ton cpu) et c'est là que le bas blesse. Cette la 5.6 fait automagiquement de la réplication multi-coeur, mais je pense après quelques tests que la version/fonctionnalité est encore un peu jeune.
Sinon certes c'est long a mettre en place pour faire un truc un peu chiadé, mais kibana ça fait le café. Je ne vois pas pourquoi est-ce que les marketteux ne pourraient pas lire les graphes?
My 20 cents Le 8 oct. 2013 19:54, "Emmanuel Thierry" <ml@sekil.fr> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et
avec la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases.
Cordialement Emmanuel Thierry
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Peut-être qu'il serait intéressant de regarder du côté de MariaDB. La migration de MySQL vers MariaDB est facile car elle a été pensé pour être prête à être exécutée. Chez MariaDB tout est quasi identique à MySQL (c'est la même core team) tous les fichiers de données sont parfaitement compatibles, MariaDB peut fonctionner avec l'instance MySQL existante. Donc vos applications ne changent pas d'un seul Bit, et les performances sont immédiates. En plus des améliorations et de la supériorité des fonctionnalités, MariaDB bénéficie des apports de la communauté (Facebook, Twitter, Google et Percona), Par exemple sur l'exécution des requêtes qui est un énorme défi pour les applications à 100% sur le Web, MariaDB offre de sérieuses améliorations, notamment pour l'optimisation des sous-requêtes et des vues, à la fois plus rapides et homogènes. J'ai des exemples d'utilisateurs qui géraient de très importants volumes en Po, qui sont aujourd'hui bluffés par MariaDB. Véro Le 09/10/2013 10:21, Nathan delhaye a écrit :
Anciennement un mix innodb/myisam qui est maintenant full innodb. On utilise les build percona.
Coté matos c'est du r610 bi-x5650, 96G de ram et des disques sas. La RAM c'est surtout important pour les index et les buffers MySQL afin de s'assurer que les disques ne soient pas trop sollicités.
Mais comme dit Benjamin, la config de l'os est tout aussi important que la config de MySQL. Quand on atteint ces chiffres, il faut premièrement commencer a sharder si c'est possible (ça c'est côté applicatif et ce n'est pas applicable au problème présent) et surtout tunner tout ce que l'on peut des couches les plus basses aux plus hautes, c'est a dire MySQL.
Le principal soucis c'est vraiment la réplication. Par exemple avec 300 mo de binlog par 5 minutes, la volumétrie devient vite un problème si on veut pouvoir conserver suffisamment d'historique pour intervenir.
Le 9 oct. 2013 08:30, "Greg" <greg-frsag@duchatelet.net <mailto:greg-frsag@duchatelet.net>> a écrit :
Bonjour,
intéressant, avec quel moteur ? ARCHIVE ? et quel matériel ?
Le 8 octobre 2013 20:11, Nathan delhaye <contact@nathan-delhaye.fr <mailto:contact@nathan-delhaye.fr>> a écrit :
Certes... Pour avoir une instance de 6To (une des bases fait 4To) c'est un peu galère a administrer. Par contre t'est toujours obligé de sortir des tricks de l'espace pour faire des opé sans down la base. Mais ça fonctionne et ça fonctionne bien à 3000 write/s et 10000 read/s
Au niveau réplication par contre (c'est bien la redondance), si t'a BEAUCOUP de modifications par secondes, tu peux taper les limites de MySQL (ou plutôt de tes disques et de ton cpu) et c'est là que le bas blesse. Cette la 5.6 fait automagiquement de la réplication multi-coeur, mais je pense après quelques tests que la version/fonctionnalité est encore un peu jeune.
Sinon certes c'est long a mettre en place pour faire un truc un peu chiadé, mais kibana ça fait le café. Je ne vois pas pourquoi est-ce que les marketteux ne pourraient pas lire les graphes?
My 20 cents
Le 8 oct. 2013 19:54, "Emmanuel Thierry" <ml@sekil.fr <mailto:ml@sekil.fr>> a écrit :
Bonjour,
Le 8 oct. 2013 à 18:12, Greg a écrit :
> > - piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié
A la limite teste le... Contrairement à ce que l'on peut penser, MySQL sait gérer de grosses bases.
Cordialement Emmanuel Thierry
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 8 oct. 2013 à 18:12, Greg <greg-frsag@duchatelet.net> a écrit :
Bonjour,
Vous utilisez quoi en dehors de Google Analytics pour analyser votre trafic web ? Pour un site web à assez fort trafic (environ 1000 à 2000 hits/s) j'ai des contraintes de perf et d'espace disque pour stocker les données, mais aussi des contraintes de tracker : access log uniquement.
J'ai fais le tour des outils : - logstash + kibana : outils géniaux, un plaisir de travailler avec pour collecter les données, mais 60GB de data / jour, c'est trop. Et il faut configurer Kibana de A à Z pour avoir des stats du genre "nombre de visites sur tel URL, heure par heure, trié par referer (ou user agent)". Kibana est un super outil pour voir que ça marche, ou pour voir quelques stats, mais on ne peut pas en faire un dashboard accessible aux marketeux.
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié
- Acunu + cassandra : prometteur, mais long à installer et configurer. Peu de retours donc pas trop envie de perdre du temps ...
- OpenWebAnalytics : ne permet pas de tracker les logs. Tracker JS ou PHP uniquement.
- awstats/webalizer/visitors : pas de système de stockage permettant des requêtes dynamique, parser trop lent, ...
Bref si vous avez des retours ce serait intéressant ;)
Greg
Bonsoir, dans la liste des trucs "chers, mais qui font le café et le font plutôt bien", il y a Splunk. Nickel sur de gros volumes, produit des graphes marqueteux©®™ compliant… Maintenant il va te couter le salaire d'un mec payé à créer maintenir et manager tes confs logstash + kibana. -- Frédéric de Villamil / @fdevillamil I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net
Pour ma part vu les écarts entre Google Analytics et les logs files, on privilégie les logs files. D'une c'est facile à stoquer, ça se compresse très bien et surtout on a toutes les données. En effet quand un navigateur fait une requête, il a beau avoir tous les adblock, trackerblock, javascript bloqué il laisse quand même un GET dans les logs. Du coup des outils comme Awstats marchent super bien, testé et approuvé sur un site utilisée par toute les mères de France avec 3 millions de visiteurs par jour en pointe. Le delta pour ce site c'était de l'ordre de 20% en plus sur des trucs de bases comme des hits. Je parle pas de visiteurs unique tellement c'est une notion floue quand toute une boite est derrière des proxy et que les navigateurs bloquent les trackers dont GA. Ce delta sur les sites de nos clients varie entre 10% pour les sites grand publique à des presque 40% pour des sites high tech / geek où là on voit clairement que les gens utilisent en masse les bloqueurs de tracker. Du coup les logs sont bien plus fiables que les stats externes. Avec Piwik on a aussi des bons résultats mais uniquement quand on intègre son tracking en php dans le site et pas par un composant javascript. Et on a pas testé sur de la très forte charge, mais sur des sites avec un bon trafic ça passe sans soucis.
Hello, Le Tuesday 08 October 2013 à 18:12, Greg écrivait:
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié
C'est ce qu'il y a pour free.fr avec un mysql derriere, zero problemes et le dev principal de piwik est français et très accessible. Avec la conf nginx qui va bien: https://github.com/perusio/piwik-nginx tu mettras en prod assez rapidement. -- Auré
Bonjour, Merci pour vos indications. Je me suis mis à tester Piwik "sérieusement" :) - version Git - sur MariaDB 10.0.4 - Nginx -> syslog en json - syslog-ng central -> script d'import et je commence déjà à contribuer au projet qui me plait dans le sens où il sait bien faire de beaux dashboards, des graphs, bref une interface, et qu'il a de grosses lacunes bas niveau: schéma de base de donnée juste hallucinant pour un site à fort trafic, script d'import de log perfectible, parser PHP ... Hé bien avec 1M de logs par heure, ça tient, et c'est clairement le PHP le bottleneck. Il m'aura fallut autoriser PHP à consommer jusqu'à 2Go de mémoire par process (sick!). Là j'en suis a trouver un moyen pour diminuer le nombre de logs et à séparer les sites par autre chose que le vhost, parce que même si 1M de logs / heure ça tient, ça ne tiendra pas longtemps :) Greg Le 9 octobre 2013 13:32, Aurélien Beaujean <abeaujean@corp.free.fr> a écrit :
Hello,
Le Tuesday 08 October 2013 à 18:12, Greg écrivait:
- piwik : permet de lire les logs, mais interface en PHP/MySQL, et avec la quantité de donnée un moteur NoSQL serait plus approprié
C'est ce qu'il y a pour free.fr avec un mysql derriere, zero problemes et le dev principal de piwik est français et très accessible.
Avec la conf nginx qui va bien: https://github.com/perusio/piwik-nginx tu mettras en prod assez rapidement.
-- Auré
Le Friday 11 October 2013 à 15:28, Greg écrivait:
Hé bien avec 1M de logs par heure, ça tient, et c'est clairement le PHP le bottleneck. Il m'aura fallut autoriser PHP à consommer jusqu'à 2Go de mémoire par process (sick!).
Pour le cron qui tourne toutes les heures, c'est ça ?
Là j'en suis a trouver un moyen pour diminuer le nombre de logs et à séparer les sites par autre chose que le vhost, parce que même si 1M de logs / heure ça tient, ça ne tiendra pas longtemps :)
Ça fait 10 mois que ça tiens sur free.fr, j'ai juste la DB qui a des HDD SSD. -- Auré
participants (10)
-
Aurélien Beaujean -
Benjamin BILLON -
Christophe -
Emmanuel Thierry -
Frédéric de Villamil -
Greg -
Nathan delhaye -
veronique Loquet - AL'X Communication -
Wallace -
Xavier Beaudouin