Transaction Log Capture for Cloud Microservice Root Cause Analysis
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing server-side software application debugging and error evaluation tools are reactive and lack proactive identification of issues, making it difficult to diagnose problems in cloud-computing environments where runtime containers can be shut down unexpectedly, and they are limited in data capture and predictive capabilities.
Innovation Solution
A system and method for monitoring server-side application execution in a cloud environment using microservices with agents that collect execution information, assign unique identifiers to transactions, and log execution details, allowing for root cause analysis and automated corrective actions based on machine learning models.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing reactive monitoring tools are used to detect problems in real-time, then problem detection capability is provided, but the ability to perform root cause analysis is lost when containers are shut down unexpectedly
Solution Approach 1:
The system performs preliminary actions by capturing and storing execution data (transaction logs, stack traces, environment variables) before container shutdown occurs. Agents continuously monitor and persist application state to external storage during runtime, ensuring data is preserved even when the container is unexpectedly terminated. This allows post-mortem analysis to proceed without losing critical diagnostic information.
2Measurement precision
If detailed execution information is captured for all microservices, then diagnostic capability is improved, but system complexity and data volume increase
Solution Approach 1:
The monitoring system is segmented into independent agents deployed with each microservice, allowing distributed data collection without centralizing complexity. Each agent independently captures execution data for its associated microservice, and transaction logs are organized by unique transaction identifiers, enabling modular analysis of individual service contributions to overall system behavior.
Solution Approach 2:
An intermediary layer (the agent framework and transaction log storage system) is introduced between the microservices and the analysis tools. This intermediary standardizes data collection across diverse microservices, converting varied execution information into a unified transaction log format that simplifies subsequent diagnostic processing without requiring direct integration with each service.
3Difficulty of detecting and measuring
If transaction logs are retained for analysis, then root cause identification capability is improved, but storage requirements increase
Solution Approach 1:
Critical diagnostic information (stack traces, error states, relevant environment variables) is extracted and prioritized for persistent storage in transaction logs, while less critical data is managed with different retention policies. The system extracts only the essential elements needed for root cause analysis, reducing overall storage requirements while maintaining diagnostic effectiveness.
Data Source
AI summary
Systems and methods for replaying events involving a transaction are disclosed. A method for monitoring server-side application execution may include: (1) deploying an application having a plurality of microservices to a cloud environment, wherein each microservice is associated with an agent that collects execution information for the microservice; (2) executing a transaction with the application; (3) a first microservice of the plurality of microservices assigning a unique identifier to the transaction and executing a first portion of the transaction; (4) the agent for the first microservice collecting first portion execution information in a transaction log and associating the transaction log with the unique identifier; (5) a second microservice of the plurality of microservices executing a section portion of the transaction; (6) the agent for the second microservice collecting second portion execution information in the transaction log associated with the unique identifier; and (7) outputting the transaction log.