--nextPart1219916.ZjbVx1Hgck
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi all,
I've been lurking on this list for a few weeks and would like to introduce=
=20
myself and the project I'm working on ("MonAMI").
I've been working on a project to implementing a "universal" sensor. =20
Universal here doesn't mean it supports every device, but rather supports=20
different (hopefully "all") monitoring work-flows, so it can in principle=20
support many different monitoring systems. Support for new systems can be=
=20
added by implementing a new plugin.
Thanks to some help from Ethan, Nagios is amongst the different monitoring=
=20
systems MonAMI supports. It does this by internally emulating NSCA and=20
sending data to a suitably configured Nagios server. Current Nagios suppor=
t=20
within MonAMI is functional, but rather limited: a reported status is based=
=20
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 ab=
out=20
this, but I thought this would be an excellent time to introduce the projec=
t=20
and ask for your opinions.
MonAMI currently runs as a small, low-overhead daemon: scheduling its own=20
monitoring activity (e.g. supplying NSCA data) and accepting on-demand=20
monitoring requests for data (e.g. ksysguard). It also supports event-base=
d=20
monitoring (e.g. triggered asynchronously whenever an Apache server receive=
s=20
a request resulting in a 404). Tentative future plans for MonAMI include=20
adding support one-shot queries via an executable and some scripting-langua=
ge=20
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=20
implemented. I'd imagine they'd both likely be used under difference=20
circumstances. Both options have advantages and disavantages; here's the=20
ones I could think of:
Advantages of 1:
a. low overhead (no fork(), no context-switching, ...)=20
b. (aside from any issues with implementing the protocol) probably the=20
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=20
(inetd/xinetd + monami) to use two different port numbers.
c. status is limited to what can be described within the monami=20
configuration.
Advantages of 2:
a. (re-)uses existing NRPE framework.
Disadvantages of 2:
a. requires extra development (within MonAMI) that currently isn't presen=
t.
b. there is potentially large overheads in gathering data if MonAMI daemo=
n=20
isn't running. In practise, this might mean that (whilst not a requirement=
)=20
having the daemon running is (in practise) needed, so negate the first=20
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/
--nextPart1219916.ZjbVx1Hgck
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBFiTG5CvCDPV5t1VQRAtjAAJ9xmpCkP5ULdY9fmGbvFjCmuJIsAACdHEYi
AHITQVdw2HZFpmKDKIpanbI=
=SwG1
-----END PGP SIGNATURE-----
--nextPart1219916.ZjbVx1Hgck--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]