in reply to Wasting time with times

Another side to the argument would be to ask how readable do the application logs really need to be? Depending upon the application, the specifics of logging are insignificant - It is more important to simply have the information available if its needed, in any format, rather then being able to browse it in a human-readable format.

To this end, I would say that there is little wrong with simply logging date and time as seconds since epoch, especially given that there is no high precision required in the time stamps provided. This effectively side-steps this argument altogether allowing for logging without the formatting performance hit and if there is a later need for debugging or log analysis, it is relatively simple to have a log file parser that reformats the log file timestamps into a human readable format.

 

Replies are listed 'Best First'.
Re: Re: Wasting time with times
by greenFox (Vicar) on Sep 16, 2002 at 05:06 UTC

    No, no, no, no, no! If no one ever needs to look at it then why are you logging it at all? If someone is going to look at it then it will probably be because something has gone wrong and then every-thing you do to make it easier for the person doing the fault finding is appreciated and reflects well on you as a developer. Say what you detected and be explicit, say why it means you can't continue and say when it happened. Remember no matter how obscure the log when something is wrong someone will look at it and be trying to make sense of it.

    My three top gripes with developers-

    • programs that detect an error condition and die without reporting the error condition any-where
    • log files without date-time stamps (I kid you not) or date-time stamps that are inconsistant or unreadable
    • meaningless or un-helpfull error messages like- "an error has occurred", "software error", "terminating due to an abnormal condition", "error-20756a" etc.

    By avoiding these you make it easier to locate the source of the problem, easier to give quality bug reports and easier to represent you well to the client because you have made me feel in control of the problem: I have an idea what is going on and I can convey that confidently to the client- even if I have no idea how to fix it.

    </end rant> :)

    --
    Until you've lost your reputation, you never realize what a burden it was or what freedom really is. -Margaret Mitchell

[reply]
      You miss the point of my argument entirely - I am most definitely not saying "Do not perform any logging", nor am I saying "Do not timestamp those logs that you do generate". My point was that logging, depending upon the application, does not necessarily have to be carried out in a human readable format, or with human-readable time stamps, particularly when this is done at the cost of application performance. Indeed, I am of the opinion that a great deal of information should be logged and indeed many of my applications log entry and exit points of major subroutines as a matter of standard practice.

      An example of this practice would be the Windows Eventlog API - This logging API does not store message information in a readily-parseable, human-readable text format, but rather a binary format which allows for rapid logging and compact storage - These logs can then be accessed programmatically by APIs or through the Eventlog viewer. The end-result is that all information is available to the user or developer working with the Eventlog, despite the fact that the storage format is not natively human-readable.

      Logging should be a symbiotic adjunct to an application not a mandatory deadweight.

       

[reply]

        I agree that logging shouldn't be done at the expense of performace but usually that is dictated by how much logging is done and where in the process, not by the logging format. Apache (as an example) seems to be able to cope with high volumes and a readable log file so it can be done.

        Having had to cross corelate faults through logs as diverse as unix system logs, firewall-1 logs, apache logs, mail logs, proxy logs, custom application logs etc. my experience has been that having the date time human readable in some recognisable format is essential. I guess I am too much of a Unix guy to want to have to fire up a GUI just to look at an event log :)

        --
        Until you've lost your reputation, you never realize what a burden it was or what freedom really is. -Margaret Mitchell

[reply]

      Shrug. You have a good point... but you're missing big peices of it. Unreadable is a relitive thing. If the logfile is documented as having the first field be timestamp in seconds since Jan 1 1979 23:59:59, then it isn't a problem. If it lists things like 1032155104 16011503 "Creating asdfoij object" -2147221005, that's fine, so long as the documentation tells you that the fields are seconds-since-epoch, PID, filename, freeform error text, and COM error code, and comes with docs for how to look up those fields. (Preferably a program to parse the logfile and give you useful errors.)

      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]
[d/l]

In Section Meditations