Re: End of hypocrisy ?
On Thu, 7 Aug 2014 16:19:03 +0100
Darac Marjal <mailinglist@darac.org.uk> wrote:
> On Thu, Aug 07, 2014 at 10:01:41AM -0400, Steve Litt wrote:
>
> > I don't necessarily disagree, but I very strongly believe its first
> > step should be to go to a text file with one line per event, or
> > perhaps some sublines. If that text file were designed correctly,
> > perhaps with field separators, it would be trivial to write a C or
> > Python program to input it into Postgres. I just want to make sure
> > that I can read that log on any Linux, BSD, or even (ugh) Mac and
> > Windows.
>
> You see, though, this isn't the design goal of the journal.
That's nice. Of course, it *is* the desired log file of a plurality or
majority of Linux users who care about log files.
> The
> journal is designed to be resistant against corruption (hashes are
> used to preserve message integrity), quick to access (there is an
> index so you don't have to spool through the whole file looking for
> the event that happened at 10:00, say) and well defined (times, for
> example, are defined as µsec since the epoch, not some
> lets-defined-another-parser text string).
Yeah, to free the log-using user from the need to use head, tail, grep
and cut, let's define yet another database structure. I mean, really,
it's easy as pie to define the tables and relationships of a database,
but world-shakingly difficult to do things like use a usec timestamp.
So, if a log-using user can't read his log files with just any old
rescue CD, well, that's a small price to pay for the coolness of having
your log files in a database.
>
> Consider it to be another database format. You wouldn't necessarily
> try to cat a MySQL or PostgreSQL datastore; you'd use the appropriate
> tools to select all from it. In a similar vein, you'd use journalctl
> to select all the entries from the journal file and you'd expect it
> to do much of the hard work such as telling you if a line has been
> altered (either tampered or simply corrupted), adjusting the
> timestamps for time zones and so on.
>
> "cat"ing the journal doesn't have to lose information, either.
> Journalctl can export as JSON or a serialised "export" format
> (plain-text).
And plain-text, as long as it's halfway sane, was all I was asking for
in my initial post, always assuming it can be easily set to export and
keep exporting persistent text log files.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: