Activity Tracing Diagnostic Systems Across Sandboxed Processes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current diagnostic logging in computing environments is inefficient, consuming substantial computing resources and generating large amounts of irrelevant data, making it difficult for technicians to identify the cause of failures due to the lack of targeted logging across process boundaries.
Innovation Solution
Implementing activity-specific log buffers that isolate diagnostic information for each processing activity, allowing for tracing across sandboxed processes, and using vouchers to enable inter-process communication for logging and reporting, ensuring that only relevant data is collected and stored.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If diagnostic information is logged for all threads and processes, then complete failure analysis is enabled, but computational resources are consumed and irrelevant data is generated
Solution Approach 1:
The patent segments diagnostic logging by dividing it into two categories: mandatory logging for failed threads (which triggers full system-wide logging including other processes) and optional logging for successful threads. This segmentation allows the system to consume computational resources only when necessary for failure analysis, rather than continuously logging all thread activities.
Solution Approach 2:
The patent implements partial action by selectively logging diagnostic information based on thread failure status. Only threads that fail trigger comprehensive logging across all processes, while successful threads generate minimal or no diagnostic output. This partial approach reduces overall computational overhead while maintaining the ability to perform complete failure analysis when needed.
2Reliability
If all process logs are collected during failure analysis, then root cause determination is enabled, but time is consumed to review irrelevant logs
Solution Approach 1:
The patent extracts and isolates the specific diagnostic information related to the failed thread and its interacting processes from the broader system logs. By triggering selective logging only for processes involved in the failed thread's execution context, the system extracts relevant failure data while excluding irrelevant logs from other processes, thereby reducing the time technicians spend reviewing unnecessary information.
Solution Approach 2:
The patent introduces an intermediary mechanism (the diagnostic logging system with failure detection) that automatically identifies and isolates relevant logs based on thread failure events. This intermediary filters and prioritizes log data, presenting only the critical information needed for root cause analysis to technicians, thus reducing time consumption.
3Reliability
If diagnostic logging is implemented across process boundaries, then comprehensive activity tracing is enabled, but device complexity increases
Solution Approach 1:
The patent segments the logging system into process-specific log files with a unified failure detection mechanism. Each process maintains its own log, but the system uses a common failure detection and logging trigger that operates across process boundaries. This segmentation approach enables comprehensive activity tracing while keeping individual process log structures simple and manageable.
Data Source
AI summary
Systems and methods are disclosed for logging encoded diagnostic information from a sequence of processing operations, the processing operations generated by an activity in a computing environment. Diagnostic information is tracked by activity, across process boundaries where the processes can be in computationally isolated, or “sandboxed”. Within each process, diagnostic information for an activity is stored in an activity-specific buffer registered with a kernel in the computing environment. For each activity in the computing system, the kernel keeps a list of all processes that have performed, or are performing, a processing task of the activity. The kernel also keeps a reference to the activity-specific log buffers for the activity for each process associated with the activity. If a processing operation for an activity fails, all activity-specific logs from all processes that are associated with the activity can be collected. A report can be generated from the collected logs for the activity.