[systemd-devel] Suppressing spam error messages in the system journal

[Christopher Cox]

On 10/22/20 9:55 AM, Dave Howorth wrote:
> On Thu, 22 Oct 2020 15:27:58 +0200
> Reindl Harald <h.reindl at thelounge.net> wrote:
>> Am 22.10.20 um 12:59 schrieb Lennart Poettering:
>>> On Do, 22.10.20 11:11, David C. Partridge
>>> (david.partridge at 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.