monit-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nagios Integration


From: Martin Pala
Subject: Re: Nagios Integration
Date: Thu, 20 Feb 2003 23:38:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9

Jan-Henrik Haukeland wrote:

Russell Adams <address@hidden> writes:

[About a Central monit app]
Depends on how complex you want monit to get. With a central server
administrating remote systems over the network, you get network
security issues.

My first impulse is to use rsync or CVS in the "gold server" mentality
to push out configs. As far as start/stop/restart multiple machines, with
proper ACL's on the local monit webserver, you could use wget from a
single central machine to script remote actions.

An aggregate status for all monits would be a useful feature, but I
would consider it redundant to the other applications I use to monitor
uptimes and statistics on all of my machines (Nagios, cricket).

Perhaps a central monitoring/management app would simply build on your
integrated webserver commands. That'd be neat. ;]


Oddly enough, I'll be using monit to ensure Nagios is always
running. I crashed Netsaint once with a bogus plugin... ;] Hence my
paranoia.

Along the thought of a central machine, I think toward a plugin for
Nagios to query the status of monit on a machine. But then I'm just a
Nagios buff.

To elaborate, I use Nagios and SNMP/NSClient/NRPE to check on critical
processes on remote machines, but only to alert others to the
problems. Not all the machines could run monit (windoze :P), but those
that could would save me time and bandwidth by having a single plugin
call monit and verify everything is running ok, or monit reporting in
via submitting a passive critical service check when there is a
problem that it can't resolve.

These arguments got me thinking. I originally proposed a central monit
app, because the idea looked neat and because it seemed like a natural
evolution for monit and also because monit will easily integrate with
such an application. In fact, a central application would be so fun
and easy to write (at least in theory) that it's almost a shame not to.

But I realize that such a central monit application is only going to
part of a niche which is already pretty crowded with programs like Big
Brother, Nagios and others and as Mr. Adams was saying:

I'm not sure I'd even use a central monitoring app for monit. ;]

That's it, for a central monit app. to actually be interesting for
users it must do what I previously outlined but it must also implement
all the other stuff found in those other programs and even after all
this work it's probably *not* going to "succeed" because users are
already using (religiously) those other well established monitoring
applications. In other words is it worth the effort? I think not, or
at least I'm in doubt.

Monit has very good preposition for presenting collected data (via its webserver), which opens the issue for creating system, where these data will be stored, presented and maintained (triggers, etc.). It won't be difficuilt to do so and its natural, which gives it good chance to survive i think. The concept benefits from the good experiences and could be good replacement for SNMP. There are some other groups that tries to solve the same problem - for example SUN had heavy-weigth Jiro (which is the blind branch now).

As you said, to succeed it will be needed to provide functionality of other systems like Nagios as well. All these systems have one problem, which is very efficiently done by Monit - how to collect data from the system? I used in the past Netsaint to watch the systems - one of problems was data mining of values which wasn't possible to access directly (for example via read via SNMP). There were some perl daemons that vere able to do so, but the spatghetti was pretty warm :)

Monit is build from the other end - it is capable to collect everything and present it in well-known way to the world (via webserver/SOAP). I think it is good base for such system, but there isn't probably the right time for it yet. There are lot of issues and it will be probably better to concentrate on core monitor development. It is possible that modules for Nagios or some similar system could bypass the need for new central monitoring system. If we will provide data via SOAP, it will be possible to write gateways for traditional systems like SNMP which will be able to read data via SOAP and translate them to SNMP too. We will see - maybe new central monitoring application will be actual one day ...


It's probably more produtive to keep on improving monit in the current
problem domain (which BTW, I think we are doing a good job at).

Yes :)

And as
Martin suggested if someone wants to, it's actually very easy to
create a pluggin for monit for those central monitoring applications. (I'm not going to do it, since I'm a not big fan of any off those
systems, to put to mildly)

I have also started to have doubts about the need for a central
configuring system for monit (i.e. configure monit from ldap), rsync
for instance can probably do the job easily or what do you think,
Martin?

I think it is very usefull in ISP environment, like my employer's company. There are hundreds of servers and the easiest way to do it is to have possibility to configure them centrally, which provides the benefit of delegated administration option (for example you can let the customer to administer some instances), easy method for new instance creation, default options via "class of service" which can be easily modified by one change for all instances as well as they can be overriden, etc.

I plan to use it in my own project, but it doesn't matter if it will be used in monit or not one day. As you said, this is probably the same class of task as central monitoring application - we can live without it and try to extend the core functionality instead :)

Martin








reply via email to

[Prev in Thread] Current Thread [Next in Thread]