Template Structure is Better???

[Pulyankote, Gopinath]

Jim,
	I have been wanting to move towards a directory based single config
file per host approach. Can you send me a sample config file for a host? 
Secondly, how did you go about creating hostgroups? Do you retain the
hostgroups.cfg file? Or can this also be added into the host config file? If
so how? 
Lastly, I had a question on contacts. There are 2 places where contacts are
defined, in services.cfg and hostgroups.cfg, which of these take precedence
when the host goes down? I have been asked to create host groups based on
site location, but my admins are based on type of host (network-admin,
windows-admin, unix-admin etc), so if I create a hostgroup based on site I
need to add a default contactgroup, if I add all the 3 contactgroups, will
the correct one get alerts based on what is defined in the services.cfg
file? I am sure it will work for a service outage, but what about a host
down situation? Hope you got what I am trying to convey!.
Thanks in advance
-Gopinath

-----Original Message-----
From: Carroll, Jim P [Contractor] [mailto:jcarro10 at sprintspectrum.com] 
Sent: Tuesday, January 14, 2003 8:43 AM
To: 'Tom DE BLENDE'; Shelfo Pete
Cc: nagios-users at lists.sourceforge.net
Subject: RE: [Nagios-users] Template Structure is Better???


Tom DE BLENDE wrote:
> 
> Hi Pete,
> 
> > "Shelfo, Pete" wrote:
> > 
> > I have been using Netsaint 7.0 for a long time and have built up
> > quite a large number of non-standard check_snmp statements that
> > require individual configuration per server.  With the new template
> > based format for Nagios 1.0 my services.cfg file is going to be huge
> > since each service statement is now about 10 lines instead of one
> > line condensed.  
> 
> I just moved from NetSaint 0.0.7 to Nagios as well. You have a point
> that the one line per service was easier to overview. However, don't
> let this scare you. Templates are really fun to play with! 

When I first started to sink my teeth into Nagios back in July/02, I glanced
at the 'old' method, shuddered quietly, glanced at the 'new' method,
pondered a moment, read the note that indicated everything which used the
'old' method would eventually use the 'new' method, and decided I didn't
want to be forced to completely redo everything after the 'old' method was
dropped.

Once I got the knack for seeing opportunities for making templates, the
actual keystrokes I needed to do was a major savings.

> > This is going to make maintenance very difficult
> > since I will have to browse tons of pages to find a service.   
> 
> Well, you can always use the search funtion in vi...

Do what I do.  In nagios.cfg, set:

  cfg_dir=/usr/local/nagios/etc/configs

and in that directory, create a separate .cfg file for each host.  That
config file will have the host config stanza as well as all the service
config stanzas.  Makes for a great way to quickly build out new host/service
definitions (ie, keep a copy of a 'baseline' config for each architecture
you wish to build out quickly, such as a SQL Server for Windows, or an
Oracle database server for Solaris -- just make sure you don't leave the
boilerplate files in that directory ending in .cfg, as Nagios will examine
them on startup).

> > I don't want to go back to the old "default" method since I am
> > completely transferring my system into the new format and don't want
> > to be outdated on the offset.
> 
> That was one of my motivations as well.> 

*shrug* I just saw it as The Way (tm).  ;)

> > Is there a way to manage custom statements like check_snmp and
> > NSClient Windows service check so that they are not out of control?
> > I see the benefit for template's but that seems to be limited to
> > environments that all the hosts in a network have similar settings.
> > If one server in a group does not follow a guideline then you have
> > to expand the group to individual hosts.  Can you do hostgroup
> > exemptions in a service check?  Can you issue multiple
> > check_commands in one service statement?
> 
> See it like this: directives for a specific host or service take
> precedence over template settings. And that is a true blessing! One
> example:
> 
> I monitor a lot of SQL servers, so I have a SQL service template like
> this:

[snip]

> So you see I can use everything from the template, and still change
> that one directive that does not fit in, in this case the
> check_command. 

Templates rock!  'Nuff said.  :)

> In my opinion the new template format beats the "Old Way". You just
> have to learn the little tricks and not just run the convert tool and
> leave it to that. Using that tool is a start that will save you a lot
> of typing work, but you should then try to exploit everyting that
> templates have to offer.

In a sense, one needs to step back, look at the bigger picture, and
recognize opportunities for economizing.

In the beginning, I too used hosts.cfg and services.cfg and added multiple
definitions where possible.  I've all but eliminated that.  It's more
verbose using my approach, but also affords greater nimbleness during
creation, and minimizes the scope of Fat Fingering a config file.  I've even
given thought to creating separate subdirectories for each hostname, and
creating tiny separate files for each host/service definition.  In a dream
world, there would be some sort of implicit recognition that, since the
service definitions are in the same directory as the host definition, they
must be referring to that host, and no other.  That would make adding new
services as simple as copying a tiny .cfg file from a boilerplate directory
to the hostname directory.  (Dependencies are a whole 'nother kettle of
fish.)

> And as far as the size is concerned... that's about the only setback I
> can see and was a bit my concern as well...

Given the choice of verbose/lucid vs. terse/cryptic, I'm all for verbose.
;)

> Kind regards,
> Tom

jc

> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL 
> security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> 


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users


-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving 
your online business a competitive advantage. Test-drive a Thawte SSL 
certificate - our easy online guide will show you how. Click here to get 
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en