On Thu, 7 Aug 2014 16:19:03 +0100 Darac Marjal <mailingl...@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 -- 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/20140807155651.2746f...@mydesq2.domain.cxm
