So - I think some other solution is needed, and I've been
thinking about how to do it. So far it's just ideas - no
code. But I believe the log checking has to happen on each
client, but controlled by a central configuration. So what I
plan to implement is something like this:
* The configuration of what logs to monitor and what strings to
look for is maintained on the central Hobbit server, either as
an addition to the hobbit-clients.cfg file, or in a separate
file - that isn't really important.
* When a client connects and sends in a client-side message, the
Hobbit server accepts the client message, but also sends back
the current log-check configuration info. By re-using the
client connection, the overhead involved in pushing the
configuration to each client becomes almost nil.
* When the client has a log-check configuration, it knows what logs
to check for what strings, and can include that information in
the normal client message it sends back to the Hobbit server.
That means the client will need a tool to do the logfile checking;
probably using a client-side regular-expression matching tool
like "grep". It can either be built into the Hobbit client, or
it could just rely on the existing "grep" utility found on the
system - this would probably be the simplest to implement.
I had come to the same conclusion when trying to think how to implement
msgs tests in a 'hobbit' way. So it seems that hobbit needs some manner
of 'push' mechanism. Of course this is just pushing configuration, but
since you are talking about a 'push' mechanism what about pushing files
too ? Though this option may be cosidered a security hole. But this
would be nice for pushing out updates. Whether it is a full Hobbit
client update, or if a particular script/test needed to be pushed out
and updated.
Pushing out files could be a configureable option that can be
enable/disabled.