Re: [FRsAG] Supervision haute fréquence d'application web
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-
tcr_/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
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
Bonjour, Le 27 mai 2016 à 12:01, Wallace 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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
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-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/
>
signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
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/
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.
signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
La fréquence maximale de InfluxDB est celle par défaut, à savoir la μs. Le 26 mai 2016 à 13:59, Wallace a écrit : > > > Le 26/05/2016 13:31, Guillaume Tournat a écrit : > > Zabbix peut faire cela avec les scénarios web. > > > La fréquence maximale de Zabbix permet de descendre à un check toutes > les 1s voir moins? > > > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
Salut, la version gratuite de NewRelic te propose tout ça et bien plus, moyennant l'installation d'un module PHP. Je l'utilise depuis quelques années, sans problème ! Sinon, pour un besoin sur du plus long terme, je teste depuis peu l'association influxdb/grafana, et je trouve ça vraiment génial ! En bon sysadmin je ne sais pas faire de jolies interfaces rapidement, avec grafana c'est très facile, et l'insertion de donnée dans InfluxDB est on ne peut plus simple. Greg Le 26 mai 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 > > Dans un deuxième temps analyser le tout de manière graphique sur un > chart avec zoom. > > La problématique est que lorsque le cache expire toutes les 5 min (le > client ne veut pas plus de temps de rétention) l'application derrière > produit parfois des redirections sur lui même au lieu de délivrer la page. > On veut mettre en évidence ce souci et avoir des preuves précises. > > Merci pour vos pistes :) > > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Greg ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
Le 26/05/2016 13:31, Guillaume Tournat a écrit : > Zabbix peut faire cela avec les scénarios web. > La fréquence maximale de Zabbix permet de descendre à un check toutes les 1s voir moins? signature.asc Description: OpenPGP digital signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Supervision haute fréquence d'application web
Zabbix peut faire cela avec les scénarios web. > Le 26 mai 2016 à 05: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 > > Dans un deuxième temps analyser le tout de manière graphique sur un > chart avec zoom. > > La problématique est que lorsque le cache expire toutes les 5 min (le > client ne veut pas plus de temps de rétention) l'application derrière > produit parfois des redirections sur lui même au lieu de délivrer la page. > On veut mettre en évidence ce souci et avoir des preuves précises. > > Merci pour vos pistes :) > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
