Cross-domain transaction contextualization service
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Large-scale distributed applications face challenges in analyzing and monitoring transactions across multiple domains due to the complexity of correlating events from different infrastructure and application layers, leading to incomplete root cause analysis and performance degradation.
Innovation Solution
A topology-based domain transversal analysis service that correlates topologies across different domains, creating cross-domain 'stories' for anomalies by associating events with nodes in the execution path, providing contextualization of events with respect to transaction types and domains, using analysts for each domain to collect and process information and an evaluation engine to maintain topology maps and generate transaction stories.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If distributed tracing tools are used to trace execution paths across software components, then transaction monitoring capability is improved, but the complexity of correlating events from different domains increases
Solution Approach 1:
The system segments the distributed application into multiple domains (infrastructure domain, application domain, etc.) and creates separate topology maps for each domain. Event collection and correlation are performed domain-by-domain through specialized analysts, breaking down the complex multi-domain correlation problem into manageable domain-specific tasks that can be processed independently and then integrated.
2Measurement precision
If multiple domains are monitored separately with different tools, then domain-specific monitoring precision is improved, but loss of information across domain boundaries increases
Solution Approach 1:
The system introduces domain-specific analysts as intermediary components between different monitoring tools and the central evaluation engine. Each analyst collects and processes events from its domain using domain-appropriate tools and methods, then transforms this information into a standardized format that can be integrated with other domains, preventing information loss during cross-domain correlation.
Solution Approach 2:
The evaluation engine serves multiple functions: it maintains topology maps for different domains, collects events from multiple domain analysts, performs cross-domain correlation, and generates unified transaction stories. This multi-functional approach enables the system to preserve information across domains while maintaining domain-specific monitoring capabilities.
3Reliability
If comprehensive event collection from all domains is performed, then root cause analysis completeness is improved, but processing time and system complexity increase
Solution Approach 1:
The system performs preliminary actions by maintaining pre-built topology maps for each domain that define the execution paths and relationships between components. When an anomaly is detected, the evaluation engine uses these pre-established topology structures to quickly correlate events and generate transaction stories, avoiding the need to perform complex correlation analysis from scratch and significantly reducing processing time.
4Reliability
If cross-domain correlation is implemented to provide comprehensive transaction context, then analytical value is improved, but device complexity increases
Solution Approach 1:
The system adds a domain dimension to the traditional single-domain tracing approach by creating topology maps and event collection mechanisms for multiple domains (infrastructure, application, etc.). This dimensional expansion enables comprehensive cross-domain correlation and contextualization of events within execution paths, providing much higher analytical value for root cause analysis while managing complexity through structured domain separation.
Data Source
AI summary
A topology-based transversal analysis service has been created that correlates topologies of different domains of a distributed application and creates cross-domain “stories” for the different types of transactions provided by the distributed application. A “story” for a transaction type associates an event(s) with a node in an execution path of the transaction type. This provides context to the event(s) with respect to the transaction type (“transaction contextualization”) and their potential business impact. The story is a journal of previously detected events and/or information based on previously detected events. The events have been detected over multiple instances of a transaction type and the journal is contextualized within an aggregate of execution paths of the multiple instances of the transaction type. The story can be considered a computed, ongoing narrative around application and infrastructure performance events, and the narrative grows as more performance-related events are detected.