Comment t'as fait pour saturer un NginX avec 0.5 pages / s ? ça envoit du paté normalement, surtout qu'en reverse proxy il y a pas de traitements bien lourds…
J'ai 0.5 page/s plusieurs heures après le pic qui a saturé Nginx, nuance. ^^
0.5 page/s c'est la vitesse de croisière.
Par exemple, à 21:02:51 (complètement pris au hasard dans mes logs, je ne sais pas si c'est le pire)
$ grep '21:02:51' error.log | wc -l
479
Les erreurs sont du types :
2013年04月03日 21:02:51 [alert] 20442#0: accept() failed (24: Too many open files)
2013年04月03日 21:02:51 [alert] 20442#0: accept() failed (24: Too many open files)
[-----8<-------- 149 ligne similaires ---------------------------------------]
2013年04月03日 21:02:51 [crit] 20442#0: *35565 open() "/var/lib/nginx/proxy/3/35/0000009353" failed (24: Too many open files) while reading upstream […]
[-----8<-------- l'ensemble se répétant plusieurs fois ----------------------]
Pendant ce temps là je lis :
$ grep '21:02:51' access.log | wc -l
109
Parfois en essayant d'accéder au site on obtenait un 503 Service Unavailable, l'erreur qu'on obtient habituellement quand le reverse proxy n'atteint pas le serveur après lui. Heureusement il suffisait de réactualiser aussitôt pour obtenir la page.
D'après ce que je lis ici où là ce n'est pas Nginx qui est en cause mais les limites d'ouverture de fichier simultanée configurées par défaut dans le système. Ces ulimit qui tacle Nginx quand le serveur prend des centaines de hit/s ! Mais ces limites ne sont pas là pour rien… Il faudra que je fasse des tests de charge avec différentes valeurs…
Tu cherches quelquechose de plus kikou qu'awstats ? Quelles infos cherches tu à mettre en valeur ?
Ben si quelqu'un saurait comparer webalizer et awstats, par exemple… Tu cites par défaut awstats, pourquoi celui-là précisément et pas un autre ?
En soit les infos que je cherche sont classiques : système d'exploitation, navigateurs, peut-être les fournisseurs d'accès, le pays voire la région (le lectorat est essentiellement en France), et j'aimerai une finesse par heure ! Ce qui m'intéresse, c'est d'analyse la popularité champignon que j'observe, pas d'analyser la durée (qui ne durera probablement pas).
Aussi je ne sais pas s'il est possible de croiser les logs… par exemple montrer sur le même graphique le taux de réussite et d'erreur : savoir déduire les réussites avec le log de hit et le log d'erreur, ou bien utiliser le log du serveur derrière le reverse proxy, qui ne reçoit logiquement que ce qui a pu passer le reverse proxy).
Idée d'analyse avancée : j'ai 2.3% des hits qui proviennent de GNU/Linux en 12h, ça descend à 2% après 24h et à 1.7% après 48h. Est-ce que cela veux dire que les linuxiens sont toutes des moules qui passent leur vie sur le net et lisent donc tout avant tout le monde ? ;)
J'ai la chance d'avoir sous la main un site qui était inconnu il y a deux jours, avec un lectorat neuf, de tout milieu et pas réputé pour sa technicité, et de faire des stats dessus… Bref, cette affaire me donne l'occasion de sonder la famille michu… ce qui peut être intéressant. Si je stabilise à 1.7~1.8% de linuxiens, c'est bien plus que ce qui est indiqué ici.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: quelles n'ymphos ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message Analyse statistiques de logs web. Évalué à 3. Dernière modification le 06 avril 2013 à 04:43.
J'ai 0.5 page/s plusieurs heures après le pic qui a saturé Nginx, nuance. ^^
0.5 page/s c'est la vitesse de croisière.
Par exemple, à 21:02:51 (complètement pris au hasard dans mes logs, je ne sais pas si c'est le pire)
Les erreurs sont du types :
Pendant ce temps là je lis :
Parfois en essayant d'accéder au site on obtenait un
503 Service Unavailable, l'erreur qu'on obtient habituellement quand le reverse proxy n'atteint pas le serveur après lui. Heureusement il suffisait de réactualiser aussitôt pour obtenir la page.D'après ce que je lis ici où là ce n'est pas Nginx qui est en cause mais les limites d'ouverture de fichier simultanée configurées par défaut dans le système. Ces ulimit qui tacle Nginx quand le serveur prend des centaines de hit/s ! Mais ces limites ne sont pas là pour rien… Il faudra que je fasse des tests de charge avec différentes valeurs…
Ben si quelqu'un saurait comparer webalizer et awstats, par exemple… Tu cites par défaut awstats, pourquoi celui-là précisément et pas un autre ?
En soit les infos que je cherche sont classiques : système d'exploitation, navigateurs, peut-être les fournisseurs d'accès, le pays voire la région (le lectorat est essentiellement en France), et j'aimerai une finesse par heure ! Ce qui m'intéresse, c'est d'analyse la popularité champignon que j'observe, pas d'analyser la durée (qui ne durera probablement pas).
Aussi je ne sais pas s'il est possible de croiser les logs… par exemple montrer sur le même graphique le taux de réussite et d'erreur : savoir déduire les réussites avec le log de hit et le log d'erreur, ou bien utiliser le log du serveur derrière le reverse proxy, qui ne reçoit logiquement que ce qui a pu passer le reverse proxy).
Idée d'analyse avancée : j'ai 2.3% des hits qui proviennent de GNU/Linux en 12h, ça descend à 2% après 24h et à 1.7% après 48h. Est-ce que cela veux dire que les linuxiens sont toutes des moules qui passent leur vie sur le net et lisent donc tout avant tout le monde ? ;)
J'ai la chance d'avoir sous la main un site qui était inconnu il y a deux jours, avec un lectorat neuf, de tout milieu et pas réputé pour sa technicité, et de faire des stats dessus… Bref, cette affaire me donne l'occasion de sonder la famille michu… ce qui peut être intéressant. Si je stabilise à 1.7~1.8% de linuxiens, c'est bien plus que ce qui est indiqué ici.
ce commentaire est sous licence cc by 4 et précédentes