Re: Journald's qualities (was: Selective rotation of journald logs)
Dnia 2024-02-23, o godz. 15:05:52
Nicholas Geovanis <nickgeovanis@gmail.com> napisał(a):
> On Fri, Feb 23, 2024, 2:57 PM Dan Ritter <dsr@randomstring.org> wrote:
>
> > Stefan Monnier wrote:
> > > Makes one wonder why they don't use naive append-only "plain
> > > text" logs (tho with appropriate delimiters (maybe some kind of
> > > CSV) to make searches more reliable than with old-style plain
> > > text logs)?
> > >
> > > What are the advantages of journald's representation?
> > > I mean, to justify the slow search and large disk space usage,
> > > there is presumably some upside for some use cases. I can see
> > > some weak argument against Sqlite based on the size of Sqlite,
> > > but what are the advantages of journald's representation compared
> > > to a naive one?
> >
> >
> > systemd's design philosophy, observed from the outside, goes
> > like this:
> >
>
> ....bunch trimmed.....
>
> Exactly correct in my view. Systemd's use-case is the desktop, not the
> server in the datacenter. They will be using log-aggregation software
> in the datacenter anyway so no use for systemd logging. We don't
> install desktop software on servers either, no X Windows, no gnome,
> etc. Network connections are stable, no roaming :-)
>
> Long-term logs are for servers, so systemd doesn't want them.
Right but it would be nice if it could at least forward them upstream
then! Your choices are
* use rsyslog, which does everything better than journald, including
writing to many different databases directly, just to forward to
remote host.
* setup super special listener for super special journald remote log
sending method that nothing but journald supports
If it just supported standard, common protocols like RFC5424 flavour
(that adds structured data to entries), or hell, just "send a JSONed
log to that address", I could just have a bunch of my "small" devices
run journald-only and send it to central logging server. But no dice,
even my router needs to run extra daemon just to forward logs.
Actually, having pluggable "backends" would solve a lot of that, dumb
little IoT device could just have "a text file" or remote output
implemented as write method and "grep the text file" as query method.
Or DBI plugin that could write to SQLite and query it back. Or just
remote log plugin that returned "sorry, your logs are in another
castle" on query. But that's just building rsyslog but worse at that
point...
I wish I disliked C less than I miss those features...
--
Mariusz Gronczewski (XANi) <xani666@gmail.com>
GnuPG: 0xEA8ACE64
https://devrandom.eu
Reply to: