Browse Prior Art Database

Indenting log statements in a log file to follow call stack depth to make it more readable and a mechanism to indent log statements in a log file to reflect their position in the call stack using function call entry and exit logs as markers

IP.com Disclosure Number: IPCOM000238448D
Publication Date: 2014-Aug-27
Document File: 3 page(s) / 36K

Publishing Venue

The IP.com Prior Art Database

Abstract

Reading log files is the bread and butter for most software professionals, its one of the most widely used mechanisms of investigating a defect report. Log files are ocontineous long lists of traces that a programs writes and often contain multiple streams of logs from multiple threads in the same application interlaced in a single file. Add to that log files are flat, there is no over indication of stack depth at the time the log was emitted. This makes reading log files dificult and time consuming. There are plenty of programs that could help unweaving log statements from separate threads into separate streams for easier consumption, Perl famously was invented to help its creator parse log files. The technique dislcosed herein intends to make the life of who ever reads the log a little bit easier by visualy indicating the call hierarchy through indentations. The solution is to pick up indentation cue based on a function entry exit log. the exit log is printed through a guarenteed distructor call for an object at the end of a function. this achievs 3 clear benefits: - keeps track of call hierarchy, at least for functions that are instrumeted for entry exit logging - prefixes indentation (visual hierarchy if exported as a different format such as xml) to log statements - used to keep track of time spent executing the function providing direct performance numbers in a log using OS level high resolution timers. This is intended to make life of software developers and mainteners that much easy.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 01 of 3

Indenting log statements in a log file to follow call stack depth to make it more readable and a mechanism to indent log statements in a log file to reflect their position in the call stack using function call entry and exit logs as markers

Log files are continuous text files that could get monotonous and difficult to read. It is essential to find the relative importance/position of log statements in a file while reading it or while debugging. A flat structure makes this analysis difficult.

The proposed solution is to indent the log file to reflect the relative position of the function emitting the log statement in a function call stack. This allows quick and easy mechanism to understand the log file using the indentation as a visual cue. Coupled with function entry and exit logs this mechanism gives a perspective to the scope of a function that is easier to read.

I could not find any existing solution to make log files more readable in their native text file form.

The approach is to indent a log file such that the indentation level is correlated with the depth of the call stack at that point in time. The solution can be described as:
1. The actual indentation will reflect the level of logging implemented in the code at hand, and it will ignore the call stack form other libraries such as framework libs or standard runtime libs if they do not implement the same logging mechanism.

2. This mechanism will give a visual cue to the actual function depth from where the log statement has been emitted along with the function entry/exit statements.

3. Store a thread level indentation number and append the corresponding number of delimiters (tabs / spaces / hyphens, or just a number before the log statement denoting the indentation level) to the log statement before writing it to a file.

4. The indentation number is incremented and decremented each time a function entry/exit log is encountered respectively.

Indentation book keeping rides entirely on the back of function entry exit statements these statements themselves are also indented accordingly.

5. Any logging form a function will happen at the same level as its entry/exit log statement.

6. The mechanism can be configured to not emit entry and exit statements but to use the indentation they capture to drive indentation for the other log statements from that function.

7. Log statements could be decorated with XML (or any other hierarchical data representation such as JSON) tags to denote function entry and exit points and the logs from that function appearing as "inner xml" for the top level function tags.

8. Xml tags could also contain properties such as execution duration, parameters to the function, parameter values, return values, there by giving a complete picture of the execution.

9. This mechanism would make automatic log analysis easier due to the added structure.

10. The logging library would also allow a stream flush, followed by stream close after each log output to retain logg...