Network Service Activity Model for Error Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for detecting problems and performance issues in computer systems and networks are inefficient, often requiring substantial infrastructure and may fail to detect intermittent errors or attribute errors to the wrong services, leading to delayed detection and increased expenses.
Innovation Solution
An activity model is generated by monitoring input and output data to predict normal behavior, allowing for the analysis of collected data to determine if the system is operating correctly and identifying potential issues, with the ability to query the model for likely outputs given input data and recursively query other hosts to isolate the source of errors.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If alarm data processing is used to detect system problems, then problem detection capability is improved, but infrastructure complexity and cost increase substantially
Solution Approach 1:
The system uses existing service logs and data already generated by the services themselves to detect problems, rather than requiring separate dedicated monitoring infrastructure. Each service's own data serves the detection function, eliminating the need for additional specialized hardware or software components.
Solution Approach 2:
The patent creates a unified monitoring framework that can detect multiple types of problems across different services using a single system. The activity model serves multiple purposes: detecting failures, analyzing service dependencies, and identifying root causes across the entire network, replacing multiple specialized monitoring tools.
2Reliability
If repeated probing is used to detect service availability, then service status monitoring is improved, but detection delay increases
Solution Approach 1:
The system continuously collects and analyzes service data in real-time, maintaining an up-to-date activity model before problems occur. This preliminary continuous monitoring eliminates the need to wait for scheduled probe intervals, enabling immediate detection of service failures as they happen rather than at the next scheduled check.
Solution Approach 2:
Instead of periodic discrete probing, the system maintains continuous monitoring of service activities by constantly analyzing incoming data streams. This continuous action ensures service status is always current, eliminating gaps between detection attempts and ensuring immediate awareness of any service changes.
3Reliability
If conventional error detection methods are used, then error detection is achieved, but error attribution accuracy decreases due to viewpoint dependency
Solution Approach 1:
The patent analyzes service data from the perspective of each individual service and its specific dependencies rather than applying a uniform monitoring approach. Each service's activity model is customized to its particular data flows and relationships, enabling accurate attribution of errors to the specific local service or dependency that caused them, rather than generic blame assignment.
Solution Approach 2:
The system breaks down the monolithic error detection problem into individual service-level activity models. Each service is analyzed separately with its own data collection and analysis pipeline, allowing precise identification of which specific service or dependency relationship is problematic, rather than treating the entire system as a single unit.
4Quantity of substance
If centralized alarm collection is used, then data aggregation is improved, but data detail and underlying cause visibility decrease
Solution Approach 1:
The system maintains distributed service-level activity models at each service or monitoring point rather than consolidating all data into a single centralized repository. This segmentation preserves the detailed contextual information about each service's specific data flows and relationships, which would be lost in centralized aggregation, while still providing comprehensive system-wide coverage.
Solution Approach 2:
Instead of flattening all alarm data into a single centralized view, the system creates a multi-dimensional structure where each service has its own activity model layer. This dimensional organization preserves detailed service-specific information while enabling system-wide correlation, allowing users to drill down from aggregate views to detailed service-level data as needed.
Data Source
AI summary
An activity model is generated at a computer. The activity model may be generated by monitoring incoming and outgoing data in the computer. The collected data is analyzed to form a graph that describes and predicts what output is generated in response to received input. Later, a window of input and output data is collected from the computer. This collected window of data is used to query the activity model. The graph in the activity model is then used to give the probability that the collected window of data was collected from the computer used to generate the activity model. A high probability indicates that the computer is performing normally, while a low probability indicates that the computer may behaving erratically and there may be a problem with the computer.