[Nagiosplug-devel] Working on testcases

[Ethan Galstad]

On 14 Nov 2005 at 15:34, Ton Voon wrote:

> 
> On 14 Nov 2005, at 11:42, sean finney wrote:
> > On Mon, Nov 14, 2005 at 10:32:42AM +0000, Ton Voon wrote:
> >>
> >> Given the above definition, both failures should be UNKNOWN. I'm with
> >> Andreas on this. But there's Sean and Ethan on CRITICAL. So the
> >> voting currently stands at 2-2.
> >>
> >> If we go with CRITICAL, then this needs to be marked as an exception
> >> in the guidelines.
> >
> > i disagree that this would be an "exception", and has more to do with
> > individual interpretation of the two classes of errors.
> 
> Think of it as trying to "nail down the interpretation" :)
> 
> 
> > in the case that name resolution fails entirely, this would be  
> > indicative
> > of a problem outside the control of both the plugin and the remove  
> > service
> > being checked(maybe someone tripped over the nagios servers' cable).
> > in such a case, nothing can be divined about the ability to reach a
> > specified host, and the contact for the service is not the proper  
> > person
> > to notify.
> >
> > but... if the lookup operation succeeds (that is, it talks with a name
> > server, but was unable to find a specified host), then dns is working
> > "just fine" (or working, anyway).  in such a case, there is nothing
> > wrong with the plugin's attempt to prepare and/or execute the check,
> > but the host does not seem to exist.
> 
> Surely this is a problem with preparation?
> 
>    address = gethostbyname( hostname );
>    address is empty, can't get socket to connect
> 
> So there is no way check_http can execute the check. Going back to  
> the proposed definition:
> 
> "UNKNOWN is for invalid command args, or failures in other systems  
> preventing the plugin from performing the specified operation"
> 
> This would be a failure in another system (name resolution, which  
> could be files, DNS, LDAP, NIS+). So this must be UNKNOWN.
> 
> However, I'm willing to concede and define this particular scenario  
> as CRITICAL as long as it is documented in the guidelines (with  
> recommended library routine to use).
> 
> Ton


Name and address resolution problems aren't internal to the plugin.  
The plugin was still able to attempt the resolution/connection/check, 
but the system came back with an error.  Those types of problems and 
would probably be better suited for a CRITICAL state.  Its just my 
opinion, but I would shy away from using the UNKNOWN state too much. 

I would consider rewording the guidelines as follows:

"UNKNOWN is for invalid command args, or low-level failures internal 
to the plugin that prevent it from performing the specified 
operation.  Higher-level errors such as name resolution errors, 
socket timeouts, etc. are outside the control of plugins and should 
generally NOT be reported as UNKNOWN states."



Ethan Galstad,
Nagios Developer
---
Email: nagios at nagios.org
Website: http://www.nagios.org