Microservice Trace Tagging and Filtering for Complete Data Exchange
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Microservices architectures face increased system complexity, coordination challenges, and communication overhead, with existing tools like APM tools providing incomplete datasets and custom logging practices lacking standardization, leading to inefficient issue resolution and performance analysis.
Innovation Solution
A data exchange manager that captures and analyzes exchanged data, providing end-to-end tracing, predictive analytics, and automated testing, with a user interface for filtering and tagging execution traces, and a Web API for trace data processing and insights.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If APM tools are used to monitor microservices, then system performance can be monitored, but the datasets provided are incomplete and lack standardization
Solution Approach 1:
The patent introduces a data exchange manager as an intermediary component that sits between microservices and monitoring tools. This manager captures complete execution traces including all exchanged data, and provides standardized filtering and tagging mechanisms. The intermediary consolidates fragmented data from multiple sources into a unified, complete dataset that maintains measurement precision while eliminating information loss.
Solution Approach 2:
The execution trace data structure serves multiple functions simultaneously: it captures complete request-response cycles, provides standardized filtering criteria for different monitoring needs, enables tagging for issue resolution, and supplies data for both APM tools and custom logging. This multi-functional approach eliminates the need for separate monitoring systems and ensures data completeness across all monitoring purposes.
2Ease of operation
If custom logging practices are implemented, then specific issues can be tracked, but standardization is lacking and coordination between teams is difficult
Solution Approach 1:
The patent transforms custom logging approaches by introducing standardized parameters and filtering criteria that can be consistently applied across all microservices. The execution traces include standardized fields for filtering, and the data exchange manager provides uniform tagging mechanisms. This parameter standardization maintains ease of operation for issue tracking while eliminating the complexity of coordinating custom logging practices between teams.
Solution Approach 2:
The patent segments the logging system into standardized components: execution traces with standardized fields, filtering criteria defined by the data exchange manager, and tagging mechanisms for issue resolution. This segmentation allows each component to be independently standardized and reused, maintaining operational ease while reducing coordination complexity through standardization.
3Measurement precision
If extensive tagging rules and filtering criteria are implemented, then execution traces can be precisely identified, but system complexity increases
Solution Approach 1:
The patent applies preliminary action by pre-defining standardized filtering criteria and tagging rules within the data exchange manager before execution traces are generated. The manager automatically applies these pre-established rules to capture relevant traces, eliminating the need for complex ad-hoc filtering during runtime. This maintains precise trace identification while reducing system complexity through pre-configuration.
Solution Approach 2:
The data exchange manager provides self-service functionality by automatically applying standardized filtering criteria and tagging rules to execution traces without requiring manual configuration for each trace. The system self-manages the complexity of trace identification through built-in mechanisms, maintaining precision while reducing the operational complexity burden on users.
Data Source
AI summary
A method, comprising: displaying a first screen for specifying one or more tagging rules for a microservice; receiving, via the first screen, a first user input specifying a tagging rule, the tagging rule including a tag and a tagging condition that needs to be satisfied by an execution trace in order for the respective tag to be appended to the execution trace; displaying a second screen for specifying one or more filtering criteria, the second screen including an input component that is populated with the respective tag; receiving a second user input specifying a filtering condition, the second user input being received, at least in part, via the second screen; and displaying a list of execution traces that satisfy the filtering condition.