Data Stream Language With Dynamic Thresholds for Software Instrumentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional instrumentation techniques for complex software applications are inadequate for fast-paced development cycles, causing significant delays in data assimilation and report generation, and vendor-based solutions are inflexible and time-consuming.

Innovation Solution

A data stream processing language and system that processes data streams from instrumented software, allowing flexible and efficient data analysis through a network of blocks with input and output ports, supporting dynamic threshold comparisons and metadata separation, enabling real-time reporting without modifying the instrumented code.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If conventional instrumentation techniques (logging to files or printing to screens) are used for complex distributed applications, then implementation is simple, but the system cannot handle complex distributed architectures and real-time analysis requirements

Engineering Contradiction:
Improvecapability to handle complex distributed applicationsVSAvoidinstrumentation system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary data stream processing system that sits between the distributed application components and the analysis tools. This intermediary collects data from multiple sources, standardizes it into a common format, and makes it available for real-time processing without requiring complex instrumentation in each distributed component.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the instrumentation system into independent modular components including data collection agents, stream processing engines, and analysis modules. Each component handles specific tasks independently, allowing the system to scale to complex distributed architectures without increasing overall system complexity.

Inventive Principle:
Principle #1Segmentation

2Manufacturing precision

If vendor-based expert services are used for code instrumentation, then instrumentation quality is improved, but significant time overhead is introduced making it unsuitable for fast-paced development cycles

Engineering Contradiction:
Improveinstrumentation qualityVSAvoidinstrumentation time overhead
Core Design Contradiction:
Manufacturing precisionVSLoss of time

Solution Approach 1:

The patent enables developers to perform instrumentation themselves using automated tools and standardized templates, eliminating the need for external vendor experts. The system provides self-service capabilities including automatic code instrumentation, data stream configuration, and analysis setup that maintain high quality while reducing time overhead significantly.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent implements preliminary action by providing pre-configured instrumentation templates, standardized data collection patterns, and ready-to-use analysis configurations. These preliminary preparations eliminate the need for time-consuming custom instrumentation work while maintaining instrumentation quality through proven patterns.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If conventional batch processing techniques are used for data assimilation and analysis, then implementation is straightforward, but significant delays occur between problem occurrence and detection

Engineering Contradiction:
Improvedata analysis speedVSAvoiddelay in problem detection
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent implements continuous data stream processing that operates without interruption between data generation and analysis. Unlike batch processing that waits for data accumulation, the continuous stream processing architecture immediately analyzes data as it arrives, eliminating delays in problem detection while maintaining straightforward implementation through standardized processing operators.

Inventive Principle:
Principle #20Continuity of useful action

4Productivity

If flexible and efficient data analysis is enabled through data stream processing language, then real-time reporting capability is improved, but system complexity increases

Engineering Contradiction:
Improvereal-time reporting capabilityVSAvoiddata stream processing system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements a universal data stream processing language with a standardized set of operators that can handle multiple types of analysis tasks including filtering, aggregation, correlation, and alerting. This multi-functional approach enables real-time reporting across different application scenarios without requiring separate complex systems for each analysis type.

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

Data Source

PatentEP3982265B1Data stream processing language for analyzing instrumented software
Publication Date: 2025.12.03 SPLUNK INC
  • EP3982265B1 patent drawingFigure 1
  • EP3982265B1 patent drawingFigure 2
  • EP3982265B1 patent drawingFigure 3

AI summary

An instrumentation analysis system processes data streams by executing instructions specified using a data stream language program. The data stream language allows users to specify a search condition using a find block for identifying the set of data streams processed by the data stream language program. The set of identified data streams may change dynamically. The data stream language allows users to group data streams into sets of data streams based on distinct values of one or more metadata attributes associated with the input data streams. The data stream language allows users to specify a threshold block for determining whether data values of input data streams are outside boundaries specified using low/high thresholds. The elements of the set of data streams input to the threshold block can dynamically change. The low/high threshold values can be specified as data streams and can dynamically change.