On Thu, Aug 7, 2014 at 5:26 AM, AW <debian.list.trac...@1024bits.com> wrote: > On Wed, 6 Aug 2014 22:15:08 +0300 > Andrei POPESCU <andreimpope...@gmail.com> wrote: > > > The advantage of journald is that it captures more information because > > it runs much earlier and also because it captures stdin (?!) and stderr > > of daemons. The data has more metadata and is also better structured and > > indexed (hence the need for binary storage). > > I've seen this... However, I would prefer to take it several steps farther, > and > store the log data in a database; postgresql, of course, is there any > other?
I'm trying to pick my jaw back up off the floor. Although, in my way of thinking, it makes as much sense as most of systemd. (Do I hear a whoosh? I could imagine I'm hearing a whoosh.) > ... Think of this powerful use case: given a server farm of 1000 or so > hosts. Each server has a write only ssl connection to an external postgresql > database for log purposes. Of course copies of the logs can be kept locally, > but think of the security increase of not storing apache, mail, or even auth > logs locally. And think of the standardization that would come almost by > default. With a few well chosen queries, and a little R magic, the entire > 1000 > host server farm could be evaluated quickly in a report style that even > management might understand... > > /sarc Perhaps this functionality is already built into systemd... and we'd > never know until we look through the header files in the source code, and > discover that - Yes! - journalctl REMOTE_LOGGING=2.5 means activate the > secure > remote pgsql capability... /sarc Whew. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOHPh4EdSymLLN8R8Rzrn9Zj-RSVw=hfmh-tz9ehmt...@mail.gmail.com
