Dynamic Transaction Log Level Adjustment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current transaction processing systems face challenges in efficiently identifying the root cause of transaction failures due to the high volume of detailed DEBUG-level logs, which occupy significant storage space and contain noise, and the complexity of correlating concurrent transactions with dependencies.
Innovation Solution
A logging mechanism that buffers detailed log information during transaction processing, dynamically adjusts log levels based on transaction results and dependencies, and stores logs at appropriate levels, using a dependency list or tree to identify related transactions and filter logs accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If DEBUG level logging is used to investigate transaction failures, then detailed information is obtained, but storage space is excessively consumed and noise increases
Solution Approach 1:
The system dynamically adjusts log levels based on transaction status. Successful transactions are logged at lower levels (INFO or above) while failed transactions trigger DEBUG level logging. This dynamic adjustment resolves the contradiction by providing detailed debugging information only when necessary, thereby maintaining debugging precision while significantly reducing storage space consumption.
Solution Approach 2:
The patent changes the log level parameter conditionally based on transaction outcomes. Instead of using a fixed DEBUG level for all transactions, the system modifies the logging parameter (log level) according to whether transactions succeed or fail. This parameter change enables precise debugging of failures while minimizing storage usage for successful transactions.
2Loss of information
If DEBUG level logs are stored for all transactions, then complete transaction data is available, but time to identify relevant logs increases
Solution Approach 1:
The system extracts and isolates logs from failed transactions at DEBUG level, separating them from successful transactions. By taking out only the relevant failure logs and applying DEBUG level detail specifically to these cases, the system maintains information completeness for debugging while dramatically reducing the time administrators spend searching through irrelevant successful transaction logs.
Solution Approach 2:
The logging system is segmented into different log levels applied to different transaction types. Successful transactions receive minimal logging (INFO level or higher) while failed transactions receive detailed logging (DEBUG level). This segmentation reduces debugging time by organizing logs into distinct categories based on transaction outcomes.
3Quantity of substance
If log storage space is limited, then old logs must be deleted to reclaim space, but important debugging information may be lost
Solution Approach 1:
The system selectively discards detailed DEBUG level logs for successful transactions while retaining them for failed transactions. This discarding and recovering strategy allows the system to maintain adequate storage capacity by eliminating redundant successful transaction logs, while preserving critical debugging information in failed transaction logs where it is most needed.
4Loss of information
If detailed logs are recorded for all transactions, then comprehensive data is available, but system resources are excessively consumed
Solution Approach 1:
The system dynamically adjusts logging intensity based on transaction outcomes. By activating detailed DEBUG level logging only for failed transactions and using minimal logging for successful ones, the system reduces processing power consumption while maintaining data completeness for debugging purposes. This dynamic approach prevents the excessive resource consumption that would result from uniform DEBUG level logging of all transactions.
Data Source
AI summary
A method dynamically adjusts a log level of a transaction. The method includes: buffering the most detailed logs of a transaction having highest log level into a memory; checking if all dependency-defined transactions within a dependency list/tree for the transaction are completed; and, in response to the completion of all dependency-defined transactions within the dependency list/tree for the transaction, obtaining a log filter level for the transaction in association with the transaction results (success/failure) of dependency-defined transactions, wherein the log filter level is a new log level for the transaction.