I configure nagios the same way.
I break up my configurations under various sub-directories under
../etc/cfgdir:
~nagios/etc/cfgdir/contacts/
~nagios/etc/cfgdir/commands/
~nagios/etc/cfgdir/services/
~nagios/etc/cfgdir/hosts/
Nagios is configured to include everything in ~nagios/etc/cfgdir/ and each
configuration file ending in .cfg is read into nagios.
Ideally I would want a comma-separated list of services run on a host
defined within the host stanza. In large server farms I find that we have
overall services (smtp, web, java, etc) running across many servers.
It's easier to define a host within a single config file (HOSTNAME.cfg)
and within the host stanza, configure it to be part of the "unix,smtp,ssh"
hostgroups. The smtp hostgroup automatically checks port 25. In the unix
hostsgroup, nagios automatically checks users, load, disks, procs, etc via
check_nrpe.
* If you have a custom service running on web12 only, define it within
web12.mydomain.com.cfg.
* If web12.mydomain.com has hardware failure and dies, change
web12.mydomain.com.cfg to web12.mydomain.com.DISABLED within
~nagios/etc/cfgdir/hosts/ and restart nagios. It's gone immediately
including the one-off service running on that host yet you still retain a
record that the host was there. Once the box is repaired, restoring it is
just as fast.
* If you need to add web12 to some java service your monitoring, after
you logon to web12 and get it configured, edit the web12.mydomain.com.cfg.
* If you add web13 and it runs the exact same services as web12, copy
web12.mydomain.com.cfg to web13.mydomain.com.cfg and change only hostname
and IP. Restart nagios. You're done.
Our group has found the advantages outweigh the annoyances. We also use
service groups to define service escalations for groups of services.
Regards,
Marty Combs
On Mon, 4 Feb 2008, Jonathan Mills wrote:
> I'm looking for some sanity checking of my logic here.
>
> What I've been doing is controlling services by mapping them to
> hostgroups. So, basically, I have a hostgroup for each type of
> service check, except for some basic checks that I lump together.
>
> Why? Because it makes it extremely easy to manage hosts. I create a
> host definition in a new file, i list all the hostgroups to which the
> host belongs, and the host then inherits all the service checks it
> needs. Adding and deleting hosts means only touching one file, the
> file containing the host definition.
>
> In practice it works great, but it has some real annoyances too. For
> example, my hostgroups look like servicegroups! It confuses people.
> I also have way more hostgroups than is desirable to be displayed in
> the web interface. And trying to map the logical groups or
> environments in my company is right out the window, since the
> hostgroups don't represent a logical or conceptual view of the
> environments within the company.
>
> What are other people doing? One thing I thought of that would help
> is if you could choose what hostgroups were actually displayed in the
> web interface. That way I could have logical groups based on
> departments or something shown as hostgroups, while service-specific
> hostgroups weren't displayed.
>
> Any comments would be greatly appraciated.
>
> Cheers!
> Jonathan
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Nagios-users mailing list
> Nagios-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting
> any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
