Monitoring Application Dependency Discovery and Root Cause Analysis

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current monitoring systems for complex computer applications face challenges in quickly identifying the root cause of performance issues due to their complexity, requiring extensive manual effort and relying on human administrators to trace dependencies, which can lead to prolonged incident recovery times and increased system resiliency challenges.

Innovation Solution

A monitoring application that collects and reports the operating status of monitored applications and their dependencies, using existing monitoring interfaces to build a logical dependency tree, and employs machine learning techniques to predict potential unhealthy states and generate proactive health reports, while also simulating API problems to test system resilience.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If manual dependency tracing is used to identify root causes, then administrators can understand system dependencies, but incident recovery time increases significantly

Engineering Contradiction:
Improveroot cause identification accuracyVSAvoidincident recovery time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system performs preliminary actions by automatically discovering, mapping, and storing the dependency topology structure before incidents occur. The dependency relationship graph is built in advance by crawling service configurations, API definitions, and runtime dependencies, so that when an incident occurs, the pre-established dependency map enables immediate root cause analysis without manual tracing

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary dependency analysis system that acts as a mediator between monitoring data and administrators. This intermediary automatically correlates incident data with the dependency topology graph, identifies affected services, and presents root cause analysis, eliminating the need for administrators to manually trace through complex dependency chains

Inventive Principle:
Principle #24Intermediary (Mediator)

2Loss of information

If comprehensive monitoring of all dependencies is implemented, then system health visibility improves, but system complexity and resource consumption increase

Engineering Contradiction:
Improvesystem health visibilityVSAvoidmonitoring system complexity
Core Design Contradiction:
Loss of informationVSDevice complexity

Solution Approach 1:

The monitoring system segments the complex dependency landscape into hierarchical levels: critical dependencies that directly impact service health are monitored in detail, while less critical dependencies are monitored at aggregated levels. The dependency relationship graph organizes services into tiers based on their importance and interdependence, allowing focused monitoring resources on the most impactful relationships

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Different monitoring depths and frequencies are applied to different parts of the dependency graph based on local characteristics. Critical path services receive continuous detailed monitoring, while peripheral services use periodic or event-driven monitoring. The system adapts monitoring intensity to the local importance and risk profile of each dependency relationship

Inventive Principle:
Principle #3Local quality

3Productivity

If automated dependency discovery is implemented, then root cause identification speed improves, but implementation complexity increases

Engineering Contradiction:
Improveroot cause identification speedVSAvoiddiscovery system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The discovery system uses universal, standardized approaches to map diverse dependency types. It employs general-purpose techniques such as analyzing service configuration files, parsing API definitions, and intercepting network traffic patterns that work across different service architectures (monolithic, microservices, event-driven). This universal methodology reduces implementation complexity compared to creating specialized discovery mechanisms for each service type

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

Solution Approach 2:

The system creates simplified copies or representations of complex dependency relationships through the dependency relationship graph. Instead of managing the full complexity of actual service interactions, it generates abstracted models that capture essential dependency patterns, service relationships, and data flows, making the system manageable and implementable without replicating every detail of the underlying infrastructure

Inventive Principle:
Principle #26Copying

Data Source

PatentUS20240427693A1Intelligent services for application dependency discovery, reporting, and management tool
Publication Date: 2024.12.26 CAPITAL ONE SERVICES LLC
  • US20240427693A1 patent drawing
  • US20240427693A1 patent drawing
  • US20240427693A1 patent drawing

AI summary

Techniques for monitoring operating statuses of an application and its dependencies are provided. A monitoring application may collect and report the operating status of the monitored application and each dependency. Through use of existing monitoring interfaces, the monitoring application can collect operating status without requiring modification of the underlying monitored application or dependencies. The monitoring application may determine a problem service that is a root cause of an unhealthy state of the monitored application. Dependency analyzer and discovery crawler techniques may automatically configure and update the monitoring application. Machine learning techniques may be used to determine patterns of performance based on system state information associated with performance events and provide health reports relative to a baseline status of the monitored application. Also provided are techniques for testing a response of the monitored application through modifications to API calls. Such tests may be used to train the machine learning model.