Post Error Analysis System for Software Applications
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional software error prediction and security breach alerting systems rely on gathering extensive information across entire systems, overwhelming quality assurance engineers with voluminous log files and requiring real-time notifications, which can lead to missed functional issues and inefficient error analysis.
Innovation Solution
Implementing a system for post-error analysis in cloud service environments on a per-user basis, where errors are detected, logged, and categorized by cloud service environment, providing a focused report to quality assurance engineers without modifying application logic, thus streamlining error identification and resolution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional systems gather extensive information across entire systems for error detection, then error detection coverage is improved, but information overload and analysis complexity increase
Solution Approach 1:
The patent segments error analysis by creating separate error queues for different threads and processing them independently. Each thread's errors are tracked in its own queue, allowing parallel processing and reducing the complexity of managing all errors simultaneously. The error analysis is divided into local thread-level analysis and global aggregation phases.
Solution Approach 2:
The patent extracts only the essential error information needed for analysis, rather than processing all system information. It identifies and extracts specific error patterns, stack traces, and contextual information relevant to thread synchronization issues, filtering out unnecessary data to reduce analysis complexity while maintaining detection effectiveness.
2Loss of time
If real-time notification systems are implemented for error alerting, then response time is improved, but false positives and missed issues increase
Solution Approach 1:
The patent performs preliminary error classification and pattern matching before generating notifications. Errors are pre-processed to identify their type, severity, and potential causes, allowing the system to filter out noise and focus on genuine issues. This preliminary analysis reduces false positives while maintaining timely notification of actual problems.
Solution Approach 2:
The system implements feedback mechanisms where notification accuracy is continuously improved based on historical data and user responses. The error detection system learns from past false positives and adjusts its sensitivity, refining its notification criteria over time to reduce false alarms while maintaining rapid response to genuine errors.
3Difficulty of detecting and measuring
If application logic is modified to provide error information, then error detection capability is improved, but system invasiveness and maintenance complexity increase
Solution Approach 1:
The patent introduces an intermediary error analysis layer that sits between the application logic and the error detection system. This intermediary component captures error information through standardized interfaces without requiring deep modifications to application code. It acts as a mediator that translates various error sources into a unified format for analysis, reducing invasiveness while maintaining detection capability.
Solution Approach 2:
Instead of modifying original application logic, the system creates copies of error-relevant code paths and data structures. It replicates the necessary error information in a separate analysis-friendly format, allowing error detection without altering the original application. This copying approach maintains detection capability while minimizing system invasiveness.
4Loss of information
If voluminous log files are provided to quality assurance engineers, then comprehensive error information is available, but engineer workload and analysis time increase
Solution Approach 1:
The patent merges error information from multiple threads and sources into consolidated error queues and unified reports. Instead of presenting separate log files for each thread, it combines related errors, identifies patterns across threads, and presents integrated analysis results. This merging reduces the volume of information engineers must process while maintaining comprehensive error coverage.
Solution Approach 2:
The system transforms raw error data into different parameter representations that are more suitable for human analysis. It converts voluminous detailed logs into summarized error statistics, frequency distributions, and priority-ranked issue lists. This parameter transformation maintains information completeness while presenting it in a more engineer-friendly format that reduces analysis workload.
Data Source
AI summary
User-to-software-application-instance-pairings are created. Each of the pairings is a unique relationship between one of the users and one of the instances of the software applications. Identifiers for the user-to-software-application-instance-pairings are received. There is a separate identifier for each of the user-to-software-application-instance-pairings. One of the log creation facilities is associated with each of the user-to-software-application-instance-pairings. Log files are created at corresponding ones of the log creation facilities in response to detecting errors during execution of the instances of the software applications. The log files are categorized based on error categories. A request for a post error analysis report is received. The request specifies one of the error categories. A subset of the log files is determined based on the specified error category specified in the request. The subset of the log files is displayed. One of the identifiers is displayed for each error described in the post error analysis report.