Microservice Anomaly Management via Dependency Mapping and ML Prediction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In complex distributed software applications, identifying and managing microservice anomalies and outages is challenging due to intricate dependencies between microservices and reuse services, making it difficult to determine the impact of service degradations on user-facing capabilities and notify affected users appropriately.
Innovation Solution
A system that utilizes a dependency map and a trained degradation prediction model to monitor microservices, detect service degradations, and raise alerts to affected users, while distinguishing between critical and non-critical impacts, and predicting potential degradations using telemetry data and machine learning.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If monitoring is performed on all microservices to detect service degradations, then the ability to identify affected capabilities is improved, but the complexity of managing and processing monitoring data increases
Solution Approach 1:
The patent segments the monitoring system by separating microservices into critical and non-critical categories based on their dependency relationships. By dividing the monitoring scope based on service importance and impact analysis, the system reduces the complexity of processing all microservice data uniformly while maintaining accurate detection for critical services that affect user-facing capabilities.
Solution Approach 2:
The patent applies different monitoring strategies based on the local characteristics of each microservice. Services with high impact on user capabilities receive enhanced monitoring and alerting, while services with lower impact are monitored with reduced intensity. This localized approach optimizes the balance between detection accuracy and system complexity.
2Reliability
If alerts are raised for all detected service degradations, then user notification completeness is improved, but the number of false alerts and unnecessary notifications increases
Solution Approach 1:
The patent performs preliminary impact analysis before raising alerts by evaluating the dependency relationships between microservices and user-facing capabilities. The system predicts which service degradations will actually affect user capabilities based on pre-established dependency maps and service criticality assessments, thereby filtering out false alerts before they are generated.
Solution Approach 2:
The system incorporates feedback mechanisms that continuously monitor service health metrics and adjust alerting thresholds based on actual service behavior patterns. By learning from historical service degradations and their impact on capabilities, the system refines its alerting logic to reduce false positives while maintaining reliable notifications for actual issues.
3Measurement precision
If the system monitors all dependencies between microservices and reuse services, then the accuracy of impact determination is improved, but the processing time and resource consumption increase
Solution Approach 1:
The patent applies partial monitoring by focusing resource allocation on the most critical dependency relationships. Instead of uniformly analyzing all microservice dependencies, the system identifies and intensively monitors only those dependencies that are most likely to impact user-facing capabilities, based on service criticality ratings and dependency graph analysis. This selective approach maintains high impact analysis accuracy while reducing processing time.
Data Source
AI summary
Various aspects relate to a distributed software application. A distributed software application is a software application that is distributed among multiple microservices. The different microservices are different processes that communicate with each other not as a monolithic software application by directly invoking each other's APIs within a single executable process, but using a different communication mechanism, e.g., by using a message passing functionality such as a message bus, a message queue, or a service mesh. In addition to internally communicating with each other and consuming each other's functionality, the microservices may also consume functionality provided by reuse services external to the software application. Such reuse services may be used by multiple software applications and can include, e.g., a logging service, a database service, and/or a storage service, and the like.