Browse Prior Art Database

Search Engine based Prioritized Software Logging

IP.com Disclosure Number: IPCOM000143689D
Original Publication Date: 2007-Jan-10
Included in the Prior Art Database: 2007-Jan-10
Document File: 4 page(s) / 55K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

Logging in software is done by outputting log entries from various modules/objects to one or several log files with some structured format. This log is later analyzed to find and fix errors. However, if problems arise when a customer uses some software, tools such as debuggers, memory leak checkers, profilers, etc. cannot be used and logging becomes crucial. Although filters can be applied, the log entries cannot be ordered by relevance which states a problem e.g. in cases where a cause for a problem is spread over time or the log size is big. Specific software problems require producing special versions of the software introducing increased logging in suspected areas which causes the customer a needless upgrade in order to analyze the bug. At present, many trace points are spread in the application code, each producing a log entry when crossed. Each trace point adds some information like time, place, variable values, error states, log level, etc. to the log. The logs are ordered by time and may be filtered by level of detail in some hard-coded or configurable mechanism. Triggers may be used to identify "hotspots" of specific problems so that more elaborate logging in a time window around the trigger can be utilized. Today's logging principle is illustrated in Figures 1 and 2.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

S

Search Engine based Prioritized Software Logging

Idea: Adam Abrams, IL-Hod HaSharon

Logging in software is done by outputting log entries from various modules/objects to one or several log files with some structured format. This log is later analyzed to find and fix errors. However, if problems arise when a customer uses some software, tools such as debuggers, memory leak checkers, profilers, etc. cannot be used and logging becomes crucial. Although filters can be applied, the log entries cannot be ordered by relevance which states a problem e.g. in cases where a cause for a problem is spread over time or the log size is big. Specific software problems require producing special versions of the software introducing increased logging in suspected areas which causes the customer a needless upgrade in order to analyze the bug.

At present, many trace points are spread in the application code, each producing a log entry when crossed. Each trace point adds some information like time, place, variable values, error states, log level, etc. to the log. The logs are ordered by time and may be filtered by level of detail in some hard- coded or configurable mechanism. Triggers may be used to identify "hotspots" of specific problems so that more elaborate logging in a time window around the trigger can be utilized. Today's logging principle is illustrated in Figures 1 and 2.

A novel solution to the problem mentioned above is presented in the following. The logging is done always at maximum level, but only log entries with sufficient relevance are kept. A search phrase is used to describe the specific problem to the search engine which in turn uses this phrase to identify candidate log entries that fit without changing the code. The log entries are ordered by relevance which is obtained by using the search phrase and support information. The entries may be linked (hypertext) to a time-based log for further study and the log size can be fixed to a comfortable size. Integrating this method into an application framework allows for reducing the amount of trace commands spread out in the code. This can be done by utilizing a built-in messaging sub-system to produce logs out of relevant messages. The presented solution is illustrated in Figure 3.

In a specific embodiment, support information helping to identify log entry relevance can be e.g. searching for keys or values in the log entries. Support information can also be information which is part of the same flow, information from the same time window or error/exceptional conditions. A formula to calculate the relevance can be the following one:

 ) (

  * )
(

  *...