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!" _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
