[Nagiosplug-devel] Improved check_oracle (TS check with autoe xtend)

[Voon, Ton]

I think Joerg is right. My feeling is that the UNKNOWN status should only
appear on configuration issues such as an incorrect use of parameters or
values. This way when a service is being setup or changed, an UNKNOWN would
be raised, but no operation procedure would be invoked (eg paging). 

I can't think of another situation where UNKNOWN would be acceptable. 

Assuming the configuration is finalised, any status from then on should be
warning or critical.

This may cause a huge number of alerts raised, but that should be handled in
Nagios (as dependencies or whatever mechanism).

-----Original Message-----
From: Karl DeBisschop [mailto:karl at debisschop.net] 
Sent: Wednesday, March 24, 2004 12:48 PM
To: joerg.helmert at aracomp.de
Cc: Stanley.Hopcroft at IPAustralia.Gov.AU;
nagiosplug-devel at lists.sourceforge.net
Subject: Re: [Nagiosplug-devel] Improved check_oracle (TS check with
autoextend)


On Wed, 24 Mar 2004 13:19:37 +0100
joerg.helmert at aracomp.de wrote:

> > The I think new committed infrastructure for embedded Perl 
> > Nagios (ePN) support does precisely this ie if the plugin 
> > bombs out because of
> > 
> >  . compile time errors (probably because of the ePN environment)
> > 
> >  . run time errors
> > 
> > then UNKNOWN is returned (along with a dump depending on log 
> > level of the ePN).
> > 
> > I share the former writers concern about spurious alerts.
> > 
> > I canvassed this proposal (for new behaviour for ePN) with an 
> > RFC to both Nag-users and Nag-devel and possibly plugindevel 
> > as well, and got _no_ comments.

I don't recall seeing the question on plugin devel. I don't always
follow nag-* closely, so it would have been easy for me to miss there.

> > Personally, I have been running this way for some months now 
> > and much prefer it to the former nightmare of committing a 
> > new plugin only to find it notifies people unnecessarily 
> > (yes, I test; use the epn simulator etc but still things go wrong).

There is ample precedent in the plugins for this behaviour

> > Stanley Hopcroft

> But think of following:
> A plugin runs successfully and returns ok.
> You start to rely on.
> Now something occurs, causing a runtime error.
> (someone deletes a file needed or changes permission or filesystem
> gets corrupted or whatever)
> It is true, that the status of that check in reality is unknown.
> But for me the overal picture is more important.
> Something is going wrong after it was ok.
> I want to KNOW a status but only find out that the status is unknown.
> That is critical for me. 

Then you set nagios to page you for UNKNOWN. 

> I reread the development guidelines and found that I missed something:
> 
> 3 | Unknown | <snipped> or the plugin was unable to check the status
> of the given hosts/service
> 
> That clearly states, what you implemented.
> 
> My opinion is still different.
> 
> Implementing it UKNOWN is more polite and keeps operators sleeping...
> ...but if knowing what is going on is most important, lets wake them
> up. ;-)

It only lets operators sleep if that's how you have configured nagios.

--
Karl


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagiosplug-devel mailing list
Nagiosplug-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
is authorised and regulated by the Financial Services Authority. Egg
Investments Ltd. is entered in the FSA register under number 190518. 

Registered in England and Wales. Registered offices: 1 Waterhouse
Square, 138-142 Holborn, London EC1N 2NA.

If you are not the intended recipient of this e-mail and have received
it in error, please notify the sender by replying with 'received in
error' as the subject and then delete it from your mailbox.