in reply to Re: Wasting time with times
in thread Wasting time with times

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-

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

Replies are listed 'Best First'.
Re: Re: Re: Wasting time with times
by rob_au (Abbot) on Sep 16, 2002 at 05:50 UTC
    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]
        Actually as an afterthought, I thought I would just add that binary logfiles are not a unique phenomenon to Windows platforms - The *nix wtmp file is also a binary format, one which is variable between platforms, defined by /usr/include/utmp.h.

         

[reply]
[d/l]
[select]
Re: Re: Re: Wasting time with times
by theorbtwo (Prior) on Sep 16, 2002 at 05:54 UTC

    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