[Xymon] journalctl log monitoring

[J.C. Cleaver]

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