Service Call Model for Error Localization in Distributed Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In distributed service systems, locating and monitoring errors is complex, time-consuming, and often inaccurate, leading to delayed error detection and alert issuance due to the intricacy of service call relationships and the reliance on log-based methods.

Innovation Solution

A method and device for acquiring and processing service call chains in a distributed system, constructing a service call model based on call sequences, and analyzing data to quickly identify errors and monitor service performance, utilizing big data information for improved error localization and system reliability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If error location is based on log or service call path tracking, then error can be located, but the method is complex, time-consuming, and less accurate

Engineering Contradiction:
Improveerror location accuracyVSAvoiderror location complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces a service call model as an intermediary structure that abstracts the complex service call relationships in a distributed system. This model pre-establishes the call paths and dependencies between services, allowing error location to query the model directly rather than parsing logs or tracking calls in real-time, thus improving accuracy while reducing complexity

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The service call model is constructed in advance by analyzing historical service call data and establishing the topology structure of service dependencies. This preliminary action captures the complex call relationships before errors occur, enabling fast and accurate error location when failures happen without needing to perform complex real-time analysis

Inventive Principle:
Principle #10Preliminary action

2Reliability

If failed service call is monitored after error occurs, then monitoring can be performed, but no error can be avoided and no error alert can be issued in advance

Engineering Contradiction:
Improveerror detection capabilityVSAvoiderror detection delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The service call model pre-establishes the topology structure and call relationships between services before errors occur. By having this model ready in advance, the system can quickly query and analyze error propagation paths when failures happen, reducing detection delay and enabling faster alert issuance

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements a monitoring mechanism that uses the service call model to track actual service calls against the expected topology. When discrepancies or failures are detected, the system provides feedback by querying the model to identify affected services and propagate error information, enabling timely alerts and faster response to maintain system reliability

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS10671474B2Monitoring node usage in a distributed system
Publication Date: 2020.06.02 ADVANCED NEW TECHNOLOGIES CO LTD
  • US10671474B2 patent drawing
  • US10671474B2 patent drawing
  • US10671474B2 patent drawing

AI summary

One or more service call chains in a distributed service system are identified, each service call chain including one or more service nodes that are sequentially called by clients of the distributed service system. A service call model corresponding to a particular service call chain is generated from the one or more service call chains. Calls to the particular service call chain by the clients of the distributed service system are identified. Performance statistics in the service call model are updated for the particular service call chain, wherein the performance statistics is updated based on the identified calls to the particular service call chain. A performance problem associated with the particular service call chain is identified based on the updated performance statistics. In response to identifying the performance problem associated with the particular service call chain, corrective action for the identified performance problem is initiated.