Runtime Log Control via Bitmap Filtering

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current logging techniques provide a one-size-fits-all solution, making it difficult to balance resource usage with the effectiveness of log files in software applications, as they lack the ability to control log messages at runtime.

Innovation Solution

A log configuration system that preprocesses source code to identify and modify log calls, generating a bitmap to determine whether to write log messages to a file based on user-provided or default specifications, allowing for dynamic control of log messages during runtime.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If all log messages are written to the log file, then logging effectiveness is improved, but resource usage (storage space, processing power, execution time) increases

Engineering Contradiction:
Improvelogging effectivenessVSAvoidresource usage
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent segments log messages into different categories or types, allowing selective logging of only relevant messages. This is achieved through preprocessing source code to identify and categorize different log calls, then applying filtering rules to determine which segments should be written to the log file, thus reducing overall resource usage while maintaining logging effectiveness for critical messages.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies different logging qualities or priorities to different parts of the codebase. By preprocessing source code and generating information about log call locations, the system can apply local filtering rules that preserve detailed logging in critical sections while reducing or eliminating logging in less important sections, optimizing the balance between logging effectiveness and resource consumption.

Inventive Principle:
Principle #3Local quality

2Adaptability or versatility

If logging is controlled at runtime, then adaptability is improved, but device complexity increases

Engineering Contradiction:
Improveruntime control capabilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent performs preliminary actions during the build or preprocessing phase by analyzing source code and generating information about log call locations and characteristics. This pre-computed information is then used at runtime to quickly determine which logs should be written, enabling runtime adaptability without adding significant complexity to the execution path, as the heavy analysis work is done beforehand.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary layer between the logging system and the log file output. This intermediary processes log calls by referencing pre-computed information about log locations and applying filtering rules, thereby enabling runtime control without directly complicating the core logging mechanism or requiring complex real-time analysis during execution.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS10474476B1Techniques for logging information
Publication Date: 2019.11.12 VMWARE INC
  • US10474476B1 patent drawing
  • US10474476B1 patent drawing
  • US10474476B1 patent drawing

AI summary

This application relates generally to logging information, and more particularly to techniques for configuring a software product to have each log call in source code controllable at runtime. The source code can be preprocessed so that individual log calls in the source code can be identified and tracked. Information specifying locations of the log calls can be used to generate a bitmap indicating whether to write log messages (corresponding to the log calls) to a log file. The preprocessed source code can then be compiled into executable code, which can be packaged with the bitmap into an executable product such that the executable code can run based on the bitmap. While the executable code is executing, examples described herein can also allow the bitmap to be updated, allowing control during execution.