Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 1 Feb 2014 19:07:42 +0200
From: Paul Schutte <sjpschutte@...il.com>
To: musl@...ts.openwall.com
Subject: Re: syslog() always sends GMT timestamps

I have to chime in here.

The venerable squid proxy has generated logs with unix epoc timestamps for
ages and it never has stopped anyone from reading those.
I am all for the ISO date format, but it makes a lot of sense to have it in
either TAI64N or epoch time.
It is trivial to filter those for human consumption as mentioned. On the
other hand if the log was in some human readable form one has to start to
dabble with inefficient things like Time::ParseDate in perl to make
computers understand it. Not to mention the time zone mess.

Just my 2 cents.

Regards
Paul


On Sat, Feb 1, 2014 at 5:48 PM, Laurent Bercot <ska-dietlibc@...rnet.org>wrote:

> On 2014-02-01 01:09, Szabolcs Nagy wrote:
>
>  yes there is nothing clearer than a 24 digit hexadecimal number
>> representing time to the nanosecond
>>
>> at least the last 3-4 digits in the log can be used as a random
>> sequence
>>
>> (i've seen this in practice and have no idea how anybody could
>> ever think that it's a good idea.. must be some sysadmin logic
>> that is beyond the reach of average mortals)
>>
>
>  I was half-trolling, but since you bit the hook:
>
>  Historically, logs were made to be read by human beings, so it
> made sense to print timestamps in a human-readable format. But it
> is less and less the case. Logs are getting more and more
> automatically processed, filtered, aggregated, analyzed, which is
> a good thing. Humans nowadays only look at raw textual log data once
> everything else has failed, including visualizing them in some web
> interface that also processes them for display.
>
>  So it actually makes more sense to write logs in a format that is
> easily parsable and usable by *computers*, and timestamps are a big
> part of it. Human time is complex to understand for computers (and
> even for humans not living in the same time zone). TAI64N is simple,
> and makes processing easy as pie. (Mmmm... pie.) Merging log files
> chronologically ? Just cat all your log files together, pipe them
> through sort, done. Oh, and it works with log files from other
> machines all around the world, without a concern for timezones or
> human time quirks such as DST, too. Want to strip the timestamps
> for some reason ? Pipe your logs through "cut -c27-", done.
>
>  And people can even read the raw files too, they just have to
> run "s6-tai64nlocal < logfile | less" instead of "less logfile",
> which is the simplest processing you could think of - a UNIX filter.
> (I've heard that Great Sysadmins can understand TAI64N directly in
> the text, but I couldn't tell, I'm not yet part of the Circle.)
>
>  So, dear initiate, now that you know the greatness of automated
> processing and of Unix filters, and have shaken off the myth that
> logs have to be read exactly as they were written, you have risen
> above average mortals, and are now a Sysadmin. Congratulations and
> welcome !
>
> --
>  Laurent
>
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.