Event Logging API Structured Key-Value Dispatch

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional event logging techniques face challenges in processing unstructured data, sending event messages to multiple destinations, and efficiently managing logging destinations, leading to difficulties in data analysis and management.

Innovation Solution

An event logging API (ELAPI) that abstracts applications from their logging destinations, using key-value pairs for structured event data, allowing multiple sinks per logical target with failover capabilities and flexible formatting options, enabling efficient data dispatch and formatting.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If conventional logging interfaces permit free form event messages, then application developers can easily send logging information, but data analysis and interpretation become extremely difficult

Engineering Contradiction:
Improveease of sending log messagesVSAvoiddifficulty of analyzing log data
Core Design Contradiction:
Ease of operationVSDifficulty of detecting and measuring

Solution Approach 1:

The patent changes the fundamental parameter of log message structure from free-form text to structured key-value pairs. Each log message is defined by a set of keys (attributes) and their corresponding values, enabling systematic parsing and analysis while maintaining ease of generation through the ELAPI interface.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent segments log messages into discrete key-value pairs where each key represents a specific attribute (e.g., timestamp, host, user, event_type) and each value provides the corresponding data. This segmentation allows for easy parsing, filtering, and analysis of individual components without processing entire unstructured messages.

Inventive Principle:
Principle #1Segmentation

2Device complexity

If applications use fixed logging destinations, then logging implementation is simple, but adaptability to change destinations or add multiple destinations is difficult

Engineering Contradiction:
Improvesimplicity of logging implementationVSAvoidability to change logging destinations
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent introduces an intermediary layer called the Event Logging API (ELAPI) that sits between the application and the logging destination. This intermediary abstracts the destination details from the application, allowing simple implementation through a single interface while providing versatile destination options including files, databases, syslog, and custom destinations without modifying application code.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The ELAPI provides a universal interface that can write to multiple different logging destinations simultaneously or sequentially. The same application code can redirect logs to different destinations (e.g., production environment uses syslog, development environment uses console) without any code changes, achieving both simplicity and versatility.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If applications modify logging destinations and data formatting manually, then logging can be adapted to different requirements, but the process is time consuming and error prone

Engineering Contradiction:
Improveflexibility in logging configurationVSAvoidtime for modifying logging setup
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The ELAPI provides self-service configuration capabilities where logging destinations and formatting can be defined once and automatically applied to all subsequent log messages. The system automatically handles destination selection, data formatting, and error handling without requiring manual intervention or code modifications, enabling rapid adaptation to different requirements.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent allows preliminary definition of logging destinations, formats, and routing rules before the actual logging occurs. Configuration files or metadata can specify destination details and formatting requirements in advance, so that when logging needs to be adapted to different requirements, the system can quickly switch between pre-defined configurations without time-consuming manual setup.

Inventive Principle:
Principle #10Preliminary action

4Quantity of substance

If logging data is sent to multiple destinations with different interfaces, then comprehensive data collection is achieved, but implementation complexity increases significantly

Engineering Contradiction:
Improvenumber of data destinationsVSAvoidcomplexity of multiple interfaces
Core Design Contradiction:
Quantity of substanceVSDevice complexity

Solution Approach 1:

The patent merges multiple logging destination interfaces into a single unified ELAPI interface. Instead of requiring separate code implementations for console logging, file logging, database logging, and syslog, the ELAPI combines all these operations into one standardized interface that handles destination routing internally, achieving comprehensive data collection without implementation complexity.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS8997116B2Event logging application programming interface (API)
Publication Date: 2015.03.31 RED HAT INC
  • US8997116B2 patent drawing
  • US8997116B2 patent drawing
  • US8997116B2 patent drawing

AI summary

An event logging interface on a computer system is used to record an event when an application hosted by the computer system encounters the event. The event logging interface receives data pertaining to an event from the application. Using the event logging interface, the computer system determines a logical target of the event, and determines one or more physical destinations referenced by the logical target. The data is then dispatched to one of the physical destinations.