// j'ai modifié le sujet afin d'éviter de hijacker le thread original plus longtemps; désolé //
Le 26/08/2017 à 13:50, Francois Lafont a écrit : > Bonjour, > > Toujours par rapport à la logique de « substituer complètement la > métrologie au monitoring », comment est-ce que tu fais par exemple > pour la supervision d'une page d'un serveur Web ? Par exemple > typiquement avec le plugin Nagios "check_http" qui vérifie la > présence d'une regex ainsi que le temps de réponse ? > > Déjà, dans ce cas là, c'est la collecte d'une métrique faite sur > le serveur Web lui-même que tu utilises ? > > Auquel cas, c'est un > check du site web sur localhost qui est effectué ce qui n'est > sans doute pas aussi probant qu'un test fait sur un serveur > distant (le poller). Non ? Oui, tout à fait. Comme tu le dis, un check sur localhost, c'est pas l'idéal. Je fais deux choses sur ce point précis. - des checks internes (data collectée sur les serveurs, traitée par grafana) qui vont surveiller la santé de l'application (taux de 5xx & 4xx, nombre de process PHP actifs dans le pool, ...); ça nécessite quelques itérations pour placer les bon seuils d'alerte (par exemple, si tu place un nombre minimum de requêtes par seconde sur un site). Généralement ces alarmes n'ont pas la possibilité de me réveiller la nuit, sauf si cet aspect est critique pour le bon fonctionnement applicatif (un cluster qui n'a plus le quorum par exemple). - un/des check(s) externalisé(s) depuis au moins deux sources (pingdom, statuscake, uptimerobot, ..., en m'assurant que le deux ne soient pas sur le même cloud provider de préférence...) qui va checker le site du point de vue utilisateur final; je demande également aux clients de me fournir un ou plusieurs endpoint de test qui vont vérifier que l'application peut causer aux datastores dont elle a besoin (mysql, redis, elastic, ...) et autres, et qu'elle "va bien" (quoi que ça puisse vouloir dire). Ces points sont donc très custom et dépendent fortement de l'appli et de sa fréquentation. À quelques exceptions près, les checks externes sont généralement les seuls qui font sonner la sirène. La philosophie, c'est de n'être réveillé que s'il y a un impact pour l'usager final. Un node qui tombe dans un cluster galéra ou un des trois frontaux qui se meurt, ça peut attendre le lendemain. Par contre, si la mort d'un frontal fait que la charge fait monter le nombre de process PHP au dessus d'un seuil sur les frontaux restants, là ça sonnera. La difficulté de l'exercice c'est d'essayer d'être exhaustif sur les modes de défaillance pouvant impacter l'utilisateur final (ce qui peut être compliqué en fonction du site) et d'avoir les bons seuils. Être prévenu par le client que son site est HS, ça la fout mal :/ C'est très itératif. Quand j'ai un pépin imprévu, je place généralement une alerte grafana pour attraper le truc plus tôt la prochaine fois. A noter que chaque déploy (code ou infra) laisse également une trace dans la métrologie (il suffit d'un curl pour envoyer un point à influxdb). Ça aide pas mal à diagnostiquer d'éventuelles régressions. Le point noir que je vois dans mon approche actuelle par rapport à du monitoring est l'absence de corrélation. Si un panne survient, je suis bombardé par les alertes. Je rejoins ceux qui ont suggéré Alerta (et peut être Riemann). Mais il faut arriver à déployer ça sans SPOF et je n'ai pas trop envie de charger ma propre infra, sinon je vais finir par ne bosser que pour moi-même... Autre point noir: la grafanamania. Tes dashboards sont tellement pratiques pour amorcer un diagnostic qu'ils finissent par devenir indispensables. Si pour une raison quelconque tu ne les a plus sous la main, tu fais un léger whiteout du cerveau avant de trouver par quel bout prendre le problème. Mais ça s'applique probablement à la métrologie aussi. Tout ça a plutôt bien marché pour moi depuis le début. Mais c'est mon contexte (clients sur les doigts d'une main, une 50aine de serveurs physiques). J'ai eu aussi la chance de souvent arriver sur des projets "greenfield" et de bosser avec des clients/développeurs compréhensifs, compétents et sympas, donc c'était "facile". YMMV... A+ -- M _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
