Willy,

Am 03.05.2018 um 17:37 schrieb Willy Tarreau:
>> [1] I'd love to have a proper integration with systemd-journald to have
>> all my logs in one place. It's pretty annoying, because some things
>> ("Proxy bk_*** started"; [WARNING] 121/202559 (11635) : Reexecuting
>> Master process) go to systemd-journald (probably printed to stdout /
>> stderr) and everything else goes into syslog.
> 
> Well, you should probably tell that to the guy who instead of learning
> how to use a unix-like system decided it was easier to break everything
> in it that used to be pretty simple, stable, reliable and clear for 40
> years before he forced his crap into almost every Linux distro to the
> point of making them even less observable and debuggable than Windows
> nowadays :-(

Personally I enjoy systemd and take a unit file over an init script all
day. But I'm very well aware of the criticism surrounding it.

> What you have above looks like stderr. The rest are logs. They are for
> very different usages, stderr is there to inform you that something went
> wrong during a reload operation (that systemd happily hides so that you
> believe it was OK but it was not), while the logs are there for future
> traffic analysis and troubleshooting.

The distinction seems to be not really clear drawn:

This goes into my syslog:

> May  3 13:30:26 ### haproxy[21754]: Proxy bk_aaa stopped (FE: 0 conns, BE: 0 
> conns).
> May  3 13:30:26 ### haproxy[21754]: Proxy bk_aaa stopped (FE: 0 conns, BE: 0 
> conns).
> May  3 13:30:26 ### haproxy[21754]: Proxy zzz stopped (FE: 2 conns, BE: 0 
> conns).
> May  3 13:30:26 ### haproxy[21754]: Proxy zzz stopped (FE: 2 conns, BE: 0 
> conns).
> May  3 13:30:26 ### haproxy[14926]: Server bk_xxx/xxx is DOWN, changed from 
> server-state after a reload. 0 active and 0 backup servers left. 0 sessions 
> active, 0 requeued, 0 remaining in queue.
> May  3 13:30:26 ### haproxy[14926]: Server bk_xxx/xxx is DOWN, changed from 
> server-state after a reload. 0 active and 0 backup servers left. 0 sessions 
> active, 0 requeued, 0 remaining in queue.
> May  3 13:30:26 ### haproxy[14926]: backend bk_xxx has no server available!
> May  3 13:30:26 ### haproxy[14926]: backend bk_xxx has no server available!
> May  3 13:30:26 ### haproxy[14926]: Server bk_yyy/yyy is DOWN, changed from 
> server-state after a reload. 1 active and 0 backup servers left. 0 sessions 
> active, 0 requeued, 0 remaining in queue.

This goes into the journal:

> May 03 13:30:26 ### haproxy[11635]: Proxy bk_xxx started.
> May 03 13:30:26 ### haproxy[11635]: Proxy bk_xxx started.
> May 03 13:30:26 ### haproxy[11635]: Proxy bk_yyy started.
> May 03 13:30:26 ### haproxy[11635]: Proxy bk_yyy started.
> May 03 13:30:26 ### haproxy[11635]: Proxy bk_zzz started.
> May 03 13:30:26 ### haproxy[11635]: Proxy bk_zzz started.
> May 03 13:30:26 ### haproxy[11635]: Proxy aaa started.
> May 03 13:30:26 ### haproxy[11635]: Proxy aaa started.

At least the Proxy ... started / stopped messages should go into the
same log.

> And the reason journalctl is this slow very likely lies in its original
> purpose which is just to log daemons' output during startup (since it was
> confiscated by the tools). It's totally unusable for anything like moderate
> to high traffic.

Cannot comment on performance for obvious reasons.

> Going back to the initial subject, are you interested in seeing if you
> can add a warning counter to each frontend/backend, and possibly a rate
> limited warning in the logs as well ? I'm willing to help if needed, it's
> just that I really cannot take care of this myself, given that I spent
> the last 6 months dealing with bugs and various other discussions, almost
> not having been able to start to do anything for the next release :-/ So
> any help here is welcome as you can guess.
> 

Personally I'd prefer the rate limited warning over the counter. As
outlined before: A warning counter probably will be incremented for
multiple unrelated reasons in the longer term and thus loses it
usefulness. Having a warning_headers_too_big counter and a
warning_whatever_there_may_be is stupid, no?

I feel that the error counter could / should be re-used for this and
just the log message should be added. My munin already monitors the
error counts. The `eresp` counter seems to fit: "- failure applying
filters to the response.".

Best regards
Tim Düsterhus

Reply via email to