On Tue, December 1, 2015 8:32 am, Robert Schetterer wrote:
Hi, is there allready work done with xymon-client log monitor and journalctl, means without syslog running ?
Best Regards MfG Robert Schetterer
At this time, there's no specific work done yet.
logfetch is built around seeking back and forth over a real file, starting at the byte position we last read to, which makes it somewhat tricky to conceptualize when using journalctl, where there's nothing seekable with which to deal with.
(I'll spare the systemd and "everyone uses pagers so let's just build it into the viewer!" rants here, but at least the recent versions have a --no-pager option >.<)
The simplest way to integrate would be to alter the xymonclient.sh code to have journalctl dump log contents using the *cursor or --since options to a separate file, which logfetch reads and handles like a "normal" log file to scan, which we rename or symlink around as needed. This has the advantage of allowing use of all the existing client-local.cfg rules regarding triggers and ignoring. We then save the cursor and start there for next time.
Logfetch could also be patched to (similar to the commands used to determine filenames now) just execute a command and read text data from its STDOUT, making naive assumptions about input start/stopping.
This code doesn't exist today.
Longer term, there are some additional features that could be used to have a more generic framework for executing commands, retrieving sorted or syslog-level-specific log lines from a local source, and reporting back on them to the xymon server (and/or xymond_client) for final 'analysis.cfg' processing. The syntax for controlling a) which lines to retrieve and b) which lines to send back is likely to be different enough from the standard 'log:' format that IMO we'd want to have a new section in client-local for it.
Arguably, splitting the logfetch run components out from xymonclient.sh and making a xymonclient-logfetch.sh, xymonclient-journalctl.sh, (etc...) call-out would be a nice, clean way of encapsulating that logic on the different types of systems.
Again, that code doesn't exist today.
For the very short term, re-enabling syslog or scripting output that simulates the [msgs:/var/log/message] data in the client message by hand are your only quick options.
Regards, -jc