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.