Template Structure is Better???

[Carroll, Jim P [Contractor]]

I can send you a sample config file off-list.  (I just not realized after
doing a bit of administrivia, that I really should carve up hostextinfo.cfg
and put the relevant chunks into the hostfiles.)

Yes, I still use the hostgroups.cfg file.  There's no obvious way (to me) to
do so.  Off the top of my head, I can't think of any other place where
you're required to reference multiple hosts in a single stanza.

On contacts (and this is wild speculation, so perhaps someone else can
confirm/deny):  In the trivial case, if a service goes down, I get
notification that that service is down.  In the trivial case, if a host goes
down, I get notification that that service is down, but I do *not* get
inundated with notifications for all the services defined on that host.

If I were to extrapolate based on that, I would say that if the service gets
down, the contact for that service would be notified, and if the host goes
down, only the contact for that host would be notified.  I'm uncertain of
whether the logic is in place to detect whether someone who is listed as a
service contact but not a host contact should be notified regardless.
Again, take the trivial case:  If I'm listed as the host contact and you're
listed as the service contact for 30 services on that host, I'll get 1
notification when the host goes down; do you really want 30 notifications
that all your services are down?

Also, stop to think about roles and responsibilities.  If you're responsible
for the database and I'm responsible for the host, do you really want to be
notified that the database is down, but there's absolutely nothing you can
do until the host is up again?  And looking at it from my POV:  Do I really
want you asking me every 5 minutes, "Is it up yet?  Is it up yet?"  And once
the host is back up and (let's say) the database comes back up smoothly, do
you really want to have been awake from 1:00am to 4:00am just to discover
that there's absolutely no reason why you needed to be up to begin with?  If
the database fails to start, you'll get your notification soon enough, no
need to worry about that.  ;)

If someone on this list disagrees with this logic, indicating that yes, the
DBA should be notified that the host is down, regardless of whether or not
they can be effectual, great:  Just show me how I can grant the DBA a view
of the host *without* having the ability to acknowledge an alert, or
schedule/cancel downtime, etc, *without* having to resort to adding
individual users to cgi.cfg.  (This is pretty much a question I recently
asked on this list, without any feedback.)

I'm not sure I adequately answered your last question, but I hope it gives
you food for thought.

jc

> -----Original Message-----
> From: Pulyankote, Gopinath [mailto:Gopinath_Pulyankote at affymetrix.com]
> Sent: Wednesday, January 15, 2003 11:01 AM
> To: Carroll, Jim P [Contractor]
> Cc: nagios-users at lists.sourceforge.net
> Subject: RE: [Nagios-users] Template Structure is Better???
> 
> 
> 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: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en