Re: remote monit (or http and multiple expect and http-notify)

[Martin Pala]

Hi,

thanks for suggestions :)

Coments bellow ...

Leen Besselink wrote:
> Hi,
>
> You guys are right, monit is easy to setup and use, I really like monit.
>
> I've been looking at some of the added features (send/expect and xml-output).
>
> And also at some of the discussion (browsing the e-mail-archive) about a 
> central management
> or configuration application, maybe add some kind of other notification, maybe 
> even plugins.
>
> So I have 2 maybe even 3 suggestions, which, to me, seem natural extensions to 
> the existing
> abilities and do not require plugins.
>
> One is to add the ability to expect a certain HTTP-body-string. Maybe even 
> multiple.
>
> At this point send/expect only works as a general check, adding that to the 
> http-check would
> make sure it's http your checking on.
>
> The nice side-effect of this would add the ability to look if a certain service 
> is running on
> an other machine, by asking the monit running on that machine. This would 
> require only one
> HTTP-request and you'd know about multiple services at ones.

This is already implemented and will be part of upcoming monit-4.5. The 
syntax is (example):

--8<--
    check host FOO with address 172.16.2.1
      if failed url https://user:address@hidden:8080/?query
         and content == 'action="j_security_check"'
      then ...
--8<--

It has been also used (by Bernhard Nowak) to check monit services via 
monit's http interface:

--8<--
set daemon  30
set logfile /var/log/monit.log
set mailserver localhost
set mail-format
  { from: address@hidden
 set alert address@hidden
set httpd port 2812 and
     allow localhost
     allow 192.168.9.1
     allow 192.168.10.1

# services to watch:
  check host aaa with address 127.0.0.1
     start program = "/etc/init.d/ABC start"
     stop program  = "/etc/init.d/ABC stop"
     if failed port 20001 with timeout 60 seconds then restart
     if 2 restarts within 20 cycles then timeout


  check host bbb with address 192.168.10.2
     start program = "/etc/init.d/DEF start"
     stop program  = "/etc/init.d/DEF stop"
     if failed host 192.168.10.2 port 8080 protocol http with timeout 
60 seconds then restart
     if 2 restarts within 20 cycles then timeout

# use monit http content feature to check for "not monitored":

  check host ccc_monit with address 192.168.10.2
  if failed url http://192.168.10.2:2812/aaa
     and content != "not monitored" with timeout 60 seconds
     then exec "/etc/init.d/heartbeat stop"


  check host ddd_monit with address 192.168.10.2
  if failed url http://192.168.10.2:2812/bbb
     and content != "not monitored" with timeout 60 seconds
     then exec "/etc/init.d/heartbeat stop"
--8<--

> Two would be adding the ability to send a http-request as notification.
>
> You wouldn't need no plugins, http would be enough. For example to implement
> sms-notification, you'd just send a http-request to Kannel.

You can use monit's 'exec' action to call such url - for example snmptrap:

 if failed <test> then exec '/bin/bash -c "/bin/snmptrap ..."'


Native upstream event notification is work in progress which will be 
added in some future monit version - it will allow to send event 
notifications and status to the central monitoring system (such as 
m/monit for example).

> The third, which maybe taking things to far would be to add the ability for 
> monit to receive
> http-notification, so it could act on that.
>
> Better would probably be if that would only initiate a poll-cycle on receiving 
> a request,
> probably adding the ability the specify a maximum number of polls per minute as 
> well.


There are actions supported via monit's http interface which allows to 
maintain particular services (start/stop/monitor/unmonitor/restart), and 
general 'status' and 'viewlog' actions.

There is currently no alternative of CLI commands such as 'reload' or 
'validate'. The 'reload' command may make sense in touch with remote 
configuration support, the validation trigger may be good candidate to 
add  ...

Thanks,
Martin