Nagios Behaviors

[Todd Barbera]

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 <todd_barbera at wgbh.org> 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: nagios-users-admin at lists.sourceforge.net
>>[mailto:nagios-users-admin at lists.sourceforge.net] On Behalf
>>Of Garringer, Mark
>>Sent: Monday, February 06, 2006 9:07 PM
>>To: 'Nagios-users at 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 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
>  
>




-------------------------------------------------------
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 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