Originally shared by Thomas Mueller (dummzeuch)

Originally shared by Thomas Mueller (dummzeuch)

In the olden days, when log files were huge and hard disks were small, programs used a single character as the first character in a line to mark the severity of the log entry, similar to this:

! This is an error message
+ This is a warning message
: This is a normal message
# This is a debug message
  I don't know about this (no marker character)
Depending on the program the line also contained a time stamp directly after that character.

This example is made up, I don't remember which characters were actually used. I am only pretty sure of the "!" being used for errors.

I could not find any description of a log file that uses this kind of syntax. Is there a Standard for this? If yes, were is it described?

I could make up my own system easily but if there is a standard I would like to use it.
http://stackoverflow.com/q/28150777/49925

Comments

  1. IMO, Hard disk volume isn't an issue in normal desktop platform now. For readability and easy debug, no more one char prefix to distinguish from different message type in desktop platform. So I suggest you can use log4j or log4net logging way.

    Of course, If your app running on embedded system or disk volume is still an issue, just do what you as you mentioned above.

    FYR

    ReplyDelete
  2. I never based my logging on a standard, and I don't think I've looked to see if there is one, so - I did like most - rolled my own.

    I start every log line with [process id] {timestamp (tread id) memory manager allocation summary].

    [8160] {14:03:03,037 (4248) 49449k}

    My logs have a selection of "tags", such as #BAD - which usually indicates something went catastrophically bad. #WTF  when something very unusual was happened.
    I also have ###START and ###STOP markers.

    Some the log text is prefixed with
    {d} for debug
    {i} for info
    {w} for warning
    {e} for error

    and certain sequences are also output with an TSomeTaskName - Start (id=xxxx) at the beginning, and TSomeTaskName - End (id=xxxx) - which makes it easy to create a "block" in an analyzer.

    I wrote a log analyzer which shows me what happens in parallel, by breaking down the logfile, and showing it as a grid where each thread has a column of it's own.  And - a couple of  previous/next error buttons :)

    ReplyDelete
  3. Some background: I'm not writing this to an actual file (I use SmartInspect for that). This is for a callback that shows selected log messages to the user. So far, it uses a TMemo for the display which makes it difficult to distinguish between errors, warnings and additional information messages. I want to add some colour coding to this display. The easiest (I'm a lazy bastard ™, remember?) way is replacing the TMemo with a TSynEdit control and add a prefix to the lines based on which the control changes the line's background colour. This works fine and the users like it very much. Doing that reminded me of Fidonet times where log files of several programs used these prefixes (Frontdoor for example, Squish for another) so I thought there might actually be (or have been) a standard for this which I could use. Hence the StackOverflow question. I guess that's typical overengineering...

    ReplyDelete
  4. Hmm... interesting idea. A logging standard. I guess it would evolve to something similar to XML with lots of MUSTs and MAYs and in the end writing a log entry will consume more CPU than the actual event that was logged. (Thomas, no disrespect intended).

    I do something similar to what Lars describes. It's a bit simpler though because i use position and length. Something like:

    LogString := FixStr(aSeverity) + FixStr(aModuleName, 10) + FixStr(aPeerAddress) + FixStr(aSessionId) and so on...

    Thus i can write a logreader application with analysis functionality (an advanced grid like DevExpress in Provider mode) and whenever i'm debugging and/or developing (like implementing a new API or some such) i simply do Memo1.Lines.Add instead of "file append".

    The memo will have a fixed font and a vertical scroll bar of course.

    The downside is that when you realize there's something more that needs to go into the logs the format will change. You could alleviate this using a version number of course.

    ReplyDelete

Post a Comment