Re: Some comments.

[Jan-Henrik Haukeland]

"Peter Holdaway" <address@hidden> writes:

>   Removing the timestamp syntax from "check process" and limiting it
> to "check file" is a bit annoying as it reveals in the http GUI the
> internals of how I am using a regularly updated file timestamp to
> check if a process is working correctly.

If you are upgrading from monit 3.2, it may take some time to get used
to, especially since monit now, not only deals with processes only.
But I'm not sure why it is a problem, that is, revealing the link
between a process and a file in the monit web gui, on the contrary, I
would think. Anyway, you sort of presented the solution to the problem
yourself by showing us the nice wrapper html page you use. I'm sure
you can edit this page to display only the information you would like
to see.

>   In 3.2, the easiest way to instrument a process for continuous
> monitoring by monit was to add a file timestamp updating routine. I
> am now considering creating a TCP port purely for monit's use.

I'm not quite sure what you mean here, but the timestamp functionality
in the 4.1 release should be at least on a par with the functionality
in the 3.2 release.

>   It seems to me that it is inconsistent to allow a connection test
> inside a process entry, but not a timestamp test.
>
>   Oh well ...

Maybe, but if so, I think it's more of an argument for factoring
connection test out of a process entry than putting file checks back
in :)

I _do_ believe that the new control file syntax and the availability
of 4 new service types (file, dir, dev, and host in addition to
process) makes monit much more flexible and easier to use for solving
problems. If monit 3.2 solved a problem for you and you cannot solve
the same using 4.1 I really would like to know (so we can fix it). If
you can, please, submit control file syntax examples to demonstrate
the problem.

> 2. GUI ease of use.
>
>   May I suggest that you make it a bit easier to start/stop/restart
> processes?

The request is noted, but on the other hand it could make the first
status page too crowded. As a side note, we (I) are about to start
working on a centralized monit application, where it should be
possible to manage many monit instances from one web page. In this
application, the request "to make it easier to start/stop/restart
processes" is very likely to be implemented. We had a short discussion
about this application on the developer list and you can read this
mail to see some very preliminary thoughts:

 http://mail.nongnu.org/archive/html/monit-dev/2003-10/msg00101.html

>   Enclosed is a wrapper we use around the monit HTTP GUI that I find very
> convenient.
>   The Select link selects all the processes and the selection box will
> stop/start or restart the selected processes.

That was a clever idea! Thanks for sharing.

>   It would also be nice if the groups were also visible in the http GUI,
> perhaps by "grouping" processes in separate sections. :-)

Yep, but it is a problem though since a group can span other entries
than processes and the status page is already grouped on service
types. (Grouping within each service type is of course possible).

-- 
Jan-Henrik Haukeland