Logging for critical messgaes

[Al Tobey]

On Thu, 2003-12-11 at 18:49, Subhendu Ghosh wrote:
> The size is related to LCD platform.  If you are running Nagios on a 
> platrofm that can support larger sizes for atomic writes in named pipes 
> and IPC you can use it.
> 
> http://article.gmane.org/gmane.network.nagios.user/6486/match=ipc+size
> 
> this is defined in include/objects.h
This can be discovered on your OS by grepping for PIPE_BUF in
/usr/include.

On Solaris: grep PIPE_BUF /usr/include/limits.h
Linux: grep PIPE_BUF /usr/include/linux/limits.h
Others: find /usr/include -type f -exec grep PIPE_BUF {} \;

More info on Solaris pipes:
http://docs.sun.com/db/doc/802-5893/6i9kci4r9?q=fifo&a=view

Maybe it'd be worthwhile to teach configure how to discover this value
and set it up instead of defaulting to the LCD.  Another option could be
to call flock() where possible and ignore the atomic write size.  This
is what I do in Nagios::Cmd.

-Al Tobey

> -sg
> 
> On Thu, 11 Dec 2003, Andy Harbach wrote:
> 
> > I am currently examining the use of Nagios to replace another monitoring
> > system. Most of the features I have seen in Nagios are excellent,
> > however we require extra information on services which are critical or
> > warnings (i.e. we need to see a lot more than a single line of output).
> > >From my understanding Nagios currently only shows a single line, and
> > truncates it if its length is over a specific number of characters.
> > 
> > My current plans are for our development team to return the extra
> > information required using the nrpe plugin, and then to log this
> > information to a file (e.g.
> > /usr/local/nagios/share/history/hostname-check-time-.html)
> > 
> > One way we have thought of doing this is to attempt editing of the
> > Nagios source code to include an extra macro (e.g. $DETAIL$) to hold the
> > information, which could then be used by a logging plugin (possibly
> > called using an event handler).
> > 
> > Another possibility is to ask the nrpe plugin (or Nagios) to do the
> > logging directly.
> > 
> > Does anyone have any thoughts on the viability of these suggestions -
> > would there be a better way to do this? Also if we were to implement
> > these features would there be a chance of getting them put in to the
> > main source tree for future releases?
> > 
> > I look forward to receiving any feedback.
> > 




** ** **  PRIVILEGED AND CONFIDENTIAL  ** ** **
This email transmission contains privileged and confidential information 
intended only for the use of the individual or entity named above.  Any 
unauthorized review, use, disclosure or distribution is prohibited and 
may be a violation of law.  If you are not the intended recipient or a 
person responsible for delivering this message to an intended recipient, 
please delete the email and immediately notify the sender via the email 
return address or mailto:postmaster at priority-health.com.  Thank you.



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/