Dynamic Registration of Software Components for Diagnosis of Root Causes of Failures

Abstract

Dynamic registration of software components for diagnosis of root causes of failures. Dynamic registration of software components for diagnosis of root causes of failures can include determining the start of execution of a thread associated with a process and creating a dynamic registry associated with the thread. One or more software components associated with the execution of the thread are determined, and an entry in the dynamic registry is created for each of the one or more software components. The entry includes an identifier of the software component and a diagnostic content index associated with the software component. The diagnostic content index indicates component-specific diagnostic information associated with the software component.

Description

[Technical Field]

[0001] The field of the invention is data processing, or more specifically, methods, apparatus and products for dynamic registration of software components for diagnosis of root causes of failures. [Background technology]

[0002] The development of the EDVAC computer system in 1948 is often cited as the beginning of the computer age. Since that time, computer systems have evolved into extremely complex devices. Most modern computers are more sophisticated than earlier systems such as the EDVAC. A computer system typically includes a combination of hardware and software components, including application programs, operating systems, processors, buses, memory, and input / output devices. Advances in semiconductor processing and computer architecture have enabled increasingly higher computer performance, and more sophisticated computer software has evolved to take advantage of the increased performance of the hardware. As a result, today's computer systems are far more powerful than they were just a few years ago.

[0003] As computer systems and associated computer programs become increasingly complex, diagnosing computer program failures and other faults becomes more challenging. To understand the challenges associated with fault isolation and diagnosis in large, complex application environments, some background and definitions related to terms such as program, process, thread, and dump are provided. A program is a set of instructions for performing a task. A process is a running program instance along with any necessary resources for the program instance to operate. An operating system (OS) handles the task of managing the resources necessary to convert a program into a running process. A program can have multiple instances, and each running instance of a program is a process. Typically, each process has an independent memory address space within which it executes independently. Typically, each process is isolated from other processes and cannot directly access data in other processes. A thread is a single unit of work or control flow executed within a process. A single-threaded process contains one thread; thus, process and thread are one and the same. Accordingly, a single task executes at a time. A multi-threaded process contains more than one thread, and the process executes multiple tasks simultaneously. A dump is a snapshot of memory associated with one or more processes, typically including program code, system-related control blocks, process-related control blocks, and other storage areas.

[0004] When software problems occur, software that collects first-failure data about events and conditions that may lead to a failure is often relied upon to collect the data necessary to diagnose the problem. The specific data needed to understand and resolve the problem can vary greatly depending on the specific failure scenario. For example, a computer system may run hundreds or even thousands of processes and threads simultaneously. A failure is often limited to a subset of processes and threads, while the rest of the computer system continues to run without impairment. In worst-case scenarios, nothing is obviously broken, but the system or production application may become slow or unresponsive. Collecting “all” data on a computer system at the time of a failure, such as using a complete memory dump, is impractical and may require a system shutdown. For clients running business-critical applications that require ultra-high availability, a complete system shutdown is often not a desirable option. Accordingly, it is important to be able to identify and limit the specific first-failure data that needs to be collected at the time of a failure without affecting system availability. System data dumps are often captured, but they do not always contain all the data needed to debug and diagnose the root case of a failure. In such cases, clients often have to recreate the circumstances surrounding the failure and gather additional information, which is time-consuming and results in repeated outages. In some cases, completing such a recreation can take months or even years. In other instances, clients may not be able to recreate the failure scenario, and the problem may go undiagnosed. Therefore, a novel solution is needed to collect the documentation necessary to diagnose the root cause of a failure. Summary of the Invention

[0005] According to one aspect of the present invention, a method for dynamic registration of software components for diagnosis of root causes of failures is provided. The method includes determining the start of execution of a thread associated with a process; creating a dynamic registry associated with the thread; and determining one or more software components associated with execution of the thread. The method also includes creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component.

[0006] According to another aspect of the present invention, an apparatus for dynamic registration of software components for diagnosis of root causes of failures is provided, the apparatus comprising: a computer processor; and a computer memory operatively coupled to the computer processor. The computer memory includes computer program instructions disposed therein that, when executed by the computer processor, cause the apparatus to execute steps of a procedure for determining a start of execution of a thread associated with a process; creating a dynamic registry associated with the thread; determining one or more software components associated with execution of the thread; and creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component, the diagnostic content indicator indicating component-specific diagnostic information associated with the software component.

[0007] According to another aspect of the present invention, there is provided a computer program product for dynamic registration of software components for diagnosis of root causes of failures, the computer program product being disposed on a computer-readable medium, the computer program product including computer program instructions that, when executed, cause a computer to perform the following procedures: determining a start of execution of a thread associated with a process; creating a dynamic registry associated with the thread; determining one or more software components associated with execution of the thread; and creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component, the diagnostic content indicator indicating component-specific diagnostic information associated with the software component.

[0008] In some examples, the method further includes determining that execution of the thread has completed; and deleting the dynamic registry associated with the thread. In some examples, the method further includes determining that a trigger event associated with the thread has occurred; collecting diagnostic data for at least one of the one or more software components based on the diagnostic content indicator associated with the software component; and storing dump information including the collected diagnostic data in a central repository.

[0009] In some examples, collecting diagnostic data for at least one of the one or more software components includes collecting diagnostic data for a subset of the one or more software components. In some examples, the subset is determined based on a prioritization scheme. In some examples, the trigger event includes a fault occurring during execution of the thread. In some examples, the diagnostic data further includes one or more of hardware diagnostic information or a console log. In some examples, the trigger event includes an anomaly occurring during execution of the thread. In some examples, the anomaly is determined based on analysis and prediction by artificial intelligence.

[0010] In some examples, the entry in the dynamic registry for each of the one or more software components further includes an active or inactive state of the software component. In some examples, the diagnostic information is collected only for the software components that include an active state. In some examples, the active state is set for a software component based on a function call of the software component by the thread. In some examples, the inactive state is set for a software component based on a return of a function call to the software component by the thread.

[0011] The above and other objects, features and advantages of the present invention will become apparent from the following more particular description of exemplary embodiments of the invention as illustrated in the accompanying drawings in which like reference numerals generally represent like parts of the exemplary embodiments of the invention. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram of an exemplary computing system configured for dynamic registration of software components for diagnosis of root causes of failures.

[0013] [Figure 2] FIG. 1 illustrates a flowchart illustrating an example method for dynamic registration to track software components over the lifecycle of threads for diagnosis of root causes of failures.

[0014] [Figure 3] FIG. 1 illustrates an exemplary procedure for diagnosing the root cause of a failure.

[0015] [Figure 4] FIG. 1 illustrates an example of a particular flow utilizing dynamic registration of software components for diagnosis of root causes of failures.

[0016] [Figure 5] FIG. 10 illustrates a flowchart illustrating another exemplary method for dynamic registration of software components for diagnosis of root causes of failures. DETAILED DESCRIPTION OF THE INVENTION

[0017] Exemplary methods, apparatus, and articles of manufacture for dynamic registration of software components for diagnosis of root causes of failures according to this invention will be described with reference to the accompanying drawings, beginning with Figure 1. Figure 1 illustrates a network diagram of a system configuration for dynamic registration of software components for diagnosis of root causes of failures according to an embodiment of the present disclosure. Figure 1 illustrates a block diagram of an automated computing machine comprising an exemplary computing system 100, including at least one computer processor 110 or "CPU" and random access memory (RAM) 120 connected to processor 110 and other components of computing system 100 via high-speed memory bus 113 and bus adapter 112.

[0018] An operating system 122 is stored in RAM 120. Operating systems useful for computers configured for dynamic registration of software components for root cause diagnosis of failures according to embodiments of the present disclosure include UNIX™, Linux™, Microsoft Windows™, AIX™, and others that will occur to those skilled in the art. In the example of FIG. 1 , operating system 122 is shown in RAM 120, although many components of such software are typically also stored in non-volatile memory, such as data storage 132, e.g., a disk drive. RAM 120 also stores a dynamic diagnostic data management component 124 and a dump collector component 126, which are described further below.

[0019] Computing system 100 of FIG. 1 includes a disk drive adapter 130 coupled to processor 110 and other components of computing system 100 via expansion bus 117 and bus adapter 112. Disk drive adapter 130 connects non-volatile data storage to computing system 100 in the form of data storage 132. Disk drive adapters useful in computers configured for inserting sequence numbers into editable tables according to embodiments of the present disclosure include integrated drive electronics ("IDE") adapters, small computer system interface ("SCSI") adapters, and others as will occur to those skilled in the art. Non-volatile computer memory may also be implemented as optical disk drives, electrically erasable programmable read-only memory (so-called "EEPROM" or "flash" memory), RAM drives, and the like, as will occur to those skilled in the art. Dynamic diagnostic data management component 124 is configured to create, store, and maintain a dynamic data registry 138 for each thread in RAM 120. Dynamic data registry 138 includes an entry for each component indicating what diagnostic data to collect for that thread. As described further herein, the one or more dynamic data registries are used by the dump collector component 126 for diagnosis of the root cause of a failure.

[0020] The exemplary computing system 100 of FIG. 1 includes one or more input / output (“I / O”) adapters 116. I / O adapters implement user-oriented input / output, for example, through software drivers and computer hardware for controlling output to display devices such as a computer display screen and user input from user input devices 118, such as a keyboard and mouse. The exemplary computing system 100 of FIG. 1 also includes a video adapter 134, which is an example of an I / O adapter specifically designed for graphics output to a display device 136, such as a display screen or computer monitor. Video adapter 134 is connected to processor 110 via a high-speed video bus 115, a bus adapter 112, and a front-side bus 111, which is also a high-speed bus.

[0021] The exemplary computing system 100 of FIG. 1 includes a communications adapter 114 for data communications with other computers and for data communications with a data communications network. Such data communications may be performed continuously via an RS-232 connection, via an external bus such as a Universal Serial Bus (“USB”), via a data communications network such as an IP data communications network, and in other manners that will occur to those skilled in the art. The communications adapter implements the hardware level of data communications whereby one computer sends data communications to another computer directly or via a data communications network. Examples of communications adapters useful in computers configured for inserting sequence numbers into editable tables according to embodiments of the present disclosure include modems for wired dial-up communications, Ethernet (IEEE 802.3) adapters for wired data communications, and 802.11 adapters for wireless data communications.

[0022] The communications adapter of Figure 1 is communicatively coupled to a wide area network (WAN) 140 that may also include other computing devices, such as computing devices 141 and 142, as shown in Figure 1. In particular embodiments, computing system 100 includes a server, and computing devices 141 and 142 are client devices of the server.

[0023] For purposes of explanation, the arrangement of servers and other devices constitutes the exemplary system shown in FIG. 1 , but is not so limited. Data processing systems useful in accordance with various embodiments of the present invention may include additional servers, routers, other devices, and peer-to-peer architectures not shown in FIG. 1 but which will occur to those skilled in the art. The network in such a data processing system may support many data communication protocols, including, for example, TCP (Transmission Control Protocol), IP (Internet Protocol), HTTP (Hypertext Transfer Protocol), WAP (Wireless Access Protocol), HDTP (Handheld Device Transport Protocol), and the like, as will occur to those skilled in the art. Various embodiments of the present invention may be implemented on a variety of hardware platforms in addition to those shown in FIG. 1 .

[0024] Existing solutions for diagnosing the root cause of failures require a substantial manual process, with limited automated collection of complete diagnostic data for debugging complex problems. This is often an error-prone, time-consuming process of collecting diagnostic data and analyzing it in relation to code flow. Expert consultation is often required. If no conclusion can be reached about the cause of the problem, additional problem-determination actions are required, including returning to the client and collecting additional diagnostic data and reproducing the problem. This process often must be repeated until the problem is resolved. Furthermore, collecting a standalone dump of all information requires a system reboot, a time-consuming process that is often not an option for highly available clients.

[0025] System dumps are typically collected by recovery routines, Serviceability Level Indication Processing (SLIP) traps, and manual operations via a console. However, these existing dump collection methods have challenges. Recovery dumps may not contain all necessary data because recovery routines have limited visibility into component interactions. Recovery routines often do not recognize all other components in the flow and the interactions between them. Furthermore, complex situations involving multiple components exist where recovery dumps miss important information. This results in situations where the problem cannot be resolved. While a recovery routine may be able to recognize the data that needs to be dumped for its own component, it cannot always recognize the data that needs to be dumped for other components in the fault flow that it is unaware of. SLIP dumps may not contain all necessary data because the user has limited knowledge. SLIP dumps are driven by the human specification of a (often complex) set of keywords that specify data content, and are often determined without sufficient knowledge of the problem flow and interactions. Complex situations involving multiple components exist where SLIP dumps miss important information. As a result, additional reproductions of the failure are necessary to establish an understanding of the root cause of the failure. In the case of persistent process-related conditions such as loops, high CPU usage, or hung conditions, console dumps may be collected manually by an operator. Like SLIP dumps, console dumps are operator-specified and often based on incomplete knowledge of the problem flow and interactions.

[0026] One or more embodiments provide dynamic registration of software components for diagnosing the root cause of a failure. In one embodiment, a smart diagnostic unified management protocol (SDUMP) is provided to enable collection of documentation needed for a problem flow involving one or more software components to diagnose the root cause of a failure. Various embodiments provide dynamic registration functionality that enables collection of all documentation needed for a problem flow involving one or more application, middleware, and operational system components to diagnose the root cause of a failure. In various embodiments, as a thread executes through a workflow, the components of that workflow (e.g., application, middleware, or operational system components) are dynamically registered. Each registry entry includes the component's identification and its associated diagnostic content indicator that describes the data that will be collected if a problem occurs. In one or more embodiments, the registry entry includes the software component's identifier, the diagnostic content indicator associated with the software component, and a state that reflects whether the component is active (registered) or inactive (unregistered) in the execution flow. In one or more embodiments, the diagnostic content indicator points to an array of component-specific fields that provide relevant diagnostic data.

[0027] According to various embodiments, the dynamic diagnostic data management component 124 maintains a dynamic data registry 138 to keep track of all software components in the flow of interest. Initially, when a thread is created, the software component responsible for creating the thread anchors a dynamic registry for the particular thread via the dynamic diagnostic data management component 124. The dynamic registry for the particular thread is used to keep track of all software components in the execution flow, using a separate entry for each component in the execution flow. In normal processing, when a software component is added to the execution flow, the respective component's entry in the thread's registry is marked as active. When the software component is no longer active in the execution flow, the entry associated with the software component is marked as inactive in the thread's registry. Upon completion of the thread, the registry for the respective thread is deleted.

[0028] In certain embodiments, the registration of a component is based on the execution of a system call or service (eg, a program call or recovery routine).

[0029] One or more embodiments provide a dynamic registry that enables a real-time view of the software components involved in the flow of a thread at any diagnostic time of interest. In various embodiments, the dynamic registry facilitates First Failure Data Capture (FFDC) related to the participating software components during an anomalous event, such as a thread failure or a persistent process state (e.g., a loop, hang, or other anomaly), assisting a debugger in problem determination without requiring a replay (i.e., recreation) of the state at the time the anomaly occurred.

[0030] According to various embodiments, the dynamic diagnostic data management component 124 provides functionality for each active thread of a process to activate, maintain, and eventually deactivate its own unique dynamic registry entry. Each software component encountered along the flow of a thread registers itself. In one or more embodiments, the dynamic registry entry for each component further includes a diagnostic content indicator (or diagnostic level) used to indicate which component-specific data is most helpful in problem determination during that particular portion of the flow. In one or more embodiments, the dynamic registry entry includes an indication of whether the software component is in an active or inactive state. In response to a triggering event (such as a failure or fault during thread execution or a request for a dump), the dump collector component 126 queries the dynamic registry for threads to collect information on all active component entries and their associated diagnostic content indicators in order to populate a data dump with corresponding data. In other embodiments, the triggering event includes an anomaly during thread execution. In certain embodiments, the process identified as contributing to the anomaly is determined based on artificial intelligence (or knowledge-based) analysis and / or prediction. In various embodiments, anomalies include not only specific hardware or software failures detected by server hardware or software, but also strange inconsistencies or discrepancies, peculiar or odd conditions, or situations that are likely to result in anomalous behavior of a computer system, such as delays, contentions, resource exhaustion, or complete failure.

[0031] In another embodiment, diagnostic information is collected only for software components that are in an active state. In another embodiment, the active state is set for a software component based on a function call of the software component by a thread. In another embodiment, the inactive state is set for a software component based on a return of a function call from the software component by a thread. In one embodiment, when a currently active component is deactivated on return from a function call or other means, it is marked as deactivated in the dynamic registry.

[0032] In one embodiment, the dynamic registry is used to enable the collection of diagnostic data in anomaly scenarios where the triggering event is not an explicit failure, but is identified as a result of higher level (e.g., artificial intelligence or machine learning based) anomaly prediction and / or analysis.

[0033] In one or more embodiments, software components activated by function calls or other means associated with a particular thread are automatically identified and tracked. In such an embodiment, a first software component registers in a thread-specific dynamic software registry when activated. Each other software component accessed or activated by the first software component registers in the thread-specific dynamic software registry the first time it is accessed or activated. A trigger event generates and captures a snapshot of all active software components in the dynamic software registry. The snapshot is used to capture and save all dump information associated with all active components associated with the event trigger. In certain embodiments, the snapshot of all active software components at the time of the trigger event is saved to a central repository. In other embodiments, additional diagnostic data beyond just dump information, such as additional hardware diagnostic information or console logs, is also collected upon the trigger event.

[0034] In certain embodiments, persistent process state may require a diagnostic view of all threads within a process. In such cases, the dump collector component 126 queries the dynamic registry for each thread, as described above, and then merges all corresponding required data into the dump.

[0035] In addition to process or thread failures, anomalies are scenarios in which continuing normal operational behavior can lead to delays, contention, or resource exhaustion. In these scenarios, the system appears to be operating but suffers from delays or other problems that can ultimately cause system failure. Typically, operations or system programming staff analyze the situation. FFDC may also be requested in these situations if a software component is believed to be faulty. Before taking corrective action, the operator may request a "console dump." Here, the dynamic data registry 138 can assist in ensuring the correct diagnostic data is automatically captured for the anomaly.

[0036] In one or more embodiments, the dynamic diagnostic data management component 124 starts at system initialization and remains active until system shutdown. The dynamic diagnostic data management component 124 is responsible for managing the contents of the dynamic registry structure. In particular embodiments, the dynamic diagnostic data management component 124 provides an application programming interface (API) for lifecycle management, including activation, deactivation, and dynamic modification of each player's component (or product) entries. According to various embodiments, a "player" refers to a subsystem / system component representative. In particular embodiments, each player is provided with an index for viewing and modifying its dynamic registry entries. During system initialization, the dynamic diagnostic data management component 124 allocates enough space for each existing player to have an entry in the dynamic registry structure of the dynamic data registry 138, thereby determining the total size of the dynamic registry structure to be added as each thread's dynamic data registry 138.

[0037] In particular embodiments, the dynamic diagnostic data management component 124 implements the following APIs with the following associated functions: NewPlayer - Dynamically adds a new player to the dynamic registry structure and allocates a larger dynamic registry structure for the new thread. ·Activate - enables dumping of player diagnostic data when a player is engaged, includes player diagnostic content indicators. Deactivate - Deactivates a player's entry when it falls out of the thread flow. ModifyIndicator - Updates the diagnostic content indicators of the player. · QueryThreadDiagnosticData - Called by the dump collector component 126 to query what data should be dumped from each participating player based on the diagnostic content indicators of the target thread.

[0038] In one or more embodiments, the dynamic diagnostic data management component 124 implements the following rules to govern the behavior of dynamic registry interactions:

[0039] Lifecycle rules: Used during the lifecycle of a thread. 1. When a thread begins execution, a dynamic registry structure is created and anchored to the thread. 2. When a player (e.g., a component) registers (e.g., invokes Activate), the dynamic registry structure entry is marked as active. 3. When a player (e.g., a component) unregisters (e.g., invokes Deactivate), the dynamic registry structure entry is marked inactive, which is managed in an efficient way for performance reasons. 4. When the thread terminates, the dynamic registry structure is deleted.

[0040] Registration Rules: Used when registering players. 1. A called player registers himself as active when he tries to: a. Perform work on another thread on behalf of the current thread. b. Begin executing code in a separate memory space (for example, after a PC routine in z / OS). c. Requesting an internal serialized resource (e.g., a lock, a latch, or an ENQ in z / OS). d. Set a failure return code to return to the caller and mark itself as persistent (e.g., for the life of the thread) in case of a cascade of bad return codes that eventually leads to a condition that requires a dump, such as a hang, loop, Sick But Not Dead (SBND), or abend code. e. Establish recovery routines (e.g., ESTAE or FRR in z / OS or CDT in AIX). 2. When creating a subsystem, the creator of the subsystem (e.g., z / OS UNIX, Db2, IMS, CICS) registers itself.

[0041] Unregister Rules: Used when a player unregisters to make themselves inactive. 1. When deleting a subsystem: a. When you disconnect from the main subsystem, the subsystem will recognize the completion / termination of this connection and deregister itself.

[0042] Registry modification rules: Used when modifying the registry. 1. Update the diagnostic content indicator when the player attempts to add additional diagnostic data or delete existing diagnostic data contained in the dump. Add data if relevant to the workflow (e.g., when dealing with different address spaces and associated data spaces on z / OS). b. Delete data when it is no longer relevant to the workflow.

[0043] In certain embodiments, players are responsible for defining their list of diagnostic content indicators and associated diagnostic data to be collected.

[0044] Exemplary embodiment of the Dynamic Registry Structure (DynRegStructure): [Table 1]

[0045] 2 shows a flowchart illustrating an example method 200 for dynamic registration to track software components over the lifecycle of a thread for diagnosis of root causes of failures, according to an embodiment of the present disclosure. Method 200 includes starting a thread (202), where the component responsible for creating the thread anchors (204) a dynamic data registry 138 for the thread in RAM 120. In a particular embodiment, an entry in dynamic data registry 138 includes an identifier for the software component, a diagnostic content indicator associated with the software component, and a state reflecting whether the component is active (registered) or inactive (unregistered) in the execution flow. The thread then continues normal processing (206).

[0046] During normal processing of the thread (206), new components may be added or removed from the execution flow (208). During execution of a component, the component determines whether to activate or deactivate its component entry in the thread's dynamic registry (210). If the thread has not completed, the method continues with normal processing of the thread (206). If the thread has completed (212), the component responsible for thread termination deletes (214) the dynamic data registry 138 associated with the thread. The thread then terminates (216).

[0047] FIG. 3 illustrates an exemplary procedure 300 for diagnosing the root cause of a failure, according to an embodiment of the present disclosure. Process 301 includes multiple active threads (Thread 1 through Thread n) (302). Each active thread 302 creates, anchors, maintains, and eventually deletes its own dynamic registry 304. In particular embodiments, procedure 300 is facilitated by a dynamic diagnostic data management component 124, which provides an interface between a particular thread 302 and the thread's dynamic registry 304. Each software component encountered along the flow of a particular thread 302 activates or deactivates its entry and adjusts the associated diagnostic content indicator in the particular dynamic registry 304 associated with the particular thread 302. The diagnostic content indicator points to an array of component-specific data that is most useful for problem determination during a particular portion of the flow. Accordingly, each dynamic registry 304 may include registry entries corresponding to multiple software components (e.g., Component 1 through Component n) encountered within the active thread. While registered in the dynamic registry 304, a software component may change its diagnostic content indicator to reflect a changed diagnostic level associated with the software component, or may deactivate an entry if the component is no longer associated with a flow.

[0048] At time 306, when a dump of one of the threads 302 is requested, for example, by a user or automatically, the dump collector component 126 queries the thread's dynamic registry 304 to read and / or archive the registry (308) to gather information about registered component entries and associated diagnostic content indicators in the thread's dynamic registry 304 and adds the corresponding data to the dump. The dump collector component adds (310) diagnostic data for the listed components from the dynamic registry 304 to the dump data. In certain embodiments, the dump collector component 126 archives a copy of the dynamic registry 304 for later review in a repository. Persistent process state may require a diagnostic view of all threads within a process. In such cases, the dump collector component 126 queries each thread's dynamic registry 304 and merges the corresponding requested data into the dump, as described above.

[0049] 4 illustrates an example of a specific flow 400 utilizing dynamic registration of software components for diagnosing root causes of failures, according to an embodiment of the present disclosure. A first exemplary scenario utilizes the dynamic registry described with respect to various embodiments and an execution thread 402 attempting to perform an operation on an encrypted file system. While the cryptographic software component is waiting for a response from the cryptographic hardware, an asynchronous timeout fault occurs in the thread, triggering the timeout fault to request a dump (436). The dump collector component 126 queried the dynamic registry 410 of the failing thread, collected data indicated by the diagnostic level (or diagnostic content indicator) associated with each registered component in the dynamic registry 410, and added the data to the dump.

[0050] Examination of the thread's dynamic registry 410 at the moment of the timeout shows that because UNIX component 404 made a request call to read a file, UNIX component 404 registered (406) itself in a first entry 408 of dynamic registry 410 with a diagnostic level (or diagnostic content indicator) of 1, indicating that all storage associated with UNIX-specific data should be dumped. UNIX component 404 then called file system component 412, which registered (414) itself in its entry 416 in dynamic registry 410 with a diagnostic content indicator of 1, indicating that all file system-specific data should be dumped. File system component 412 initiated the I / O operation as part of the read request. I / O component 418 registered (420) itself in entry 422 of dynamic registry 410 with a diagnostic content indicator of 1. I / O component 418 noticed that the file system of the target data was encrypted and called crypto component 424 for decryption. The cryptographic component 424 registered 426 itself in entry 428 of the dynamic registry 410 with a diagnostic content indicator of 1, indicating that it would dump storage associated with the requested operation. When the cryptographic component 424 sent a decryption request to the cryptographic hardware component 430 to access the encryption key, the cryptographic component 424 modified the diagnostic content indicator to 2, ensuring that data associated with the hardware request was also dumped. Additionally, the cryptographic component 424 registered 432 the cryptographic hardware component 430 in a fifth entry 434 of the dynamic registry 410 with a diagnostic content indicator of 1, indicating that it would collect cryptographic hardware logs. The resulting dump taken by the dump collector component 126 included the requested FFDC as well as any data specifically requested by the recovery routine.

[0051] In a second exemplary scenario that does not utilize the dynamic registry 410, as described with respect to various embodiments, thread 402 again attempts to perform a read operation on the encrypted file, and an asynchronous timeout again occurs while the cryptographic component 424 waits for a response from the cryptographic hardware component 430. Because the dump collector component 126 does not have a dynamic registry to query, it relies on the cryptographic component's recovery routines to identify the data to include in the dump. The cryptographic component 424 instructs the dump collector component 126 to collect the cryptographic component's relevant data in a dump, and the dump collector component 126 can also capture both thread-specific data and its caller's data (e.g., I / O component data). However, the dump collector component 126 does not know to collect any UNIX or file system data, nor can it collect cryptographic hardware logs. Because the cryptographic hardware component is causing the delay, a user or operator must manually request the hardware log from the hardware colleague and hope that the log is still available. Understanding the root cause of the failure may require a re-create procedure that requests a dump containing additional data, along with a more rapid manual request for the hardware log.

[0052] In a third exemplary scenario, some components participate in the dynamic registry 410 while others do not. In this scenario, data is collected based on a combination of the diagnostic levels of the participating components and the data requested by the recovery routines.

[0053] For further explanation, FIG. 5 depicts a flowchart illustrating another exemplary method 500 for dynamic registration of software components for diagnosis of root causes of failures, according to an embodiment of the present disclosure. Method 500 comprises determining (502) the start of execution of a thread associated with a process and creating (504) a dynamic registry associated with the thread. Method 500 further comprises determining (506) one or more software components associated with the execution of the thread and creating (508) an entry in the dynamic registry for each of the one or more software components. The entry includes an identifier of the software component and a diagnostic content indicator associated with the software component. The diagnostic content indicator describes component-specific diagnostic information associated with the software component.

[0054] In another embodiment, the method 500 further comprises determining that execution of a thread has completed; and deleting the dynamic registry associated with the thread. In another embodiment, the method further comprises determining that a trigger event associated with the thread has occurred; collecting diagnostic data for at least one of the one or more software components based on the diagnostic content indicator associated with the software component; and storing dump information including the collected diagnostic data in a central repository.

[0055] In another embodiment, collecting diagnostic data for at least one of the one or more software components includes collecting diagnostic data for a subset of the one or more software components. In another embodiment, the subset is determined based on a prioritization scheme. For example, in one embodiment, the prioritization scheme prioritizes diagnostic data that is deemed to be more important than other diagnostic data.

[0056] In another embodiment, the trigger event includes a fault occurring during execution of the thread. In another embodiment, the diagnostic data further includes one or more of hardware diagnostic information or a console log. In another embodiment, the trigger event includes an anomaly occurring during execution of the thread. In another embodiment, the anomaly is determined based on artificial intelligence analysis and prediction. In yet another embodiment, the anomaly is determined based on machine learning.

[0057] In another embodiment, the entry in the dynamic registry for each of one or more software components further includes an active or inactive state of the software component. In another embodiment, diagnostic information is collected only for the software components that include an active state. In another embodiment, the active state is set for a software component based on a function call of the software component by a thread. In another embodiment, an inactive state is set for a software component based on a return of a function call to the software component by a thread.

[0058] In view of the above description, the reader will recognize that advantages of dynamic registration of software components for diagnosis of root causes of failures according to embodiments of the present invention include: Improved First Failure Data Collection (FFDC) helps prevent customer outages by eliminating the need for system support to return to the client or customer to perform a rebuild procedure to gather more information, thereby reducing the number of rebuilds required and improving serviceability. Improve FFDC by providing a complete profile of software components and their interactions to determine what diagnostic data is needed. Automates the collection of diagnostic data required for multi-component problems, eliminating the need for experts to analyze and determine what data needs to be collected to resolve the problem. Reduced debugging time during testing and development cycles. Substantially improve the completeness of diagnostic data collected during failure recovery. Eliminates the need for customers to decide which subsystems / components need to be dumped for a debug operation, thereby increasing the speed and accuracy of the debug operation.

[0059] Exemplary embodiments of the present invention are described primarily in the context of a fully functional computer system for dynamic registration of software components for diagnosing root causes of failures. However, a reader of ordinary skill in the art will recognize that the present invention may also be embodied in a computer program product disposed on a computer-readable storage medium for use with any suitable data processing system. Such a computer-readable storage medium may be any storage medium for machine-readable information, including magnetic, optical, or other suitable media. Examples of such media include magnetic disks in hard drives or diskettes, compact discs for optical drives, magnetic tape, and others that will occur to those skilled in the art. Those skilled in the art will readily recognize that any computer system with appropriate programming means is capable of executing the steps of the method of the present invention embodied in a computer program product. Furthermore, those skilled in the art will recognize that while some of the exemplary embodiments described herein are directed to software installed and executed on computer hardware, alternative embodiments implemented as firmware or as hardware are nevertheless within the scope of the present invention.

[0060] The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present invention.

[0061] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals transmitted through wires.

[0062] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0063] The computer-readable program instructions for carrying out the operations of the present invention may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or conventional procedural programming languages, such as object-oriented programming languages ​​like Smalltalk, C++, and the "C" programming language, or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry.

[0064] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0065] These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function / acts specified in the block or blocks of the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner; thus, a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the function / acts specified in the block or blocks of the flowcharts and / or block diagrams.

[0066] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in the flowchart and / or block diagram block or blocks.

[0067] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, are implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0068] From the foregoing description, it will be understood that modifications and changes may be made in various embodiments of the present invention without departing from the true spirit thereof. The description herein is for purposes of illustration only and is not to be construed in a limiting sense. The scope of the present invention is limited only by the language of the following claims.

Claims

1. 1. A method for dynamic registration of software components for diagnosis of root causes of failures, the method comprising: determining the start of execution of a thread associated with the process; creating a dynamic registry associated with said thread; determining one or more software components associated with the execution of the thread; creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component, the diagnostic content indicator indicating component-specific diagnostic information associated with the software component; A method for providing the above.

2. determining that execution of said thread has completed; deleting the dynamic registry associated with the thread. The method of claim 1 further comprising:

3. determining that a trigger event associated with the thread has occurred; collecting diagnostic data for at least one of the one or more software components based on the diagnostic content indicators associated with the software component; storing dump information including the collected diagnostic data in a central repository. The method of claim 1 or 2, further comprising:

4. The method of claim 3 , wherein collecting diagnostic data for at least one of the one or more software components comprises collecting diagnostic data for a subset of the one or more software components.

5. The method of claim 4 , wherein the subset is determined based on a prioritization scheme.

6. The method of claim 3 , wherein the trigger event comprises a failure during execution of the thread.

7. The method of claim 3 , wherein the diagnostic data further comprises one or more of hardware diagnostic information or a console log.

8. The method of claim 3 , wherein the trigger event comprises an anomaly during execution of the thread.

9. The method of claim 8 , wherein the software component associated with the anomaly is determined based on artificial intelligence analysis and prediction.

10. 10. The method of claim 1, wherein the entry in the dynamic registry for each of the one or more software components further includes an active or inactive state of the software component.

11. The method of claim 10 , wherein the diagnostic information is collected only for the software components that include an active state.

12. The method of claim 10 or 11, wherein the active state is set for a software component based on a function call of the software component by the thread.

13. The method of claim 10 , wherein an inactive state is set for a software component based on a return of a function call to the software component by the thread.

14. 1. An apparatus for dynamic registration of software components for diagnosis of root causes of failures, the apparatus comprising: a computer processor; and a computer memory operatively coupled to the computer processor, the computer memory, when executed by the computer processor, causing the apparatus to: a procedure for determining the start of execution of a thread associated with a process; creating a dynamic registry associated with said thread; determining one or more software components associated with the execution of the thread; creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component, the diagnostic content indicator indicating component-specific diagnostic information associated with the software component; An apparatus having computer program instructions disposed therein that cause the apparatus to perform a procedure including:

15. The computer instructions further cause the device to: determining that execution of said thread has completed; deleting the dynamic registry associated with the thread; The apparatus according to claim 14, wherein the apparatus executes the steps of

16. The computer instructions further cause the device to: determining that a trigger event associated with the thread has occurred; collecting diagnostic data for at least one of the one or more software components based on the diagnostic content indicators associated with the software component; storing dump information including the collected diagnostic data in a central repository; 16. The apparatus according to claim 14 or 15, which causes the following procedure to be performed.

17. 17. The apparatus of claim 16, wherein collecting diagnostic data for at least one of the one or more software components comprises collecting diagnostic data for a subset of the one or more software components.

18. 1. A computer program product for dynamic registration of software components for diagnosis of root causes of failures, the computer program product being disposed on a computer readable medium, the computer program product, when executed, causing a computer to: a procedure for determining the start of execution of a thread associated with a process; creating a dynamic registry associated with said thread; determining one or more software components associated with the execution of the thread; creating an entry in the dynamic registry for each of the one or more software components, the entry including an identifier of the software component and a diagnostic content indicator associated with the software component, the diagnostic content indicator indicating component-specific diagnostic information associated with the software component; a computer program product comprising computer program instructions for causing the execution of the steps of

19. 20. The computer program product of claim 18, wherein the computer-readable medium comprises a signal medium.

20. 20. The computer program product of claim 18, wherein the computer-readable medium comprises a storage medium.

Images