Browse Prior Art Database

Dynamic logging severity based on error level and frequency

IP.com Disclosure Number: IPCOM000239773D
Publication Date: 2014-Dec-01
Document File: 3 page(s) / 36K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method for dynamic logging severity based on error level and frequency is disclosed.

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

Page 01 of 3

Dynamic logging severity based on error level and frequency

Disclosed is a method for dynamic logging severity based on error level and frequency.

Logging is a very important part of software engineering to aid in debugging problems. Typically, most logging systems today include a range of severities (debug, warning, error, critical) which can be set by the owner in a relatively static manner. This relatively

static manner is a problem because in certain cases, more intense levels of logging may be required to investigate issues, whereas in other cases when the system is running without errors, the system should not waste resources on unnecessary intense levels of logging.

An additional solution is required to make the logging infrastructure more efficient. The

disclosed method aims at doing this by dynamically turning on intense levels of logging

when certain areas of interest are "hot" with errors, then progressively tuning the log level to a lesser severity when errors are not occurring (the area of interest becomes "cooler"). A dynamic logging system is disclosed that aims to display relevant logging information while not flooding logs with debugging output. Normally, logging is either statically controlled (i.e. always on or always off) or manually toggled. When toggled on, a normal logging system will have levels of severity that the user can set that will act as a threshold to filter unwanted log messages in order to prevent unnecessary log clutter (e.g. TRACE, DEBUG, etc...). These levels of logging are hard coded into the source code and only the messages will be logged if the user specified threshold allows it.

When developing software, software problems (bugs) may not be detected because there are little warnings about certain areas of code that may be causing an error. Either the logging is not being monitored, the threshold is set too low, or the user simply isn't looking at the logs and the warnings get lost in a sea of unnecessarily verbose logs. Also, customers may not know if a bug has occurred until the software crashes and, typically, the logs may be so extensive that the corresponding error messages

were overwritten or were lost in the sea of messages. This can make it difficult for

developers to get the logs and determine the cause of the bug.

These types of problems may be avoided by dynamically logging error messages based on the frequency of the error being hit. With this in mind, the error logging framework uses a "heat map." As an error occurs, the "temperature" relating to the segment of code increases. Similarly, as time goes on and/or the segment completes successfully, the "temperature" decreases. Thus, the threshold for logging may be changed by the user. The threshold can be a value or a percentage. Any area of code that has a "temperature" above the set level causes logging. This allows the user to set the threshold at 0, for example, to show all logging messages, or be very picky and only show th...