Distributed Tracing for API Failure Monitoring

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current monitoring systems for distributed network systems providing cloud services lack accuracy in tracking failures, as they primarily focus on HTTP server-side failures and do not account for user-perceived errors or time thresholds, which can lead to incomplete reporting and potential financial consequences for service providers.

Innovation Solution

Implementing a system that receives API requests, assigns unique identifiers, records receipt times, and associates system state changes to track failures, including time threshold failures, to provide a more comprehensive and accurate monitoring of service availability and responsiveness.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If conventional HTTP server-side failure monitoring is used, then implementation complexity is low, but measurement precision of failure rates is insufficient

Engineering Contradiction:
Improvefailure rate measurement accuracyVSAvoidmonitoring system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The monitoring system is segmented into multiple independent components: distributed tracing agents deployed across individual services, a centralized tracing system for collecting traces, and a failure analysis system for processing trace data. This segmentation allows each component to focus on specific tasks, improving measurement precision while managing complexity through modular architecture.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Distributed traces serve as an intermediary mechanism that captures user request flow across service boundaries. The trace system mediates between individual service operations and overall system failure analysis, enabling comprehensive failure rate measurement without requiring direct complex integration between all services.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If only server-side HTTP errors are tracked, then monitoring implementation is simple, but reliability of failure metrics is insufficient

Engineering Contradiction:
Improvefailure metric reliabilityVSAvoidmonitoring system complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

Instead of only monitoring server-side error responses, the system inverts the approach by tracing user requests from the client perspective through distributed tracing. This captures failures that may not generate standard HTTP error codes, such as timeouts, silent failures, or operational errors, thereby improving reliability of failure metrics.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The distributed tracing system serves multiple functions simultaneously: it tracks user request flow, measures service availability, detects failures across different error types, and provides diagnostic information. This multi-functionality improves metric reliability while managing complexity through a unified tracing infrastructure.

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

3Loss of information

If user-perceived errors are not accounted for, then monitoring system complexity is low, but loss of information about actual service quality occurs

Engineering Contradiction:
Improveservice quality information completenessVSAvoidmonitoring system complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The system performs preliminary action by injecting trace identifiers at the beginning of user requests and propagating them through all subsequent service calls. This preliminary tracing action captures the complete user experience journey before failures occur, preserving information about user-perceived service quality that would otherwise be lost.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The distributed tracing system provides feedback by collecting and analyzing trace data to identify patterns of user-perceived failures. This feedback loop enables the system to detect and report service quality issues that differ from traditional server-side error metrics, reducing information loss about actual service quality.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS9813307B2Methods and systems of monitoring failures in a distributed network system
Publication Date: 2017.11.07 RACKSPACE US
  • US9813307B2 patent drawing
  • US9813307B2 patent drawing
  • US9813307B2 patent drawing

AI summary

In one embodiment, the methods and systems may include receiving an Application Program Interface (API) request, assigning a unique identifier to the API request, recording, in association with the unique identifier, receipt time corresponding to a time at which the API request is received, and associating one or more system state changes with the unique identifier. Advantageously, the present embodiments provide a more accurate failure monitoring and associated metrics. Additional benefits and advantages of the present embodiments will become evident in the following description.