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