Kai Reese wrote:
Hey.
Maybe I'm missing the scope of things, but where are repetetive
iterations of PING a problem when you work with templates? I'm working
in a much smaller scope here than Mark and I've wondered about
repetetive service-entries as well, but I've come to the conclusion
that by using templates I can avoid most of the problems that these
multiple entries create, even more so when -as I understand is your
problem- the only thing that changes are the contacts.
I would however see problems with an overhaul of the way things are
addressed at this moment for matters of portability and upgradability.
I would imagine the hassle of defining 25*10 services is less than
migrating all your hosts and service-definitions to a new
setup/layout.
Well, my thought was not to eliminate contacts from the services
definition, but rather make it optional and pass the contact info from
the host definition. This way I can create a single service for all or a
large chunk of hosts with different contacts. If for some reason I want
to exclude a user from a specific service on which they are a contact
for the host, I would then override the inheritance from the host
definition to use a specific contact or contact group. I don't have any
particular need to do this so it seems a bit redundant to me to have to
specify it within my service configuration which also causes me to
configure the same service checks depending upon who should have access
to them.
Also, at this very moment, I'm wondering if services maybe support the
'contact' entries, since they also do work with the (undocumented)
hostgroup_name entries.
Wouldn't that solve most of your problems? Did I misunderstand your
problem at some point or is what I just wondered exactly the solution
you were asking to be implemented?
Kai
I wouldn't say it's a problem since I can work around it, but rather a
question as to why the implementation would not allow for this. Is there
a downside to making the contacts an inherited feature from the host and
having the contact option within the service definition become optional
rather than mandatory?
Todd
On 2/7/06, Todd Barbera <[EMAIL PROTECTED]> wrote:
Hi Mark,
I too had submitted an e-mail asking if passing the host properties along to
the services would have some detrimental impact, but I didn't receive a
reply. I agree that it would certainly make the services.cfg file much
simpler to maintain if you didn't have to set up multiple services in order
to create different views for various user groups. For instance, all my
hosts are setup for PING. If I want notifications sent out to specific users
for specific hosts, I have to have multiple iterations of PING in my
services.cfg file. If I try to add all contacts to PING, then the see every
host in the interface. This is not desirable since I only want them to see
the hosts and services for which they have a stake in. I think this is a
greater design question that may be best answered by Ethan, but if anyone
else has thoughts on the matter I'd be happy to hear the response.
Best regards,
Todd
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Garringer, Mark
Sent: Monday, February 06, 2006 9:07 PM
To: 'Nagios-users@lists.sourceforge.net'
Subject: [Nagios-users] Nagios Behaviors
This may be rather long, please bare with me.
I am currently running Nagios 2.0rc2 with 451 hosts and 1733 services. I've
recently upgraded from Netsaint (0.78b I think). During this upgrade I took
the time to reexamine my configurations to take advantage of the grouping
logic and regular expression features in Nagios. This help make the setup
much easier, faster, and more consistent than it ever was under Netsaint.
Kudos!
All of the following assumes that I'm doing things to the best of my
understanding, and if they are incorrect or misguided in some way, I'd be
more than happy to discuss the 'correct' way of implementing these features.
I'm starting to run into a few operational issues that I'd like to raise.
One of the most annoying is that RECOVERY should actually have a state for
EACH type of RECOVERY that can exist. That way, I'm not getting RECOVERY
notices for WARNINGS that I didn't get in the first place (because I don't
care about WARNINGS in most cases.). I should only ever get RECOVERY for
states which I've already indicated I want to receive their corresponding
original alert from.
The other is that HOST level notification/check_periods should be inherited
by any service being check on that HOST unless explicitly overridden.
For example, I have a host with 10 services on it (checking disk space in
various file systems, checking for certain named processes to be running)
and it has a HOST level notification_period (maintenance window) from
Saturday at 1800 till Sunday 1000. Every week. I don't want to, or need to
know about service changes during these times. I'm the user, and I'm
requesting a black out of notifications during this time. If there are
(still) problems after 1000 on Sunday, I do need to know about them or take
action. The best answers I can seem to find seem to be workarounds that will
cause me more overall upkeep and/or are counter to the whole idea of using
grouping logic to begin with.
Creating a separate, non-dynamic cron offshoot to take care of this for me
while functional requires me to basically go and define another list of
items (and upkeep them) to deal with and is completely external to Nagios.
Defining each service individually so that they all can have 1 host assigned
to them so they can have different maintenance windows as needed is totally
against the grouping logic and allows again for much easier divergence from
a set standard. Having 25 linux machines all in a linux host group because I
want to check 10 common services rocks. However, not all 25 servers will
have the same (or even overlapping) maintenance windows, so creating 25*10
separate service entries instead of just 10 sucks eggs. Maintaining the
maintenance window at the host level makes perfect sense to me.
Creating more host groups doesn't seem like any better of a solution and
will just make things more difficult to find under the Hostgroup sections of
the web display.
By not understanding something am I trying to use this in a way which it was
never intended? This seem like a pretty logical feature to me, of course.
Can anyone offer me advice?
Thanks!
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
_______________________________________________
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: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
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
