configuration file layout (was: RE: Event Handlers are not runing or logging.)

[nagios at mm.quex.org]

On Fri, Aug 27, 2004 at 09:24:32AM +0200, Jan M. Jensen wrote:

> I have the same problems. I cannot find any documention on which
> definitions goes into which config-files.
> 
> Where do you define homegrown check-scripts, and where do you define
> homegrown eventhandlers.
> 
> So far I have tried several possible combinations, and ended up just
> defining everything everywhere, which is a not very elegant solution

It doesn't matter. Aside from the main configuration file read by
Nagios (typically called nagios.cfg), the CGI configuration file
read by the cgi scripts (typically cgi.cfg), and any files included
by nagios.cfg using "resource_file=foo" (typically resource.cfg),
all the other configuration files (cfg_file=foo or cfg_dir=foo)
are simply object configuration files.  "Objects" include host
and service definitions, contacts, escalations, hostgroups, time
period, contact groups, and some other things I can't remember.

You can put any combination of these in any file. You don't need
to define an object before you reference it, either. So it's really
up to you to decide what makes most sense.

I haven't seen any suggested layouts for large setups (aside from
the default settings). My current method is using several cfg_dir
statements to include directories:

/etc/nagios/config/all
/etc/nagios/config/company
/etc/nagios/config/company/location

Where "company" is the name of the company the hosts belong to, and
"location" is an abbreviated name of the location of the systems
(e.g. office or datacentre, or the name of the city, etc.).

Host definitions go under the "location" directory, in their own
files: web1.cfg, for example.

Service definitions go under the "company" directory, in their own
files: http.cfg, for example.  In each, I define a hostgroup for
the service check(s), and add the appropriate machines.  For some
things this is overkill (e.g. specialised services that will only
ever be on one machine), so I don't stick to it religiously, but
I do find it makes things easier to track, and it's easy to add
extra services - make a copy of an existing one and modify it.

I also make heavy use of templates, so in theory if we need to
change parameters for any group of hosts/services we can quite
easily.

I also include /etc/nagios/config, which has some notifications.cfg
for notification commands, and checks.cfg for host and service check
commands.  I occasionally place check commands in service definition
config files if they're not usable anywhere else, but that does tend
to make them harder to find when you need to tweak them.

That said, this method is by no means perfect. I'd be interested to
hear how other people set things up, if anyone has a wonderfully
elegant and manageable solution.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at 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