Créer les services liés au Template...

[rlemble]

Bonjour,

Quand je coche "oui" pour cette option, elle revient toute seule à "non" après avoir cliqué sur "sauvegardé".

Est-ce normal ?

[rom]

Oui, elle est a non par defaut car tu ne veux pas appliquer les services lies au template des que tu modifies ton host ?
Ce probleme avant (la derniere RC) prenait tout son sens car le test d'existence d'un service pour un meme Host n'etait pas effectué. Donc tu pouvais appliquer plusieurs services avec la meme description a un Host, ce qui aurait fait crier a Nagios a la generation.

Donc now :
=> Creation de Template d'host
=> Creation de Template de Service
=> Attribution du Tpl de Service au Tpl de Host

=> Creation d'un Host reel
=> Etendre au Tpl de Service de l'Host Tpl

=> Modification de l'Host reel
=> Si coche oui, aucun effet
=> Si coche non, aucun effet

=> Attribution d'un nouveau Service Tpl au Host Tpl
=> Pas de modif de l'Host reel, pas de Sv Tpl dupliqué pour l'Host reel
=> Modification de l'host reel
=> Si coche oui, creation d'un nouveau Service reel basé sur le Sv Tpl
=> Si coche non, aucun effet

[rlemble]

=> Attribution d'un nouveau Service Tpl au Host Tpl
=> Pas de modif de l'Host reel, pas de Sv Tpl dupliqué pour l'Host reel
=> Modification de l'host reel
=> Si coche oui, creation d'un nouveau Service reel basé sur le Sv Tpl
=> Si coche non, aucun effet

Donc, si je veux modifier un paramètre du service template, je dois repasser à la main sur mes 300 hosts pour que la modif soit prise en compte !!!! On perd la moitié de l'intérêt des templates !

[rom]

Non, ce que je veux dire ce que le nouveau searvice Tpl ne sera pas applique a tous les Hosts issus du Host Template.

[rlemble]

Non, ce que je veux dire ce que le nouveau searvice Tpl ne sera pas applique a tous les Hosts issus du Host Template.

Ben justement !

J'ai un host Tpl "serveur_dell".
Je veux maintenant superviser l'espace disque sur les serveurs dell ( je ne le voulais pas au moment de créer les hosts ).
La logique voudrait qu'en ajoutant un service Tpl "espace disque" à l'host Tpl "serveur_dell", le service Tpl s'applique à tous les hosts créés grâce à cet host Tpl.
Sinon, il faut passer à la main sur tous les hosts et c'est ingérable dans un gros environnement de production.

[rom]

Oui dans ce cas la ca pose probleme, mais deux solutions :

1 => Pour faire ce que tu dis, nous preconisons plus une application des services via Hosts/HostGroups. Dans le cas present, tu crees ton service et l'ajoute rapidemment a tt ces confs.
Ce sont deux approches de configuration assez differentes, surtout pour les evolutions.

2 => (A venir), la possibilite de selectionner des elements et leur appliquer massivement un changement. Typiquement dans ta liste de Host, tu en prends 30, tu cliqueras sur "Massif Change" et tu pourras tous leur reapliquer un formulaire.

[rlemble]

Oui, les deux méthodes sont applicables, mais elles sont plus contraignantes que si on pouvait faire ce que j'explique plus haut.

N'est-il vraiment pas possible de faire en sorte que les nouveaux services Tpl appliqués sur des hosts Tpl soient directement appliqués sur les hosts créés à partir de ces hosts Tpl ?

[templuche]

N'est-il vraiment pas possible de faire en sorte que les nouveaux services Tpl appliqués sur des hosts Tpl soient directement appliqués sur les hosts créés à partir de ces hosts Tpl ?

Disons que ce n'est pas aussi simple que cela... Certains voudront que le service soit "dupliqué", c'est à dire qu'il y a un service créé pour chaque host et donc indépendant pour pouvoir mettre des valeurs seuils différentes. D'autres voudront au contraire que ce soit le même service appliqué à tous les hosts pour changer plus rapidement la configuration. Ce n'est pas simple, il n'y a pas qu'une seule vision et tout le monde n'est pas d'accord...

[rlemble]

Ok, je vais donc changer de philosophie et je vais appliquer les services sur des hostgroups.

Merci beaucoup pour votre aide et pour votre travail.
Oreon est vraiment un plus quasiment indispensable à Nagios.

[philuxe]

Voila sur quoi je me casse la tête aussi, tout ceci devient tres important qd on a bq d'hotes a monitorer, c'est mon cas et c'est vrai que les choix de départs sont hyper déterminant pour la facilité ou difficulté d'administration qui en découlera si on a fait les mauvais choix.

De mon point de vue ca manque d'ergonomie de ce côté la, j'allais presque plus vite avec mon fichier plat à vrai dire. :P

La grande question c'est comment regrouper les hosts ?

[rom]

Pour moi le seul vrai probleme a ce niveau est la presence de la base rrd physique associé au plugin et nommé par rapport au HostID_serviceID.

En effet, quand tout fonctionne et tout est configure, c agreable, de surcroit quand on a associé ses services a ses hostgroups. On a gagné du temps et une modif globale se fait assez vite, par le template de service ou le service lui meme.
Le probleme apparait quand on veut customiser un peu un service.. Ce n'est pas possible car la modif a etre applique a tous (cas du Sv basé sur un Tpl, appliqué a des HostGroups/Hosts)
La solution que je preconise est de creer une nouvel instance de ce service (duplication, etc..) et de l'attribuer que au cas qui nous interesse. Les mecanismes de non redondance de description etant traité on a un/n services independants et pret a etre customisé.
=> Avec les bases rrd physiques (issues du plugin graphique), on va perdre la base rrd et tt l'historique a partir du moment ou on va faire ses manips... tres embetant..
=> Avec perfparse, no problem, le service description etant le meme dans la base, le service est toujours alimenté. De plus, on pourra revenir a terme a une def de service "globale" et tout sera Ok.

Voila ce que j'imagine a terme :
- Disparition progressive a mon sens des bases rrd physiques (plugins graphiques).
- Le stockage dans perfparse uniquement des choses interessantes et ayant un interet dans le temps (possiblite de purger le cas echeant).
- Creation d'indicateurs de qualite de service pour resumer l'etat global de fonctionnement basé sur des indicateurs atomiques. (lecture courante, fichiers de log ou NDO)