Distributed Tracing Context Injection for External Server Telemetry

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional tracer applications struggle to capture accurate telemetry data across servers, platforms, or threads in web-based applications, often requiring manual instrumentation and vendor-specific configurations, and fail to handle network congestion caused by high instrumentation data volumes.

Innovation Solution

A runtime telemetry framework automatically instruments enterprise applications, maintains instrumentation context across threads, and prioritizes spans to minimize network congestion, enabling detailed telemetry data collection even on remote servers with varying protocol support.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If traditional tracer applications are used to capture telemetry data, then manual instrumentation and vendor-specific configurations are required, but accuracy across servers, platforms, and threads deteriorates

Engineering Contradiction:
Improvetelemetry data accuracyVSAvoidmanual instrumentation complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system automatically instruments applications by injecting tracing code at runtime without requiring manual developer intervention. The tracer application self-configures and self-instruments the target application, eliminating the need for manual instrumentation while maintaining accurate telemetry data collection across servers, platforms, and threads.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The tracer application is designed to work universally across multiple servers, platforms, and threading models. It provides a single unified interface that automatically adapts to different environments, eliminating vendor-specific configurations and ensuring consistent telemetry accuracy across heterogeneous distributed systems.

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

2Quantity of substance

If high volume instrumentation data is collected, then detailed telemetry capabilities are improved, but network congestion worsens

Engineering Contradiction:
Improvetelemetry data volumeVSAvoidnetwork congestion
Core Design Contradiction:
Quantity of substanceVSObject-generated harmful factors

Solution Approach 1:

The system extracts and prioritizes only the most essential telemetry data for transmission over the network. By identifying and separating critical span context information from less important data, the system reduces network traffic volume while maintaining the quality and completeness of essential performance insights.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Different levels of telemetry data are assigned different priorities based on their importance. Critical span context information is transmitted with high priority, while less important data is either transmitted with lower priority or processed locally without network transmission, thereby reducing overall network congestion while preserving detailed telemetry capabilities.

Inventive Principle:
Principle #3Local quality

3Loss of information

If span context is propagated across distributed systems, then comprehensive performance insights are improved, but network protocol compatibility deteriorates

Engineering Contradiction:
Improvespan context propagationVSAvoidprotocol support variation
Core Design Contradiction:
Loss of informationVSAdaptability or versatility

Solution Approach 1:

The system uses an intermediary approach by implementing a protocol translation layer that adapts span context propagation to different network protocols. This mediator converts the universal span context format into protocol-specific formats as needed, ensuring comprehensive performance insights are maintained while achieving broad protocol compatibility across distributed systems.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP4211560B1Smart distributed tracing context injection
Publication Date: 2025.08.06 ORACLE INT CORP
  • EP4211560B1 patent drawingFigure 1
  • EP4211560B1 patent drawingFigure 2
  • EP4211560B1 patent drawingFigure 3

AI summary

Disclosed systems relate to propagating tracing across a distributed software application. In an example, an application logs tracing data for a web page from an original server. The application determines, at the web browser, that the web page from the original server requires a request to an external server outside a domain of the original server. The application interrogates the external server to determine whether the external server allows tracing headers in requests. The application updates an allow list, at the web browser, to indicate that the external server allows tracing headers in requests from the original server. The application injects a tracing header in the request based on a result of the interrogation. The application sends, from the web browser to the external server, the request with the tracing header. The external server is configured to log tracing data based on the tracing header.