On 10/22/20 9:55 AM, Dave Howorth wrote:
On Thu, 22 Oct 2020 15:27:58 +0200
Reindl Harald <h.rei...@thelounge.net> wrote:
Am 22.10.20 um 12:59 schrieb Lennart Poettering:
On Do, 22.10.20 11:11, David C. Partridge
(david.partri...@perdrix.co.uk) wrote:
1) Is there any way in journald.conf to perform a
message
suppression
similar to the one I used for syslog? If not should there be
one?
No.
Does that mean no there isn't and also that there should not be,
or are you open to considering allowing a suppression mechanism
similar to that available in rsyslogd?
Not a fan of such hacks. Fix the programs or filter during display,
don't suppress at time of collection.
it's not a matter of fan or not
it just makes sense to filter out things one *never* want to see at
all instead store it
I think Lennart's point is that whatever happened to cause something in
the system to make a log entry happened, and that should be recorded.
Even though you may never want to see such evidence somebody, somewhere
might want it as part of an investigation, so it's better that it's
captured and preserved. The space will eventually be reclaimed so
there's no harm done.
And as he suggests, if you never want to see it, then filter it out on
display.
There still could be some worthwhile cases though. While it may be true that
"frontends" might provide some filtering (rsyslog, plenty of options, journalctl
much less), allowing filtering at the source to prevent huge log gathering thus
avoiding having massive retention and/or storage requirements for data that ends
up being very temporal, could be of benefit.
(I know, disk and memory are cheap... but should that be our answer?)
So, I could see this being useful to some. For me, I always do the rsyslog
forwarding thing to keep my sanity (by filtering the noise level). And that
works for me. Let journald just churn and roll. For me, this is "the
workaround" for the issue.
Our developers insist on inserting ANSI escape sequences in their logs... maybe
some won't see the correlation. When there's too much "noise", especially when
you don't know precisely what you are looking for, a very noisy log of "useless"
data (noting, that it's conceivable that "something" gathered is "universally"
useless for an organization) can be very difficult to parse through.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
