Re: it scares me a bit...

[Martin Pala]

I will summarize my point of view:

1.) Components for content analysis already *are* in monit. Regular 
expressions are used in send/expect options of generic protocol port test:

--8<--
 if failed host cave.persia.ir port 4040
    send "Open, Sesame!\r\n"
    expect "Please enter the cave\r\n"
    send "Shut, Sesame!\r\n"
    expect "See you later [A-Za-z ]+\r\n"
--8<--

As you can see, monit already allows content inspection. The extension 
will just make the syntax more general and ease the use with other 
implemented protocols (such as http module).

As possible example usage, there are protocols such as SOAP, which are 
encapsulated in HTTP. The proposed functionality will allow to easy test 
for properties, which can be carried in SOAP message and indicate the 
error. This functionality can provide interesting functions for WBEM/CIM 
management (replacement of SNMP) - for example you can check the state 
of disk array, etc.


2.) If you don't like this functionality, you don't need to use it. It 
is enabled via optional statement - in the case that this statement is 
not used, monit will not analyse the content nor use the related code 
(there's no security risc). I see no problem with it - it depends 
completely on you what will be enabled and used in control file.


3.) Using myriad of special purpose testing scripts is less reliable, 
more expensive, time-consumming and more complicated to manage then 
simple integrated functionality. I prefer the flexible functionality in 
monit better then managing cardhouse of scripts.


4.) We implement features to provide functional solution, not to 
introduce new bugs. I don't think that we should give up because we 
potentialy can make some mistake.


Summary:
I see no rational reason why not to implement the content inspection 
functionality in monit.


Martin


Vlada Macek wrote:
> alex black wrote:
>
>
> > It's all very well and good if apache is running - but if something
> > else has screwed up (either in code recently promoted,
> > configuration, etc) then it's useless. The only way I can be
> > satisfied that it is running correctly is to have some ability to
> > test URLs - if those tests fail it's great to get a message from
> > monit saying something like... I tried to restart apache to solve
> > this problem but that didn't work - time for you to do something.
>
>
> Most of this is already present in monit. In addition monit may check
> the HTTP return code, it would be cheap. But once it is able to
> checksum the HTTP content, it actually checks more than just the
> return code (200 OK) and such extension would be IMO useless. You may
> have some blind file with known checksum on the webserver, which you
> could exclude from your web logs (as was previously adviced on the
> list). By this you'll check static page serving.
>
> > From what you are saying I'm not convinced even you really need the
> "Remote page grepping" feature you originally proposed. Even armed
> with this feature, you will not be able to check that your dynamic
> content is served properly. For these purposes I propose you to create
> some clever self-diagnostics script on the remote web server, which
> e.g. checks the database backend, does some queries etc., and if all
> is okay, returns the content with a known checksum. This output may
> again be checked by monit's existing facility.
>
> By self-diagnostics web script you will be able to do checks that will
> by far exceed monit's abilities (with grepping included!), just
> because it will be written by you and only you exactly know what to
> check. As a cherry on a cream, you can make a script output human
> readable status page. Once it's checksum changes, monit alerts and
> anyone can peek with a browser and see what is wrong in detail. Monit
> tells you only "Bad, but I'm trying, man...".
>
> As I said, I do not see the purpose for such expensive feature as is
> fixed string grepping.