Re: [FRsAG] Supervision haute fréquence d'application web
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.
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/
-- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier
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/
Bonjour, Le 27 mai 2016 à 12:01, Wallace <wallace@morkitu.org> a écrit :
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.
Nous sommes d'accord que la métrique la plus importante est le temps de réponse. Une grande majorité des applis web tournent derrière un serveur web (Apache ou NginX), qui est capable d'ajouter cette information dans les logs. Ainsi, on a de la métrologie sur 100% de la production et sans impact directement dessus. Olivier
On 2016-05-27 12:01, Wallace wrote:
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.
Dans le vrai monde des pauvres, haproxy est fabuleux, avec des logs de folie pour faire toutes les stats que tu veux, avec push vers du syslog de base. 10.102.164.98:57794 [27/May/2016:13:12:42.824] http-XXXX tcr_XXXX/tcr-web01 0/0/0/226/232 200 306305 - - ---- 18/2/0/0/0 0/0 {} "GET /rest/api/1/campaigns/0a40de4f............../summary HTTP/1.1" La tu vois que le backend a mis 226ms a repondre a la requete, qu'il y avait 18 connections au LB dont 2 pour ce backend ...... Avec du telegraf+grafana, ben c'est assez facile d'avoir du monitoring de la vraie vie, pas que de ton scenario connu, caché, etc. -- Thomas
participants (4)
-
Olivier Doucet -
Philippe Bourcier -
Thomas Pedoussaut -
Wallace