On 08/07/2014 10:42 PM, Leonid Isaev wrote:
Thanks for letting me know aboout this work, but from the above description it seems rather limited. I brought up the log-levels only as an example. In practice one needs to be able to filter using_any_ message attribute.
I just used the example to reply to your own so they are equally limited in that manner see systemd.journal-fields(7)
For instance, message body (iptables traffic, output of frequently-run systemd timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility (kernel/daemon/...).
And you have configured syslog-ng and rsyslog to do that for you and how much time did it take?
I can understand the need for very powerful filter capabilities which can be used when needed and the journalctl already possesses those.
In the sample you showed me how you are doing things you did so in three steps 1 configure syslog-ng 2 parse through files with log level lower then error, parse through files with error
But I myself am a lazy old fat admin that has been administrating server for what 10 years now and prefer to use this "journalctl -p err _SYSTEMD_UNIT=dnsmasq.service" which yields the same result in one step ( for each log level ) and I dont have to worry about installing or setting up anything basically I prefer I simply asking the journal to give me the information I need when I need it.
But why do you need to log all of this into their own persistent journal files, what practical problem are you hoping to solve,achieve or gain by that?
JBG _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
