Nagios Support Forum

--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]