Hi, is there allready work done with xymon-client log monitor and journalctl, means without syslog running ?
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
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
Am 01.12.2015 um 22:20 schrieb 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
Thx for explain !
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
On Tue, Dec 1, 2015 at 4:20 PM, J.C. Cleaver <cleaver at terabithia.org> wrote:
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.
journald.conf supports the ForwardToSyslog option
============================ Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users.
Am 01.12.2015 um 22:35 schrieb oliver:
On Tue, Dec 1, 2015 at 4:20 PM, J.C. Cleaver <cleaver at terabithia.org> wrote:
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.
journald.conf supports the ForwardToSyslog option
============================ Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users.
This i widly known , but i think that is/will be not default in many distros so having native journalctl log monitoring will be very usefull in any case
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Best Regards MfG Robert Schetterer
-- [*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
participants (3)
-
cleaver＠terabithia.org
-
ohemming＠gmail.com
-
rs＠sys4.de