Bonsoir,
Plutôt que de faire du monitoring passif, c'est quand même plus
intéressant de faire du monitoring actif (ie: sur le vrai traffic de
prod).
Et plutôt que d'utiliser un module côté serveur, tous les bons
Load-Balancers commerciaux (ie: Zeus ZXTM, maintenant Brocade Virtual
Traffic Manager et F5 BigIP (à ma connaissance, les autres marques ont
encore un peu de travail sur ce point, mais je ne les ai pas toutes
testées)) te permettront de faire du monitoring de tout ce qui se passe
en live derrière, avec donc les stats que tu voudras et la possibilité
de pousser dans du InfluxB/graphite (via syslog), et ses amis. Perso, je
l'ai fait pendant des années sur de très grosses prod... un billet sur
le sujet ici :
http://labs.criteo.com/2013/05/monitoring-your-web-services-latency-on-the-load-balancer-side/
L'avantage par rapport à une solution software côté serveur c'est :
- le CPU des LBs est généralement très disponible... autant
l'utiliser;
- j'aimerais bien voir la gueule du monitoring côté serveur quand
celui-ci "prend cher" (ie: 100% CPU), même temporairement;
- on peut prouver à un dev/client que son code se comporte pas comme
il devrait entre 2 versions, même si ses propres compteurs sur le
serveur disent l'inverse (ie: par exemple lors d'une garbage collection
(quand on travaille à la milliseconde près, tout se voit));
- si tu as plusieurs services, clients, un besoin temporaire, tu peux
activer ces stats "on demand", sans avoir à toucher à la prod ou aux
serveurs des clients derrière, plutôt pratique;
- les gens du HFT (high frequency trading) font aussi comme ça (plus
précisément, ils sniffent le réseau et mettent une machine dédiée au
monitoring (genre Corvil), mais c'est la même idée que de le faire sur
les LBs... ne pas toucher aux serveurs).
Après, c'est la solution du riche, mais bon quand HTTP c'est ton métier
et que tu veux ce genre de features, je ne pense pas que le prix d'un
peu de matos soit un problème.
Cordialement,
Philippe Bourcier
On 2016-05-26 12:04, Wallace wrote:
Le 26/05/2016 11:57, Michel blanc a écrit :
Le 26/05/2016 à 11:13, Wallace a écrit :
Bonjour,
Je cherche une méthode simple (logiciel ou scripts) pour superviser
sur
quelques heures une page web.
Les besoins sont :
- récupérer la réponse http et si 30x donner la destination
- mesurer le temps de réponse
- mesurer le temps de first byte
- récupérer des champs dans les header http
- faire tourner cela toutes les secondes et les stocker en base ou
fichier à plat
Hello,
Est-ce que tu veux scripter un client HTTP, ou sniffer le traffic ?
Dans le premier cas, est-ce qu'un truc du genre:
while true; do curl -fsw
"%{http_code};%{time_starttransfer};%{time_total};"
http://www.google.fr
-o /dev/null -D /tmp/head && grep 'Cache-Control:' /tmp/head; sleep
1; done
(mind the CRLF & adjust)
ferait l'affaire ?
Pas mal du tout simple et efficace :)
Si tu tourne sous nginx, tu peux aussi changer le log format et
avoir
(presque) toutes ces infos dans le log.
C'est une idée, mais le but est de mesurer le tout en dehors de la
plateforme. On pourrait au mieux le mettre sur le load balancer.
Dans le deuxième cas, si c'est pas du https, un tcpdump peut le
faire
mais il faudra coder sérieux derrière pour coller les métriques
dans,
par exemple influxdb et visu avec grafana. Il doit exister des
outils
pour logger des flux HTTP mais je ne vois pas
(https://github.com/buger/gor avec --input-raw-track-response peut
être
? Pas sur que tu aies la métadata qui t'intéresse avec).
Là pour le coup vu le trafic ça risque d'être énorme en volume à
gérer.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
