[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Alex Carver]

On 2015-09-10 11:45, Michael B. Trausch wrote:
> On Thu, 2015-09-10 at 11:29 -0700, Alex Carver wrote:
>> Not if it's an all or none proposition.
>>
>> Example, right now I can set up filters to have rsyslogd take syslog
>> input and either drop it to a file or, for things that are noisy,
>> shuttle them off over the network to something that actually has a
>> reasonable amount of storage (something many of my embedded systems
>> don't have).  For the documents that I can find, *everything* goes to
>> the journal with no option to filter and you must choose to have all
>> of
>> it go to disk and/or duplicate it over the network.  You can't have a
>> mix.  If I'm wrong about this I want to see the documentation about
>> how
>> to filter what gets written to the journal and what doesn't.
> 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.
> 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.
> 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.


I can't fix every program that's noisy or has issues.  There just isn't
enough time in a day to do all that.  However, let's ignore the noise
for a minute and go with the filtration.  On one of the embedded
systems, the firewall data is sent to another machine without ever
landing on the local storage medium (flash).  There's a LOT of data
coming from the firewall that is necessary (connections, probes, etc.)
that gets analyzed both on the fly and later.  That's too much for the
flash to handle so it goes to another machine with a spinning disk.  By
the same token some of the basic messages about hardware stay on the
local disk (such as an ifup/down event).

So I've got two rules set up for those:
if firewall-message: send to remote_ip
if hardware-message: send to /var/log/hardware

My flash disk is only then touched for the hardware messages.  The
firewall messages fly across the network instantly.

Under the journald system it seems I do not have this option at all.  I
must either write everything to memory (volatile storage method) and
then have *another* program pull from that and either write to disk or
send away, or I must allow journald to write to disk always (persistent
storage method") which writes everything meaning I'm going to have lots
of firewall messages getting dumped to the flash module.  If I set
journald to the "none" storage method, it's just going to purge all the
data period.  If I set it to send to a remote location, then all of the
data goes to a remote location where I'd have to filter it (and again,
if that remote location is systemd/journald  I'm back to square one with
filtering).

It seems I'm getting one for the price of two.  To have what I need now
I just run one syslogd.  To hvae the same thing under systemd I must run
journald and then run a syslogd on top of it because journald is not
capable of filtering inbound.