[Python-ideas] Fwd: [Python-Dev] An yocto change proposal in logging module to simplify structured logs support

[Ludovic Gasc]

2015-06-29 3:09 GMT+02:00 Nick Coghlan <ncoghlan at gmail.com>:

>
> On 29 Jun 2015 1:50 am, "Ludovic Gasc" <gmludo at gmail.com> wrote:
> > In fact, the issue shouldn't be our brains, but it was clearly a time
> consuming task, and we have too much directly paid-work to take care.
> >
> > Don't be wrong: I don't say that ELK doesn't work, only it's time
> consuming with a high level of logs.
> > I'm pretty sure that a lot of people are happy with ELK, it's cool for
> them ;-)
> >
> > It's like Oracle and PostgreSQL databases: Where with Oracle you need a
> full-time DBA, with PostgreSQL: apt-get install postgresql
> > With this last sentence, I'm totally caricatural, but only to show where
> I see an issue that should be fixed, at least for us.
> > (FYI, in a previous professional life, I've maintained Oracle, MySQL and
> PostgreSQL servers for several clients, I know a little bit the subject).
>
> This discrepancy in manageability between services like PostgreSQL & more
> complex setups like the ELK stack is why Red Hat started working on
> Nulecule as part of Project Atomic:
> http://rhelblog.redhat.com/2015/06/23/announcing-yum-rpm-for-containerized-applications-nulecule-atomic-app/
>
>
Thanks for the link, I didn't know, I'll keep an eye on that.


> There's still some work to be done making sure the related tools support
> Debian and derivatives properly, but "the ELK stack is too hard to install
> & maintain" is a distro level software management problem to be solved,
> rather than something to try to work around at the language level.
>
As you can imagine, I want to finish to dig around journald before to
change the strategy.
Thanks for your time and your remarks.

Have a nice day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150706/50302f4b/attachment.html>