Re: Nagios Integration

[Russell Adams]

SOAP? And you want to stay lightweight?

My immediate suggestion is to add a hidden URL to the local webserver
similar to the other control URL's that are already embedded, that
simply returns a text only tab delimited table of whats running and
some statistics about each process. Include the monit process for
uptime statistics.

For example my current machine I'm testing on is just monitoring cron,
and so retrieving http://localhost:2812/_textstatus would return:

monit   running 417660  0       30000
cron    running 417720  0       572000

Process name first, then more likely a 0/1 for notrunning/running
would be better, the uptime of the process in seconds, cpu time, then
memory. Of course this could be expanded with additional info thats
normally on the detail screens.

The point is a very quick plugin could be drawn up to grab and parse
the fields returned. Heck, if the performance data is good, I can drop
it into cricket too. Stripping the HTML takes more time than grabbing
a field.

Just an idea.

Russell

On Thu, Feb 20, 2003 at 11:38:54PM +0100, Martin Pala wrote:
> 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
> 
> 
> 
> 
> 
> 
> --
> To unsubscribe:
> http://mail.nongnu.org/mailman/listinfo/monit-general