Re: URL content checking [Vote]

[Jan-Henrik Haukeland]

On Dec 2, 2004, at 4:22 PM, Michael Shigorin wrote:

> As monit (IMCO) should be quite resistant to system failures
> being quite "basemental" software piece (remember SMTP-related
> discussion? :), being less fault-prone regarding e.g. broken
> libraries for some fancy test (e.g. involving Oracle OCI) would
> bring in some solid points over the years and installations.

Nothing in the proposed URL function contradict this philosophy. No 
plugin nor external libs are required to realize this functionality. 
The point is that monit already have support for url-testing. So what 
we actually are doing is to lift up existing functionality into the 
control file and wrap it in a new setting.  A bit of "glue" coding is 
necessary but nothing fancy.

> > check URL myURLCollection
> >                 if failed urls [
> >                         http://user:address@hidden/foobar?querystring
> >                         http://user:address@hidden/foobar
> >                         http://blabla3.com/foobar?querystring
> >                         http://labla4.com/foobar?querystring
> >                         http://user:address@hidden/foobar
> >                         ....] # Space or newline separate url-entries
> >                 then <action>
>
> And what should be the <action>?  As far as I understand,
> presumably sending mail/SMS, not restarting apache or restoring
> database and/or backup.

Yep, in this case the only meaningful actions would be to either to 
call exec or alert.

> I may be wrong but a quick perl, ruby, python, heck -- shell
> script to GET or lynx -dump the page(s) and some grepper would do
> this particular trick.

You are not wrong, but does that imply that it is wrong to implement it 
in monit? I think not, actually monit is great for stuff like this.

> So all in all, is monit the targeted system-level bulletproof
> tool focusing on local processes or is it aiming to become a
> distributed infrastructure wielding dozens of plugins?

``Every program attempts to expand until it can read mail.  Those 
programs which cannot so expand are replaced by ones which can.''  But 
seriously, monit already does "bulletproof system monitoring" and  if 
you  only need that, stay with monit version 4.4. Monit need to evolve 
if it should continue to be alive and an active open-source project. If 
there is nothing more to do, the project will die.

So to stay alive we need to add stuff to monit and continuously 
refactor and refine it. It's a question about choosing the right 
direction for the project. Right now it seems that monit is evolving 
into becoming a monitoring swish-army knife which doesn't sound to bad 
in my book.

> Sorry for being verbose and kind of "anti"sh again, but I tend to
> criticize the things I like most -- the rest isn't worth it :)

I know it comes from a genuine interest in monit so I do very much 
appreciate your points of view and comments. But don't expect us to 
follow them all the time :)

> (...and I'm just an hour back from the meeting where I've
> presented monit to fellow colleagues

Nice, BTW I hope everything is okay and that things will settle in your 
country.
--
Jan-Henrik Haukeland