Delurk and some questions

Paul Millar p.millar at physics.gla.ac.uk
Wed Dec 20 13:50:58 CET 2006


Hi all,

I've been lurking on this list for a few weeks and would like to introduce 
myself and the project I'm working on ("MonAMI").

I've been working on a project to implementing a "universal" sensor.  
Universal here doesn't mean it supports every device, but rather supports 
different (hopefully "all") monitoring work-flows, so it can in principle 
support many different monitoring systems.  Support for new systems can be 
added by implementing a new plugin.

Thanks to some help from Ethan, Nagios is amongst the different monitoring 
systems MonAMI supports.  It does this by internally emulating NSCA and 
sending data to a suitably configured Nagios server.  Current Nagios support 
within MonAMI is functional, but rather limited: a reported status is based 
on any single numerical data with WARNING and CRITICAL "water marks".

I'm looking at adding NRPE-like support.  I have some ideas on how to go about 
this, but I thought this would be an excellent time to introduce the project 
and ask for your opinions.

MonAMI currently runs as a small, low-overhead daemon: scheduling its own 
monitoring activity (e.g. supplying NSCA data) and accepting on-demand 
monitoring requests for data (e.g. ksysguard).  It also supports event-based 
monitoring (e.g. triggered asynchronously whenever an Apache server receives 
a request resulting in a 404).  Tentative future plans for MonAMI include 
adding support one-shot queries via an executable and some scripting-language 
native interfaces.

I think there are two ways of providing NRPE-like support within MonAMI:
  1. extend the existing Nagios plugin to provide NRPE functionality;
  2. provide a mechanism for using MonAMI results within the existing NRPE
	framework.

These aren't mutually exclusive options: support for both options can be 
implemented.  I'd imagine they'd both likely be used under difference 
circumstances.  Both options have advantages and disavantages; here's the 
ones I could think of:

Advantages of 1:
  a. low overhead (no fork(), no context-switching, ...) 
  b. (aside from any issues with implementing the protocol) probably the 
quickest and easiest to implement.

Disadvantage of 1:
  a. requires running the MonAMI daemon.
  b. if also using "native" NRPE, this would require the two daemons 
(inetd/xinetd + monami) to use two different port numbers.
  c. status is limited to what can be described within the monami 
configuration.

Advantages of 2:
  a. (re-)uses existing NRPE framework.

Disadvantages of 2:
  a. requires extra development (within MonAMI) that currently isn't present.
  b. there is potentially large overheads in gathering data if MonAMI daemon 
isn't running.  In practise, this might mean that (whilst not a requirement) 
having the daemon running is (in practise) needed, so negate the first 
disadvantage of option 1.

So, I was wondering what people's feeling were, here.

Cheers,

Paul.

PS if people are interested, the project is available here:
  http://monami.sourceforge.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20061220/6b0e6c2b/attachment.sig>
-------------- next part --------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list