<html><head></head><body><div>On Thu, 2015-09-10 at 11:29 -0700, Alex Carver wrote:</div><blockquote type="cite">Not if it's an all or none proposition.<br>
<br>
Example, right now I can set up filters to have rsyslogd take syslog<br>
input and either drop it to a file or, for things that are noisy,<br>
shuttle them off over the network to something that actually has a<br>
reasonable amount of storage (something many of my embedded systems<br>
don't have). For the documents that I can find, *everything* goes to<br>
the journal with no option to filter and you must choose to have all of<br>
it go to disk and/or duplicate it over the network. You can't have a<br>
mix. If I'm wrong about this I want to see the documentation about how<br>
to filter what gets written to the journal and what doesn't.<br></blockquote><div><br></div><div>I'd be a bad one to try to find that, because it's not functionality I've ever used. I've rather preferred the approach of fixing the squeaky wheel. See, to me, logs are useless if one needs tools like HP's OpenView to grok them. Instead, the signal-to-noise ratio should be correct: there should be very little noise in the first place.</div><div><br></div><div>My motivation for attacking the problem like that is simple: there's very little reason to apply filtering between the syslog/journal's entrypoint, when you can avoid the whole invocation in the first place (saving several context switches in the process). Adding filtration adds context switches. More context switches are bad. I therefore consider noisy processes to be misbehaving, and either repair or replace them. Thank goodness for having source code.</div><div><br></div><div>Call my view tainted: I've been doing an awful lot that requires very precise timing lately, and even an extra context switch at a bad time can throw my timing off. On the flip side of the coin, I don't want my process to be of higher execution priority than the kernel, because then I can miss things which are *coming at me* from the physical hardware. A noisy process is therefore absolutely intolerable, and the additional overhead of filtration even more so. Cut the problem off where it starts, and nothing downstream has to compensate.</div></body></html>