[slf4j-dev] Repost

[Thorbjørn Ravn Andersen]

Ceki Gulcu skrev  den 28-08-2008 09:56:
>   
>>>   
>>>       
>> I am thinking this over as I am trying to identify which problem it is 
>> that is being solved, instead of just seeing the tool.
>>     
>
> Calling a logger when entering a method or when exiting it is not uncommon. 
> XLogger caters for that use case by extending the methods available in the 
> Logger interface. Isn't  the instrumentation code under discussion also a 
> variation of the aforementioned use case?
>
>   
Yes, you are absolutely right. 


We are applying logging mechanisms to provide a trail in the log file of 
what has happened, and my problem here is that I have a feeling that 
this is not the right way to solve the underlying issue of being able to 
look back in time and see what happened and why (which is usually what 
you need when something goes wrong and you need to find out why).

Currently we think in terms of sending descriptive one-liners to a log 
file.  The programmer determines at coding time what could be 
interesting to log and how interesting each one-liner is, and it is 
determined at deploy time how much of the information the programmer has 
provided that actually should be put in the log file, and which format 
this should be written in.  It is therefore very important that the 
deployer knows ahead of time which pieces of information that are 
important so it is only the unimportant ones that are discarded or not 
logged in the first place.

This is notoriously hard to do as you do not know ahead of time what 
information you need.  Other approaches are that in a situation where 
you KNOW at coding time that you are dealing with something that needs 
to be investigated "after the fact" you grab ALL the information you can 
from all over the place and save it somewhere where the software 
coroners can get to it.

This guy phrases it as "Log Everything All the Time 
<http://highscalability.com/links/goto/121/20/links_weblink>" - 
http://highscalability.com/log-everything-all-time

There are several issues in doing so to be able to emulate a time machine:

* The sheer volume of state data...  A mechanism must be derived which 
allows us to handle this firehose of date.  This is already being solved 
in the logging frameworks so that is nice.  We just need to deal with 
chunks of data instead of text lines.

* Tools are necessary to handle the above data.  Hence it is necessary 
to log rich information and not flattened text lines.  Hence the 
formatting step to a text line must be delayed.  This also allows for 
rerendering a given logfile if information is not clearly visible 
anyway.  (e.g. we use very long descriptive package names which is a 
pain in textbased logfiles).  This work can be seen in the chainsaw GUI 
for the log4j project which allows reading XML-logs.

Plus some more which I am still clarifying to myself.

I hope this helps understanding what it is I am pondering upon, and why 
I think we are going from logs being like status updates in a splash 
screen to an analysis tool on the lines of a debugger.

I'd love to discuss this, if there are anybody else but me who thinks 
this is worth considering :)

-- 
  Thorbjørn





-- 
  Thorbjørn Ravn Andersen          "... plus... Tubular Bells!"