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