Dynamic Instrumentation Data Collection via Runtime Manifests
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional mechanisms for collecting instrumentation metrics in software products are inflexible and inefficient, often failing to provide sufficient information to diagnose performance issues or guide improvements, and they do not allow for trade-offs between data collection speed and user disruption.
Innovation Solution
A flexible software quality metric system that uses dynamic and adaptive techniques, where client computers receive manifests specifying which metrics to collect, from what sources, and how to calculate them, allowing for real-time adjustments without updating the software modules, thereby enabling faster diagnosis and improvement of software products.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If conventional instrumentation data collection mechanisms are used, then the software product can be tested and basic metrics can be gathered, but the system lacks flexibility to adapt data collection strategies in response to performance issues and cannot provide sufficient information for effective diagnosis
Solution Approach 1:
The patent implements dynamic configuration of instrumentation data collection through manifests that can be updated at runtime without requiring software updates. The system transitions from static, pre-configured metrics collection to a dynamic model where the server can instruct client computers to collect different sets of instrumentation data based on detected performance issues, thereby improving adaptability while ensuring sufficient diagnostic information is gathered
Solution Approach 2:
The system changes the parameters of data collection by using manifests that specify which instrumentation data to collect, from what sources, and how to calculate metrics. These manifest parameters can be dynamically adjusted by the server based on analysis of received metrics, allowing the system to adapt collection strategies and ensure sufficient diagnostic information without requiring software updates
2Loss of information
If more instrumentation data is collected from each computer to improve diagnosis, then more information is available for analysis, but the processing burden and disruption to users increases
Solution Approach 1:
The patent applies partial action by collecting instrumentation data selectively rather than comprehensively from all sources at all times. The server analyzes received metrics and determines whether additional specific instrumentation data is needed for diagnosis, instructing only those specific data points to be collected. This approach ensures sufficient diagnostic information while minimizing user disruption by avoiding unnecessary data collection
Solution Approach 2:
The system implements feedback loops where the server receives instrumentation metrics from client computers, analyzes them for performance issues, and based on that analysis, determines whether additional instrumentation data should be collected. This feedback mechanism ensures that data collection is driven by actual diagnostic needs rather than collecting excessive data routinely, balancing completeness with minimal user disruption
3Adaptability or versatility
If instrumentation metrics collection is updated to collect different metrics, then the system can identify new sources of improvement, but the software modules themselves must be updated which slows down the process
Solution Approach 1:
The patent extracts the data collection configuration from the software product code itself and places it in separate manifest files that can be independently updated and distributed. This separation allows the instrumentation data collection parameters to be modified without requiring updates to the software modules, enabling rapid adaptation to collect new metrics or modify collection strategies simply by distributing updated manifests to client computers
Solution Approach 2:
The manifest acts as an intermediary between the server and the instrumentation data collection process. Instead of modifying software modules to change what data is collected, the server communicates desired collection parameters through manifests, which then mediate the actual data collection process. This intermediary mechanism enables flexible updates to metrics collection without requiring software updates, significantly reducing the time needed to adapt data collection strategies
Data Source
AI summary
A flexible system for collecting and reporting instrumentation metrics relating to performance of a software product. Computing devices that execute the software product receive a manifest that specifies the manner in which instrumentation metrics are collected and reported, including what instrumentation metrics are collected. Based on the manifest, an instrumentation metrics client associated with a software product may retrieve instrumentation data from a software product or other sources. The metrics client may then generate one or more instrumentation metrics, based on the instrumentation data, in accordance with instructions in the manifest. The metrics client may then take one or more actions based on the instrumentation metrics and the manifest, such as reporting the information to an instrumentation metrics server for aggregation and analysis by the metrics server or performing escalation actions that can modify the metrics collected and reported.