Re: [FRsAG] Entrepreneur de l’année : Votre vote peut faire la différence !

[nap]

2016-10-18 16:15 GMT+02:00 Guillaume Friloux via FRsAG :

> TRES grande deception!
> Deja, je n aurai jamais participe a ce vote en temps normal,
> mais ton mail m a convaincu de voter pour un autre...
>

Je dois bien avouer que le mail m'a donné la même impression. Ça n'a rien à
faire sur la liste un tel mail de marketing.

"Vous me connaissez, [bla bla marketing] ! " => bah non justement, et après
un tel mail j'ai juste pas envie non plus.


Gabès Jean


> --
> gυιℓℓαυмε ғяιℓσυx
>
>
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Solution de monitoring de sites web avec vue agrégée, url publiques/privées, support de proxy http, etc ?

[nap]

2016-10-18 11:56 GMT+02:00 cam.la...@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
___
Liste de diffusion du FRsAG
http://www.frsag.org/