Solution de monitoring de sites web avec vue agrégée, url publiques/privées, support de proxy http, etc ?
Bonjour à tous, Dans le cadre de la surveillance de sites internet, j'ai besoin de surveiller pour chaque site un jeu d'urls, le but est de vérifier à ce stade qu'elle renvoie un code valide (200, etc). Ex : site1.com = { http://www.site1.com, http://site1.com, https://admin.site1.com, etc } Là où je rentre dans du spécifique, c'est que : * Les urls d'admin ne sont dispo que sur notre réseau privé et pas d'internet (donc pas de solution SaaS) * Comme cela doit être hébergé en interne, la solution doit supporter de passer par un proxy http Squid pour accéder à internet * Du coup, en fonction de si la ressource est interne ou externe, utilisation du proxy ou pas. * Enfin, il me faudrait une vue agrégée pour mon cher infogéreur pour ne pas claquer 1 alerte par site (les sites sont hébergées sur la même plateforme) ; il ne veut pas avoir 70 incidents ouverts si la plateforme tombe mais 1 seul incident. Il n'a pas la capacité de relier des tickets les uns par rapport aux autres pour les regrouper... Cela donnerait qqc comme : { global: OK site1: OK site2: OK site3: OK ... siten: OK } Si un site passe KO, alors le statut global passe KO et génère une alerte { global: KO site1: OK site2: OK site3: KO ... siten: OK } Donc en synthèse, je veux pouvoir : * Surveiller des urls publiques / internes * Passer par un proxy ou pas pour accéder à ces urls * Avoir une vue détaillée (ie pour un site donné, le statut des différentes urls) * Avoir une vue agrégée (ie état global) * Avoir des alertes au niveau détaillée ou global mais pas forcément vers les mêmes équipes Est-ce que qqn connait un outil qui ferait tout ça ou faut-il que je le code rapidement ? Merci, Nicolas
Salut Si je m'abuses les solutions comme shinken proposent cette notion de vue agrégée. Chez shinken c'est via la notion des dépendances entre services (http://shinken.readthedocs.io/en/latest/08_configobjects/servicedependency.h...). Pour la partie proxy, je ne pense pas que ce soit un problème. Il te faut peut être définir 2 tests l'un qui passe via proxy, l'autre en interne et affecter le bon script de test selon l'appartenance de ton hôte. La tricherie est de définir un hôte non comme une machine à proprement parler (qui n'a pas de sens dans ton exemple) mais comme un site hébergé par une machine. Km
2016-10-18 11:56 GMT+02:00 cam.lafit@azerttyu.net <cam.lafit@azerttyu.net>: > Salut > > Si je m'abuses les solutions comme shinken proposent cette notion de > vue agrégée. Chez shinken c'est via la notion des dépendances entre > services (http://shinken.readthedocs.io/en/latest/08_configobjects/ > servicedependency.html). > > Si Shinken je conseille même carrément des bp_rles en auto (donc basées sur des expressions ou des templates, sinon c'est ingérable sur un gros volume), avec une forte "importance métier" sur la bp rule et une faible sur chaque service réel, qui eux mêmes utiliserait les service dependencies vers l'état général du apache/web globalement: * visuellement il aura accès à un indicateur général et a des arbres de dépendances dans la webui de shinken (s'il l'utilise, sinon Thruk est pas mal dans le domaine aussi) * il aura qu'une seule notification en cas de serveur web tombé, et dans l'UI il aura bien l'identification du problème source (donc le serveur web) et pas le milliard d'impact derrière (donc une UI avec 1 et une seule ligne: celle qui est utile ^^) > Pour la partie proxy, je ne pense pas que ce soit un problème. Il te > faut peut être définir 2 tests l'un qui passe via proxy, l'autre en > interne et affecter le bon script de test selon l'appartenance de ton > hôte. > Je tricherai même encore plus avec: * une variable _HTTP_PROXY définie comme * _HTTP_PROXY http_proxy=http://XXX:YYY@monserveur:3128 sur un template "service-externe" * _HTTP_PROXY http_proxy=" " sur un template "service-interne" Si ta sonde utilise la libcurl par exemple, tu pourras avoir une définition de commande qui ressemble à: command_line $_SERVICEHTTP_PROXY$ /bin/masonde $HOSTADDRESS$ $ARG1$ avec la possibilité d'avoir la liste des sites listés sur ton hôte de cette manières: [....] _SITES_INTERNES /site1,/site2 _SITES_EXTERNES /site3,/site4 Et avec 2 services qui utilisent le duplicate_foreach (en gros on va lister sur l'hôte des "choses" et pour chaque "chose" on va créer automatiquement un service associé qui sera disponible dans l'appel de la commande via la macro $KEY$) * le premier en template site-externes qui a un "duplicate_foreach" qui pointe vers le _SITES_INTERNES de l'hote (donc ici $KEY$ sera égal à /site1 pour le permier service, puis /site2 pour le second, etc etc) * le second en template site-internes qui pointe en duplicate_foreach vers _SITES_EXTERNES de l'hôte > > La tricherie est de définir un hôte non comme une machine à proprement > parler (qui n'a pas de sens dans ton exemple) mais comme un site > hébergé par une machine. > Tricherie je ne sais pas, car au final un hôte peux être ce qu'on veux. Ce n'est qu'un conteneur, rien de plus. Ici on va regrouper les sites suivant ce qu'on souhaite, et on aura plus qu'à lister les hôtes et dessus les sites sans avoir à définir de nouveaux services ou autre. Et là on peux commencer à gérer un gros parc, sinon si c'est un site par un site, autant prendre un partenariat avec une école pour être fourni en continu avec une armée de stagiaires qui vont faire de la saisie de texte/configuration à l'année ^^ > > Km > Jean Gabès
Le Tue, 18 Oct 2016 09:37:25 +0000, "Nicolas Steinmetz" <public+frsag@steinmetz.fr> a écrit :
ans le cadre de la surveillance de sites internet, j'ai besoin de surveiller pour chaque site un jeu d'urls, le but est de vérifier à ce stade qu'elle renvoie un code valide (200, etc).
Ex : site1.com = { http://www.site1.com, http://site1.com, https://admin.site1.com, etc }
Je fais cela avec XYmon, pas beau, mais efficace. Questions, conseils, conf spécifiques : n'hésites pas.
Le 22 octobre 2016 à 19:10, L.M.J <linuxmasterjedi@free.fr> a écrit :
Le Tue, 18 Oct 2016 09:37:25 +0000, "Nicolas Steinmetz" <public+frsag@steinmetz.fr> a écrit :
ans le cadre de la surveillance de sites internet, j'ai besoin de surveiller pour chaque site un jeu d'urls, le but est de vérifier à ce stade qu'elle renvoie un code valide (200, etc).
Ex : site1.com = { http://www.site1.com, http://site1.com, https://admin.site1.com, etc }
Je fais cela avec XYmon, pas beau, mais efficace. Questions, conseils, conf spécifiques : n'hésites pas. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, J'utilise également Shinken pour faire cette supervision. Par contre j'ai fait le choix de créé différents poller ! (Super fonctionnalité de Shinken) J'ai donc 1 poller par dmz + 1 poller externe ! On peut assigner des "poller_tag" aux host ou services pour définir quel poller utiliser pour faire tel ou tel check. Du coup j'ai des check effectué depuis un VPS chez OVH pour monitorer l'accès publique aux applis. On peut aussi en profiter pour faire quelques sondes pour vérifier que certaines URLs ne sont PAS accessible. En plus avec l'option "passive" seul le serveur "maitre" fait des requêtes vers les poller. Les poller n'ont besoin d'aucun accès vers le serveur "maitre". Du coup pas besoin de proxy externe à shinken :) Cordialement, Lucas
participants (5)
-
cam.lafit＠azerttyu.net -
L.M.J -
Lucas -
nap -
Nicolas Steinmetz