Fault analysis methods, equipment, media and program products

Abstract

This application discloses a fault analysis method, device, medium, and program product, relating to the field of computer technology. It includes capturing user-mode data through a user-mode probe and kernel-mode data through a kernel-mode probe when a target application triggers a system call. This dual-probe collaborative approach allows for direct and clear observation and tracing of the specific call order and hierarchical relationships between functions in the operating system kernel. Simultaneously, the user-mode and kernel-mode data are correlated using tracing identification information to construct a function call chain. This function call chain is then input into a preset analysis engine for analysis to obtain fault analysis results. This achieves full-link tracing of the system, solving the current difficulties in fault and anomaly analysis at the operating system kernel level and improving the efficiency and accuracy of fault analysis.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to fault analysis methods, devices, media, and program products. Background Technology

[0002] In the development and maintenance of computer operating systems (such as Linux and Windows), analyzing and locating faults and anomalies at the kernel level is crucial for ensuring stable system operation, improving system performance, and enhancing system security.

[0003] However, after a user-mode application triggers a system call to enter kernel mode, existing tools for monitoring and recording the interaction between the process and the operating system kernel can only capture the call entry and exit points. They cannot directly and clearly observe and trace the specific call order and hierarchical relationships between various functions in the operating system kernel. When an exception occurs during the execution of a system call in the operating system kernel, it is difficult to trace the specific location of the fault, causing great difficulties for fault and exception analysis at the operating system kernel level. Summary of the Invention

[0004] This application provides fault analysis methods, devices, media, and program products to at least solve the problem in related technologies that when an exception occurs during the execution of a system call in the operating system kernel, it is difficult to trace the specific fault location, which causes great difficulties for fault and exception analysis at the operating system kernel level.

[0005] This application provides a fault analysis method, including:

[0006] In response to system calls triggered by the target application, user-space data is captured based on user-space probes;

[0007] Kernel-mode data is captured based on kernel-mode probes and user-mode data;

[0008] Based on user-mode data and kernel-mode data, trace identification information is generated, and based on the trace identification information, the association between user-mode data and kernel-mode data is established to construct a function call chain;

[0009] The function call chain is input into the preset analysis engine, and the function call chain is analyzed based on the preset analysis engine to obtain the fault analysis results.

[0010] This application also provides a fault analysis apparatus, including:

[0011] The first information acquisition module is used to capture user-mode data based on user-mode probes in response to system calls triggered by the target application.

[0012] The second information acquisition module is used to capture kernel-mode data based on kernel-mode probes and user-mode data;

[0013] The function call chain construction module is used to generate tracing identifier information based on user-mode data and kernel-mode data, and to establish the association between user-mode data and kernel-mode data based on the tracing identifier information to construct the function call chain;

[0014] The fault analysis module is used to input the function call chain into the preset analysis engine, analyze the function call chain based on the preset analysis engine, and obtain the fault analysis results.

[0015] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described fault analysis methods when executing the computer program.

[0016] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described fault analysis methods.

[0017] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described fault analysis methods.

[0018] This application, by setting up user-mode probes and kernel-mode probes, not only can user-mode data such as system call entry and exit information be captured through the user-mode probe, but kernel-mode data related to system calls in the operating system kernel can also be captured through the kernel-mode probe. In other words, through the collaborative use of dual probes, the specific call order and hierarchical relationships between various functions in the operating system kernel can be directly and clearly observed and traced. Simultaneously, the user-mode and kernel-mode data are correlated through tracking identification information to construct a function call chain. This function call chain is then input into a preset analysis engine for analysis to obtain fault analysis results. This achieves full-link tracing of the system, solving the current problem of difficulty in fault and anomaly analysis at the operating system kernel level, and improving the efficiency and accuracy of fault analysis. Attached Figure Description

[0019] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A flowchart of a fault analysis method provided in an embodiment of this application;

[0021] Figure 2 A flowchart illustrating another fault analysis method provided in this application embodiment;

[0022] Figure 3 This is a schematic diagram of the structure of a fault analysis device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0024] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0025] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] Figure 1 This is a flowchart illustrating a fault analysis method provided in an embodiment of this application. This method can be executed by an electronic device, which can be exemplarily understood as a device such as a mobile phone, tablet computer, laptop computer, desktop computer, or smart TV. Figure 1 As shown, this fault analysis method can be applied to computer operating systems (such as Linux and Windows) to achieve collaborative monitoring and analysis of user mode and kernel mode (such as fault analysis), real-time monitoring and analysis of key data structures in kernel mode, and performance analysis and optimization of network protocol stacks and file systems. It can also be applied to technologies such as cloud computing, big data, and artificial intelligence for fault diagnosis and performance tuning. This fault analysis method may include the following steps:

[0027] S110, In response to a system call triggered by the target application, capture user-mode data based on the user-mode probe.

[0028] In this embodiment of the application, the target application can be any application in the operating system. For example, the target application can be a database service, etc.

[0029] System calls are the interface between user programs and the operating system kernel, allowing programs to request services from the kernel such as file operations, process management, and network communication.

[0030] The user-mode probe is a lightweight probe module deployed in user-mode space. It captures user-mode data by hooking into and exiting system call functions. When capturing user-mode data, the user-mode probe supports at least 64 levels of function call hierarchy, ensuring complete capture of call chain information in complex application scenarios. This avoids the loss of critical function information due to call stack truncation, which could affect subsequent fault location and performance bottleneck analysis. Here, "hierarchy" refers to the hierarchical relationship of function calls.

[0031] In this embodiment, user-mode data may include relevant data in the user-mode space during the system call process, such as call stack information, system call parameters and return values, and basic context information. It may also include metadata such as timestamps and resource usage data corresponding to the system call.

[0032] The call stack refers to the stack structure in memory used to manage function call relationships during program runtime. Its core function is to record complete context information of function calls.

[0033] Call stack information can include the address of the called function (such as the memory address of a user-mode function), the function call hierarchy (i.e., the complete call chain from the user-mode function to the system call function), etc.

[0034] System call parameters can include user-space input parameter values ​​passed to the system call, such as those for file operations and network requests. Specific parameters related to file operations can include the file path, file opening mode (e.g., read-only, read-write), and permission mask; specific parameters related to network requests can include the port number and the length of data to be transmitted.

[0035] The return value can include file descriptors, error codes, and other output results of the system call execution.

[0036] Basic context information may include call timestamps, process information, and thread information. The call timestamp can be used to associate it with the time sequence of kernel-mode function execution; process information may include process identification information to locate the specific user-mode process executing; and thread information may include thread identification information.

[0037] Specifically, in response to a system call triggered by a target application through a system call interface, the electronic device replaces the second function name and second memory offset address in the system call table based on the first function name and first memory offset address corresponding to the user-mode probe. This replaces the function mapping relationship and call entry probe in the system call table to hijack the system call entry and exit points. It also triggers the stack unwinding function corresponding to the stack unwinding library to start, tracing the complete call chain from the current system call function to the upper-level application function, obtaining information such as the call function address and hierarchical relationship, and thus capturing user-mode data.

[0038] For example, taking Linux as an operating system, a user-space probe uses a preset mechanism (such as the LD_PRELOAD mechanism) to intercept the system call entry point of the system call interface. By replacing the function pointers related to system calls in the system call interface, it intercepts the target application's calls to system call functions. When the target application initiates a system call, it first passes through the interception logic of the user-space probe, thereby capturing user-space data. This ensures that system call monitoring can be completed in user space, avoiding the security and stability risks caused by directly manipulating the kernel system call table, while also achieving the capture of call stack information.

[0039] S120 captures kernel-mode data based on kernel-mode probes and user-mode data.

[0040] In this embodiment, the kernel-mode probe is a probe module deployed in the kernel-mode space based on dynamic instrumentation technology (such as Kernel Probes, KProbes) and function tracer technology (Function Tracer, FTrace). It is used to monitor the execution of kernel functions in real time and capture kernel-mode data. This allows operations and maintenance personnel to flexibly add or modify the probe logic without affecting system stability.

[0041] Kernel-mode data can include function hierarchy relationships (i.e., the complete kernel call path), entry and exit timestamps for each kernel function, and resource monitoring data. The entry and exit timestamps for each kernel function are measured in nanoseconds; resource monitoring data can include CPU resource utilization and memory usage.

[0042] Specifically, after acquiring user-mode data based on the user-mode probe, the electronic device parses the user-mode data based on the kernel-mode probe, determines the call stack address related to the user-mode data, and performs a tracing operation based on the call stack address and a preset function tracer to capture the kernel-mode data.

[0043] S130. Generate tracing identifier information based on user-mode data and kernel-mode data, and establish the association between user-mode data and kernel-mode data based on the tracing identifier information to construct a function call chain.

[0044] In this embodiment of the application, the tracking identification information can be understood as identification information used to uniquely track user-mode data and kernel-mode data, that is, the complete cross-stack call path identification information from the time the target application initiates a system call to the time the kernel completes the processing.

[0045] Specifically, after acquiring user-mode data and kernel-mode data, the electronic device can generate tracking identification information based on preset identification generation rules and the user-mode and kernel-mode data. It can then establish a relationship between the user-mode and kernel-mode data based on this tracking identification information, that is, bind the user-mode and kernel-mode data to construct a function call chain. The preset identification generation rules are pre-set rules for generating tracking identification information and can be configured according to specific business scenarios and user needs; no restrictions are imposed here.

[0046] S140. Input the function call chain into the preset analysis engine, analyze the function call chain based on the preset analysis engine, and obtain the fault analysis results.

[0047] In this embodiment of the application, the preset analysis engine can be used for data analysis during system call process, i.e., fault location, streaming data processing of data (such as user space data and kernel space data), and data visualization processing, etc.

[0048] Fault analysis results can include information such as fault probability score and fault type.

[0049] Specifically, after constructing the function call chain, the electronic device inputs the function call chain into a preset analysis engine. Based on the anomaly detection model in the preset analysis engine, the user-mode data and kernel-mode data in the function call chain are analyzed to obtain fault analysis results.

[0050] Through the embodiments of this application, by setting up user-mode probes and kernel-mode probes, not only can user-mode data such as system call entry and exit information in user-mode space be captured through the user-mode probe, but kernel-mode data related to system calls in the operating system kernel can also be captured through the kernel-mode probe. That is, through the collaborative approach of dual probes, the specific call order and hierarchical relationships between various functions in the operating system kernel can be directly and clearly observed and traced. Simultaneously, the user-mode data and kernel-mode data are correlated through tracking identification information to construct a function call chain. This function call chain is then input into a preset analysis engine for analysis to obtain fault analysis results. This achieves full-link tracing of the system, solving the current problem of difficulty in fault and anomaly analysis at the operating system kernel level, and improving the efficiency and accuracy of fault analysis.

[0051] In this embodiment of the application, after capturing user-mode data based on the user-mode probe, the fault analysis method may further include: writing the user-mode data into a circular buffer based on the user-mode probe; and triggering an interrupt based on the user-mode probe and a preset interrupt function to notify the kernel-mode probe to retrieve the user-mode data from the circular buffer.

[0052] In this embodiment, a preset interrupt function is used to trigger an interrupt to notify the kernel-mode probe that new data has been stored in the circular buffer. For example, the preset interrupt function can be the ioctl() function.

[0053] In this embodiment, the circular buffer employs a dual-pointer lock-free design. It can be used to store user-space data, as well as metadata corresponding to that user-space data.

[0054] In this embodiment, data mapping is achieved by setting up a circular buffer, and the kernel probe is notified by triggering an interrupt function, thereby realizing zero-copy communication between user-mode data and kernel-mode data and reducing communication overhead during data transmission.

[0055] In this embodiment of the application, before writing user-space data into the circular buffer based on the user-space probe, the fault analysis method may further include: creating a circular buffer.

[0056] Specifically, creating a circular buffer can include: initiating a memory mapping system call to the system kernel based on a user-space probe and a preset memory mapping system call function to send memory mapping parameters to the system kernel; performing memory region allocation and mapping operations based on the system kernel and the memory mapping parameters to obtain the target mapping region; and dividing the target mapping region into a circular queue based on the system kernel to obtain a circular buffer. The circular buffer includes producer pointers and consumer pointers, which are synchronized based on a lock-free mechanism.

[0057] In this embodiment, the preset memory mapping system call function is a function used to map a memory region of a file or device to the address space of a process. For example, the preset memory mapping system call function can be the mmap() function.

[0058] Memory mapping parameters can include mapping type, ring buffer size, etc. The mapping type can be shared memory.

[0059] The producer pointer points to the location where the user-space probe writes data. The consumer pointer points to the location where the kernel-space probe reads data.

[0060] In this embodiment, a ring buffer is constructed using a preset memory-mapped system call function, and data synchronization in the ring buffer is performed based on a lock-free mechanism, achieving zero-copy sharing between user mode and kernel mode. In addition, microsecond-level data synchronization is achieved by combining interrupt notification.

[0061] In this embodiment of the application, writing user-mode data into a circular buffer based on a user-mode probe may specifically include: encapsulating and packaging the user-mode data based on the user-mode probe to obtain encapsulated and packaged user-mode data, and writing the encapsulated and packaged user-mode data into a circular buffer based on atomic operations.

[0062] Specifically, the process of encapsulating and packaging user-mode data based on user-mode probes to obtain encapsulated and packaged user-mode data can include: determining the data encapsulation structure based on user-mode probes and a preset syntax structure; writing the target fields in the user-mode data that correspond to the data encapsulation structure into the target positions in the data encapsulation structure based on user-mode probes to obtain a structured data object; and performing binary conversion processing on the structured data object based on user-mode probes to obtain the encapsulated and packaged user-mode data.

[0063] In this embodiment, the preset syntax structure is used to define a structured data model, specifying the fields to be encapsulated and their encapsulation forms. For example, the fields to be encapsulated may include function address fields, stored as hexadecimal strings or integers; system call parameters, encapsulated according to type definition, such as string types for file paths and integer / floating-point types for numeric parameters; return values, encapsulated according to type definition, such as integer types for file descriptors and enumeration types for error codes; metadata, etc. The preset syntax structure can be a Protocol Buffers syntax structure for binary data serialization.

[0064] Specifically, after obtaining user-space data, the electronic device determines the data encapsulation structure based on the user-space probe and a preset syntax structure. Following this structure, it writes the target fields corresponding to the encapsulation structure from the user-space data to the target locations within the encapsulation structure, resulting in a structured data object. This structured data object is then converted into a compact binary byte stream, yielding the encapsulated and packaged user-space data. This allows for processing user-space data based on the user-space probe, avoiding direct parsing of complex data structures by the system kernel, thus reducing the attack surface. Furthermore, encapsulating and packaging the user-space data significantly reduces its size and converts it to a binary data serialization format, further reducing data volume compared to other text formats, thereby lowering bandwidth and storage overhead during cross-space transmission.

[0065] Furthermore, after obtaining the encapsulated and packaged user-space data, the electronic device writes the encapsulated and packaged user-space data into the circular buffer based on atomic operations. This ensures that the update operations of the producer pointer and consumer pointer are atomic, avoids data corruption when multiple threads or processes operate on pointers simultaneously, and also avoids the performance overhead caused by using mutex locks and other similar methods. This achieves lock-free data transmission and improves the efficiency of data transmission.

[0066] In this embodiment, after the electronic device obtains user-mode data based on the user-mode probe, a preset interrupt function triggers an interrupt to notify the kernel-mode probe to obtain user-mode data from the circular buffer. After obtaining user-mode data based on the kernel-mode data, kernel-mode data is captured based on the kernel-mode probe and the user-mode data.

[0067] Capturing kernel-mode data based on kernel-mode probes and user-mode data can specifically include: parsing user-mode data based on kernel-mode probes to obtain the call stack address corresponding to the user-mode data and determine the kernel symbol corresponding to the call stack address; obtaining the target function corresponding to the kernel symbol based on kernel-mode probes, executing the target function, capturing the execution parameters corresponding to the target function, and determining the execution parameters as kernel-mode data.

[0068] Specifically, determining the kernel symbol corresponding to the call stack address can include: determining the kernel symbol corresponding to the call stack address based on a kernel-mode probe and a preset address symbol conversion function.

[0069] The default address symbol conversion function is used to provide function addresses and symbols. It looks up the corresponding kernel symbol through the function address, realizing the mapping between user-mode functions and kernel-mode functions in user-mode data. For example, the default address symbol conversion function can be the kallsyms_lookup() function. Based on the kallsyms_lookup() function, the address of user-mode glibc_open is converted to obtain the kernel function sys_open.

[0070] Furthermore, the target function corresponding to the kernel symbol is obtained based on the kernel-state probe, the target function is executed, and the execution parameters corresponding to the target function are captured. The execution parameters are then determined as kernel-state data. Specifically, this may include: obtaining the target function based on the kernel-state probe and determining whether the target function has registered a kernel-state probe; when it is determined that the target function has registered a kernel-state probe, activating a preset function tracker to perform a tracking operation, capturing the execution parameters corresponding to the target function, and determining the execution parameters as kernel-state data.

[0071] When it is determined that the target function is not registered with a kernel-mode probe, the function address corresponding to the target function is registered with the kernel-mode probe management system. Based on the system kernel, a breakpoint instruction is inserted at the entry point of the target function, the memory resources required by the kernel-mode probe are allocated, the kernel-mode probe status is recorded, and the target function is associated with the kernel-mode probe management list to register the target function with the kernel-mode probe. When registration is successful, a preset function tracker is activated to perform a tracing operation, capture the execution parameters corresponding to the target function, and determine the execution parameters as kernel-mode data. When registration fails, a rollback operation is performed.

[0072] In this embodiment, kernel-mode data capture is performed through intelligent decision-making logic. If the target function has a registered kernel-mode probe, the function tracer is directly activated; otherwise, the kernel-mode probe is dynamically loaded. Real-time tracing of the target function can be achieved without pre-compiling or restarting the kernel. This supports dynamically adding, modifying, or removing probes without affecting system stability, avoiding the lengthy and time-consuming process of recompiling the kernel in traditional methods.

[0073] In this embodiment of the application, after the electronic device obtains kernel-mode data, it generates tracking identification information based on user-mode data and kernel-mode data.

[0074] Generating tracing identifier information based on user-mode data and kernel-mode data can specifically include: obtaining a first timestamp, a first process identifier, and a first thread identifier corresponding to the user-mode data, and a second timestamp, a second process identifier, and a second thread identifier corresponding to the kernel-mode data; calculating a first hash value corresponding to the user-mode data and a second hash value corresponding to the kernel-mode data; and generating tracing identifier information based on a preset identifier generation rule and at least one of the first timestamp, the first process identifier, the first thread identifier, the second timestamp, the second process identifier, the second thread identifier, the first hash value, and the second hash value.

[0075] The preset identifier generation rules can include the order in which the strings are arranged when generating tracking identifier information.

[0076] The specific implementation method for calculating the first hash value corresponding to user-mode data and the second hash value corresponding to kernel-mode data is similar to the existing implementation method for calculating hash values, and will not be described in detail here.

[0077] In this embodiment, when generating tracing identification information, the timestamps corresponding to user-mode data and kernel-mode data are taken into account to avoid time conflicts. At the same time, process identification information and thread identification information are taken into account to distinguish different execution entities. By adding random numbers or hash values, the probability of collision is further reduced, ensuring that the generated tracing identification information meets the requirements of globally unique identification across stacks, processes, and time.

[0078] In this embodiment, after obtaining the function call chain, the electronic device preprocesses the function call chain to reduce the amount of data transmitted to the preset analysis engine. The preprocessing may include one or more of filtering, compression, and priority marking processes.

[0079] Before inputting the function call chain into the preset analysis engine, the fault analysis method may further include: filtering the function call chain to obtain a filtered function call chain; performing priority marking on the function call chain data in the filtered function call chain to obtain a target function call chain; and compressing the target function call chain to obtain a compressed target function call chain.

[0080] Specifically, the electronic device can filter the data in the function call chain based on kernel-mode probes and preset filtering rules, filtering out irrelevant functions such as the kernel scheduler and idle tasks. Based on preset priority rules and the kernel module names corresponding to the function call chain data in the filtered function call chain, the priority of each function call chain data is determined, and priority marking is performed on the function call chain data in the filtered function call chain. At the same time, the target function call chain (including tracking identification information) is compressed based on a preset compression algorithm (such as the lossless LZ4 compression algorithm) to obtain the compressed target function call chain.

[0081] In this embodiment, filtering the function call chain can remove irrelevant data, reduce the resource consumption of processing non-critical path data such as schedulers and idle tasks, and add priority markers to improve the efficiency of fault diagnosis and performance tuning, ensure that problems in core system paths are discovered and handled first, accelerate fault response, shorten fault location time, and reduce data transmission overhead and improve transmission efficiency.

[0082] In this embodiment, the function call chain is input to a preset analysis engine, and the function call chain is analyzed based on the preset analysis engine to obtain fault analysis results. Specifically, this may include: inputting the compressed target function call chain to the preset analysis engine, which parses the compressed target function call chain and extracts target data. The target data includes at least one of the function time, error code, and resource usage data corresponding to the compressed target function call chain; inputting the target data to the anomaly detection model of the preset analysis engine, which analyzes the target data to obtain fault analysis results. The fault analysis results include a fault probability score and a fault type.

[0083] In this embodiment, when the electronic device inputs the function call chain to the preset analysis engine based on the kernel-mode probe, the preset analysis engine receives the function call chain data through a socket-based communication mechanism, which improves the efficiency of data transmission. It also processes the data according to the CPU core segmentation, with each core having an independent queue. At the same time, it performs dynamic rate limiting based on the token bucket algorithm to dynamically adjust the consumption rate, avoid memory overflow, and ensure the normal operation of the system under high load.

[0084] When the operating system is Linux, the socket-based communication mechanism can be Netlink, the standard communication mechanism between the Linux kernel and user space.

[0085] Specifically, dynamic rate limiting based on the token bucket algorithm can include: a preset analysis engine generates tokens in a token bucket at a preset token generation rate. Each token corresponds to a certain amount of data processing permission (e.g., 1KB of data corresponds to 1 token). When data corresponding to a function call chain enters the preset analysis engine, it must obtain a token from the bucket before it can be processed. When the data input rate exceeds the token generation rate (total tokens in the bucket are exhausted), the engine triggers backpressure control to pause receiving new data or cache it in a temporary queue until tokens are regenerated in the bucket. If the input rate is lower than a preset threshold, tokens accumulate in the bucket (the bucket has a maximum capacity limit) to handle sudden traffic surges. The preset threshold can be dynamically adjusted according to the system load to balance processing efficiency and system stability.

[0086] In this embodiment, the function timeout is the execution time of each function, i.e., the time difference between the entry timestamp and the exit timestamp.

[0087] Error codes are standardized error identifiers returned when a system call fails to execute; they are unified symbols used in the system to describe the cause of the failure. For example, ENOENT indicates insufficient memory, EACCES indicates insufficient permissions, and ENOENT indicates that the file does not exist.

[0088] The failure probability score reflects the probability of a failure occurring. A score greater than 90 indicates a high likelihood of failure, while a score less than 50 indicates normal or low risk. Furthermore, the failure type is determined based on the correlation between the failure probability score and the failure type.

[0089] In the embodiments of this application, the anomaly detection model can be a model built based on a Bayesian network structure, or other models that can be used for anomaly detection, and there are no restrictions on this.

[0090] In this embodiment, analysis can be performed using an anomaly detection model in a preset analysis engine, automating the process, improving the efficiency and accuracy of fault analysis, and reducing labor costs.

[0091] In this embodiment of the application, after obtaining the fault analysis results, the fault analysis method may further include: generating a target control instruction based on the fault analysis results and a preset historical knowledge base, wherein the target control instruction includes a processing strategy for the target fault corresponding to the fault analysis results; executing the target control instruction to perform fault processing; and / or: generating alarm information based on the fault analysis results and feeding the alarm information back to the user.

[0092] The preset historical knowledge base stores fault characteristics, corresponding optimization measures, and execution effects.

[0093] Specifically, after obtaining the fault analysis results, if the fault analysis results indicate that a fault exists, the electronic device determines the fault characteristics based on the fault type and the corresponding data, matches the fault characteristics with the fault characteristics in the preset historical knowledge base, determines the corresponding optimization measures, determines the optimization measures as the processing strategy, generates target control instructions based on the processing strategy, and executes the target control instructions to perform fault processing.

[0094] In this embodiment of the application, after obtaining the fault analysis results, corresponding target control commands can be generated for fault handling, and / or; alarm information can be generated based on the fault analysis results and the alarm information can be fed back to the user, which improves the efficiency of fault handling and also improves the user experience by timely feeding back the fault information to the user.

[0095] In this embodiment, the electronic device can also send the fault analysis results and the processing strategy corresponding to the target control command to the preset rendering tool based on the preset analysis engine, and perform data rendering and display based on the preset rendering tool.

[0096] In this embodiment, the electronic device can further send resource usage data corresponding to the function call chain to a first preset rendering tool based on a preset analysis engine. The first preset rendering tool then renders the resource usage data, determines the CPU hotspot path, and displays the CPU hotspot path in the form of a flame graph. The device can also send the target function call hierarchy relationship corresponding to the function call chain to a second preset rendering tool based on the preset analysis engine. The second preset rendering tool then renders the data and presents the dependencies between functions in the form of a topology graph. Finally, the device can send the target call sequence corresponding to the function call chain to a third preset rendering tool based on the preset analysis engine. The third preset rendering tool then renders the data and displays the cross-state call chain sequence (i.e., function calls across user mode and kernel mode) in a timeline view. The first preset rendering tool can be the Perfetto rendering tool, the second preset rendering tool can be the Cytoscape.js rendering tool, and the third preset rendering tool can be the Chrome Tracing rendering tool. This allows users to intuitively see the relevant information of the function call chain, improving the user experience.

[0097] Figure 2 A flowchart of another fault analysis method provided in the embodiments of this application is shown below. Figure 2 As shown, this fault analysis method may specifically include the following steps:

[0098] S210, In response to a system call triggered by the target application, capture user-mode data based on the user-mode probe.

[0099] S220. Based on the user-mode probe, the user-mode data is encapsulated and packaged, and the encapsulated and packaged user-mode data is written into the circular buffer. An interrupt is triggered based on the user-mode probe and a preset interrupt function to notify the kernel-mode probe to retrieve the user-mode data from the circular buffer.

[0100] S230. Obtain user-mode data from the ring buffer based on the kernel-mode probe, parse the user-mode data, obtain the call stack address corresponding to the user-mode data, and determine the kernel symbol corresponding to the call stack address.

[0101] S240. Obtain the target function corresponding to the kernel symbol based on the kernel-mode probe, execute the target function, capture the execution parameters corresponding to the target function, and determine the execution parameters as kernel-mode data.

[0102] S250 generates tracing identifier information based on user-mode data and kernel-mode data, and establishes the association between user-mode data and kernel-mode data based on the tracing identifier information to construct a function call chain.

[0103] S260. Preprocess the function call chain to obtain the preprocessed function call chain.

[0104] S270. The preprocessed function call chain is input into the preset analysis engine, which parses and processes the preprocessed function call chain and extracts the target data. The target data is input into the anomaly detection model of the preset analysis engine, which analyzes the target data to obtain the fault analysis results; and / or, the preset analysis engine calls the preset rendering tool to render and display the preprocessed function call chain.

[0105] It should be noted that the specific implementation methods of steps S210 to S270 are similar to those of the relevant steps in the above embodiments of this application, and will not be repeated here.

[0106] Through the embodiments of this application, by setting up user-mode probes and kernel-mode probes, not only can user-mode data such as system call entry and exit information in user-mode space be captured through the user-mode probe, but kernel-mode data related to system calls in the operating system kernel can also be captured through the kernel-mode probe. That is, through the collaborative approach of dual probes, the specific call order and hierarchical relationships between various functions in the operating system kernel can be directly and clearly observed and traced. Simultaneously, a circular buffer is constructed using preset memory-mapped system call functions, and data synchronization within the circular buffer is performed based on a lock-free mechanism, achieving zero-copy sharing between user-mode and kernel-mode. Combined with interrupt notifications, microsecond-level data synchronization is achieved. After establishing a correlation between user-mode data and kernel-mode data through tracking identification information, constructing a function call chain, and preprocessing the function call chain, it is input into a preset analysis engine for analysis to obtain fault analysis results. This achieves full-link tracing of the system, solving the current problem of difficulty in fault and anomaly analysis at the operating system kernel level, and improving the efficiency and accuracy of fault analysis.

[0107] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0108] Embodiments of this application also provide a fault analysis device, which can be installed in an electronic device and can be understood as a part of the functional modules in the aforementioned electronic device.

[0109] like Figure 3 As shown, the fault analysis device 300 may include a first information acquisition module 310, a second information acquisition module 320, a function call chain construction module 330, and a fault analysis module 340.

[0110] The first information acquisition module 310 can be used to capture user-mode data based on a user-mode probe in response to a system call triggered by a target application.

[0111] The second information acquisition module 320 can be used to capture kernel-mode data based on kernel-mode probes and user-mode data.

[0112] The function call chain building module 330 can be used to generate tracing identifier information based on user-mode data and kernel-mode data, and establish the association between user-mode data and kernel-mode data based on the tracing identifier information to build a function call chain.

[0113] The fault analysis module 340 can be used to input the function call chain into the preset analysis engine, analyze the function call chain based on the preset analysis engine, and obtain the fault analysis results.

[0114] Through the embodiments of this application, by setting up user-mode probes and kernel-mode probes, not only can user-mode data such as system call entry and exit information in user-mode space be captured through the user-mode probe, but kernel-mode data related to system calls in the operating system kernel can also be captured through the kernel-mode probe. That is, through the collaborative approach of dual probes, the specific call order and hierarchical relationships between various functions in the operating system kernel can be directly and clearly observed and traced. Simultaneously, the user-mode data and kernel-mode data are correlated through tracking identification information to construct a function call chain. This function call chain is then input into a preset analysis engine for analysis to obtain fault analysis results. This achieves full-link tracing of the system, solving the current problem of difficulty in fault and anomaly analysis at the operating system kernel level, and improving the efficiency and accuracy of fault analysis.

[0115] In some embodiments of this application, the fault analysis device 300 may further include an information interaction module.

[0116] The information interaction module can be used to write user-state data into a circular buffer based on the user-state probe after capturing user-state data based on the user-state probe.

[0117] An interrupt is triggered based on the user-mode probe and a preset interrupt function to notify the kernel-mode probe to retrieve user-mode data from the circular buffer.

[0118] In some embodiments of this application, the fault analysis device 300 may further include a ring buffer creation module.

[0119] The circular buffer creation module can be used to initiate a memory mapping system call to the system kernel based on the user-mode probe and a preset memory mapping system call function before writing user-mode data to the circular buffer based on the user-mode probe, so as to send memory mapping parameters to the system kernel.

[0120] Memory region allocation and mapping operations are performed based on the system kernel and memory mapping parameters to obtain the target mapped region;

[0121] The target mapping region is divided into a circular queue based on the system kernel to obtain a circular buffer. The circular buffer includes producer pointers and consumer pointers, and the producer pointers and consumer pointers are synchronized based on a lock-free mechanism.

[0122] In some embodiments of this application, the information interaction module can be specifically used to encapsulate and package user-space data based on user-space probes to obtain encapsulated and packaged user-space data, and then write the encapsulated and packaged user-space data into a circular buffer based on atomic operations.

[0123] In some embodiments of this application, the information interaction module can also be specifically used to determine the data encapsulation structure based on the user-mode probe and the preset syntax structure;

[0124] Based on the user-space probe, the target field corresponding to the data encapsulation structure in the user-space data is written into the target position in the data encapsulation structure to obtain the structured data object;

[0125] The structured data object is converted into binary form based on the user-space probe to obtain the encapsulated and packaged user-space data.

[0126] In some embodiments of this application, the second information acquisition module 320 can be specifically used to parse user-mode data based on kernel-mode probe, obtain the call stack address corresponding to the user-mode data, and determine the kernel symbol corresponding to the call stack address;

[0127] The kernel probe is used to obtain the target function corresponding to the kernel symbol, execute the target function, and capture the execution parameters corresponding to the target function. The execution parameters are then determined as kernel-mode data.

[0128] In some embodiments of this application, the second information acquisition module 320 may also be specifically used to determine the kernel symbol corresponding to the call stack address based on the kernel state probe and a preset address symbol conversion function.

[0129] The second information acquisition module 320 can also be specifically used to acquire the target function based on the kernel-state probe and determine whether the target function has been registered with the kernel-state probe;

[0130] When it is determined that the target function has been registered with the kernel-mode probe, the preset function tracker is activated to perform a tracking operation, capture the execution parameters corresponding to the target function, and determine the execution parameters as kernel-mode data.

[0131] In some embodiments of this application, the fault analysis device 300 may further include a probe registration module.

[0132] The probe registration module can be used to register the function address corresponding to the target function to the kernel-mode probe management system after determining whether the target function has been registered with the kernel-mode probe. When it is determined that the target function has not been registered with the kernel-mode probe, the module can also register the target function to the kernel-mode probe management system, insert breakpoint instructions at the entry point of the target function based on the system kernel, allocate the memory resources required by the kernel-mode probe, record the kernel-mode probe status, and associate the target function with the kernel-mode probe management list in order to register the target function to the kernel-mode probe.

[0133] Upon successful registration, the preset function tracker is activated to perform a tracing operation, capture the execution parameters corresponding to the target function, and determine the execution parameters as kernel-mode data;

[0134] If registration fails, perform a rollback operation.

[0135] In some embodiments of this application, the function call chain construction module 330 can be specifically used to obtain the first timestamp, the first process identifier information and the first thread identifier information corresponding to user-mode data, and the second timestamp, the second process identifier information and the second thread identifier information corresponding to kernel-mode data;

[0136] Calculate the first hash value corresponding to the user-mode data and the second hash value corresponding to the kernel-mode data;

[0137] Based on preset identifier generation rules and at least one of the following: first timestamp, first process identifier, first thread identifier, second timestamp, second process identifier, second thread identifier, first hash value, and second hash value, trace identifier information is generated.

[0138] In some embodiments of this application, the fault analysis device 300 may further include a data preprocessing module.

[0139] The data preprocessing module can be used to filter the function call chain before it is input into the preset analysis engine, so as to obtain a filtered function call chain.

[0140] Priority marking is performed on the function call chain data in the filtered function call chain to obtain the target function call chain;

[0141] The target function call chain is compressed to obtain the compressed target function call chain.

[0142] In some embodiments of this application, the fault analysis module 340 can be specifically used to input the compressed target function call chain to a preset analysis engine, and the preset analysis engine will parse the compressed target function call chain and extract target data. The target data includes at least one of the function time, error code and resource usage data corresponding to the compressed target function call chain.

[0143] The target data is input into the anomaly detection model of the preset analysis engine. The anomaly detection model analyzes the target data to obtain the fault analysis results, which include the fault probability score and the fault type.

[0144] In some embodiments of this application, the fault analysis device 300 may further include generating a target control instruction based on the fault analysis result and a preset historical knowledge base after obtaining the fault analysis result. The target control instruction includes a processing strategy for the target fault corresponding to the fault analysis result.

[0145] Execute target control commands to handle faults;

[0146] and / or;

[0147] Alarm information is generated based on the fault analysis results and then fed back to the user.

[0148] For a description of the features in the embodiment corresponding to the fault analysis device 300, please refer to the relevant description in the embodiment corresponding to the fault analysis method, which will not be repeated here.

[0149] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described fault analysis method embodiments.

[0150] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described fault analysis method embodiments when it is run.

[0151] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0152] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described fault analysis method embodiments.

[0153] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described fault analysis method embodiments.

[0154] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0155] The foregoing has provided a detailed description of the fault analysis method, device, medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A fault analysis method, characterized in that, include: In response to system calls triggered by the target application, user-space data is captured based on user-space probes; Kernel-mode data is captured based on the kernel-mode probe and the user-mode data; Based on the user-mode data and the kernel-mode data, trace identification information is generated, and based on the trace identification information, the association between the user-mode data and the kernel-mode data is established to construct a function call chain; The function call chain is input into a preset analysis engine, and the function call chain is analyzed based on the preset analysis engine to obtain fault analysis results; The method of capturing kernel-mode data based on kernel-mode probes and user-mode data includes: The kernel-mode probe is used to parse the user-mode data to obtain the call stack address corresponding to the user-mode data. Based on the kernel-mode probe and a preset address symbol conversion function, the kernel symbol corresponding to the call stack address is determined. The kernel-state probe is used to obtain the target function corresponding to the kernel symbol, execute the target function, capture the execution parameters corresponding to the target function, and determine the execution parameters as the kernel-state data.

2. The fault analysis method according to claim 1, characterized in that, After capturing user-space data based on the user-space probe, the method further includes: The user-state data is written into the circular buffer based on the user-state probe. An interrupt is triggered based on the user-mode probe and a preset interrupt function to notify the kernel-mode probe to retrieve the user-mode data from the circular buffer.

3. The fault analysis method according to claim 2, characterized in that, Before writing the user-space data to the circular buffer based on the user-space probe, the method further includes: Based on the user-mode probe and the preset memory mapping system call function, a memory mapping system call is initiated to the system kernel to send memory mapping parameters to the system kernel; Based on the system kernel and the memory mapping parameters, memory region allocation and mapping operations are performed to obtain the target mapped region; The target mapping region is divided into a circular queue based on the system kernel to obtain the circular buffer. The circular buffer includes producer pointers and consumer pointers, and the producer pointers and consumer pointers are synchronized based on a lock-free mechanism.

4. The fault analysis method according to claim 2, characterized in that, The step of writing the user-space data into the circular buffer based on the user-space probe includes: The user-space data is encapsulated and packaged based on the user-space probe to obtain encapsulated and packaged user-space data, and then the encapsulated and packaged user-space data is written into the circular buffer based on atomic operations.

5. The fault analysis method according to claim 4, characterized in that, The process of encapsulating and packaging the user-space data based on the user-space probe to obtain encapsulated and packaged user-space data includes: The data encapsulation structure is determined based on the user-mode probe and the preset syntax structure; Based on the user-state probe, the target field corresponding to the data encapsulation structure in the user-state data is written into the target position in the data encapsulation structure to obtain a structured data object; The structured data object is converted into binary data based on the user-space probe to obtain the encapsulated and packaged user-space data.

6. The fault analysis method according to claim 1, characterized in that, The step of obtaining the target function corresponding to the kernel symbol based on the kernel-state probe, executing the target function, capturing the execution parameters corresponding to the target function, and determining the execution parameters as the kernel-state data includes: The target function is obtained based on the kernel-state probe, and it is determined whether the target function has been registered with the kernel-state probe. When it is determined that the target function has been registered with the kernel-state probe, the preset function tracker is activated to perform a tracking operation, capture the execution parameters corresponding to the target function, and determine the execution parameters as the kernel-state data.

7. The fault analysis method according to claim 6, characterized in that, After determining whether the target function has registered the kernel-mode probe, the method further includes: When it is determined that the target function has not been registered with the kernel-mode probe, the function address corresponding to the target function is registered with the kernel-mode probe management system. Based on the system kernel, a breakpoint instruction is inserted at the entry point of the target function, the memory resources required by the kernel-mode probe are allocated, the kernel-mode probe status is recorded, and the target function is associated with the kernel-mode probe management list to register the target function with the kernel-mode probe. Upon successful registration, the preset function tracker is activated to perform a tracking operation, capture the execution parameters corresponding to the target function, and determine the execution parameters as the kernel-state data; If registration fails, perform a rollback operation.

8. The fault analysis method according to claim 1, characterized in that, The generation of tracking identifier information based on the user-mode data and the kernel-mode data includes: Obtain the first timestamp, first process identifier information, and first thread identifier information corresponding to the user-mode data, and the second timestamp, second process identifier information, and second thread identifier information corresponding to the kernel-mode data; Calculate the first hash value corresponding to the user-mode data and the second hash value corresponding to the kernel-mode data; The tracking identification information is generated based on a preset identification generation rule and at least one of the following: the first timestamp, the first process identification information, the first thread identification information, the second timestamp, the second process identification information, the second thread identification information, the first hash value, and the second hash value.

9. The fault analysis method according to claim 1, characterized in that, Before inputting the function call chain into the preset analysis engine, the method further includes: The function call chain is filtered to obtain a filtered function call chain; Priority marking is performed on the function call chain data in the filtered function call chain to obtain the target function call chain; The target function call chain is compressed to obtain a compressed target function call chain.

10. The fault analysis method according to claim 9, characterized in that, The step of inputting the function call chain into a preset analysis engine, and analyzing the function call chain based on the preset analysis engine to obtain fault analysis results includes: The compressed target function call chain is input to the preset analysis engine, which parses the compressed target function call chain and extracts target data. The target data includes at least one of the function time, error code, and resource usage data corresponding to the compressed target function call chain. The target data is input into the anomaly detection model of the preset analysis engine, and the anomaly detection model analyzes the target data to obtain the fault analysis result, which includes a fault probability score and a fault type.

11. The fault analysis method according to claim 1 or 10, characterized in that, After obtaining the fault analysis results, the method further includes: Based on the fault analysis results and the preset historical knowledge base, a target control instruction is generated, and the target control instruction includes the handling strategy for the target fault corresponding to the fault analysis results; Execute the target control command to perform fault handling; and / or; Alarm information is generated based on the fault analysis results and then fed back to the user.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the fault analysis method as described in any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the fault analysis method as described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the fault analysis method as described in any one of claims 1 to 11.

Images