Bonjour Philippe,
Merci pour ta réponse, effectivement dans d'anciennes vie les LB physiques me donnaient satisfaction sur ce point. Néanmoins en dehors du top 50 des pures players FR ou EU, peu d'entreprises ont les budgets pour du LB physique. Au mieux les clients ont du Nginx plus comme investissement. D'où la recherche de solution software à intégrer à ce niveau ou des sondes depuis l'extérieur. Merci
Le 26/05/2016 21:38, Philippe Bourcier a écrit :
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-l...
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/