Unified Management Method and System for System Diagnostic Tools Adapting to Heterogeneous Plugins

Abstract

This application provides a unified management method and system for system diagnostic tools that adapt to heterogeneous plugins. The method includes: configuring a Seccomp filter for the target diagnostic process of the system diagnostic tool; obtaining the plugin identifier and operation parameters in the system call; querying whether corresponding cached diagnostic data exists in the BPF Map based on the plugin identifier and operation parameters; at the exit of the system call, the eBPF program detects whether the data write-through marker exists in the BPF Map; if it exists, the corresponding diagnostic data is read from the data cache of the BPF Map and written to the user buffer, and the return value register is modified to the data length in the data write-through marker. This method can achieve data path efficiency that matches the plugin backend processing speed while maintaining non-intrusive unified management of multiple heterogeneous plugins.

Description

Technical Field

[0001] This invention belongs to the field of operating system technology, and in particular relates to a unified management method and system for system diagnostic tools that adapt to heterogeneous plug-ins. Background Technology

[0002] In current data center operations and maintenance scenarios, the sources and forms of system diagnostic tools are extremely complex. Modifying their code in any form is impractical in engineering practice, specifically due to the following insurmountable obstacles: Commercial closed-source and license restrictions: Core business servers typically deploy commercial diagnostic suites provided by vendors such as Oracle, IBM, and Microsoft. These software programs are distributed in binary form and are strictly protected by end-user license agreements, legally and physically prohibiting users from decompiling, injecting code, or recompiling them; Legacy systems and lack of maintenance: Many critical tasks still run on legacy systems, whose accompanying diagnostic tools may have been developed by disbanded teams, with lost source code or long since ceased maintenance and updates. The technical and business interruption risks of modifying these systems are unacceptable; Static linking leading to injection failure: In containerized scenarios that prioritize ease of deployment and environment independence, diagnostic tools increasingly adopt static linking compilation. This renders traditional dynamic library injection schemes such as LD_PRELOAD fundamentally ineffective, unable to intercept any library function calls; Security and compliance constraints: In heavily regulated industries such as finance and government, system auditing requirements are stringent. Any modification to certified diagnostic tool binaries, or the injection of external code into the process address space, will result in a deviation from the security baseline and a failure to comply with regulations.

[0003] Integrating these heterogeneous plugins into a unified diagnostic platform typically requires modifying the diagnostic tool's own code to adapt to the communication protocols of each plugin, or embedding numerous adaptation layers within the tool. This not only increases maintenance costs but also easily introduces stability risks. Some solutions attempt to intercept data read calls from the diagnostic tool through user-mode function hijacking or dynamic library injection, forwarding requests to the corresponding plugin backend. However, such methods only work with dynamically linked library function calls and cannot intercept access initiated directly through system call instructions, rendering them completely ineffective for statically linked diagnostic tools. Other solutions employ kernel modules or the FUSE framework, which, while covering all system calls, introduce multiple context switches and memory copies, causing significant delays in frequent diagnostic data read operations and impacting real-time monitoring. eBPF technology can modify return values ​​or write to user buffers at system call exits, but its runtime environment is non-blocking and cannot independently complete slow-path operations that require interaction with heterogeneous plugin backends. Therefore, how to enable diagnostic tools to uniformly call different heterogeneous plugins to obtain diagnostic data without modifying the diagnostic tool's code or intruding on its runtime process, while simultaneously reducing the performance overhead of hot-path data reads, has become an unresolved problem. Summary of the Invention

[0004] To address the challenge of enabling diagnostic tools to uniformly access diagnostic data from different heterogeneous plugins without modifying their code or intruding on their runtime processes, while simultaneously reducing the performance overhead of reading hot path data, this application provides a unified management method and system for system diagnostic tools with heterogeneous plugin adaptation.

[0005] This application provides a unified management method for system diagnostic tools that adapt to heterogeneous plug-ins, including: Configure a Seccomp filter on the target diagnostic process of the system diagnostic tool to suspend system calls initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin and generate a Seccomp user notification, wherein the system call carries a plugin identifier. A proxy daemon running outside the target diagnostic process receives the Seccomp user notification, obtains the plugin identifier and operation parameters from the system call, queries the BPFMap for corresponding cached diagnostic data based on the plugin identifier and operation parameters, writes a data write flag containing the data length to the BPF Map, and returns the data length through the Seccomp user notification mechanism, and if no cached diagnostic data exists, selects the corresponding plugin backend adaptation logic based on the plugin identifier to obtain the diagnostic data, writes it to the user buffer specified by the system call through an inter-process memory copy operation, and returns the actual read length through the Seccomp user notification mechanism. The data write flag is used to instruct the eBPF program to perform direct writing to the user buffer. At the exit of the system call, the eBPF program checks whether the data write-through flag exists in the BPF Map. If it does, it reads the corresponding diagnostic data from the data cache of the BPF Map and writes it into the user buffer, and modifies the return value register to the data length in the data write-through flag.

[0006] Optionally, the proxy daemon receives the Seccomp user notification and obtains the plugin identifier and operation parameters from the system call, including: The plugin identifier and operation parameters are extracted from the parameter information carried by the Seccomp user notification. The plugin identifier represents the heterogeneous plugin called by the target diagnostic process.

[0007] Optionally, the step of querying the BPF Map for corresponding cached diagnostic data based on the plugin identifier and operation parameters includes: Using the plugin identifier and operation parameters as query keys, retrieve matching cached diagnostic data entries in the data cache area of ​​the BPF Map.

[0008] Optionally, when cached diagnostic data exists, writing a data write-through flag containing the data length to the BPF Map and returning the data length through the Seccomp user notification mechanism includes: Construct a direct-write tag carrying the data length and cache location information, and write it into the task area to be injected in the BPF Map; The Seccomp notification interface is invoked to send the data length to the kernel, thereby triggering the system call to return with the data length.

[0009] Optionally, when no cached diagnostic data exists, the step of selecting the corresponding plugin backend adaptation logic based on the plugin identifier to obtain diagnostic data, writing it to the user buffer specified by the system call through an inter-process memory copy operation, and then returning the actual read length through the Seccomp user notification mechanism includes: The proxy daemon process determines the corresponding adaptation logic based on the plugin identifier and obtains diagnostic data blocks from the plugin backend. The diagnostic data block is written to the user buffer by calling the inter-process memory copy function. The length of the diagnostic data block is returned to the kernel via the Seccomp notification mechanism.

[0010] Optionally, after returning the length of the diagnostic data block to the kernel via the Seccomp notification mechanism, the following steps are also included: The proxy daemon writes the diagnostic data block and its corresponding plugin identifier and operation parameters into the data cache area of ​​the BPF Map, as the cached diagnostic data for subsequent diagnostic data acquisition operations.

[0011] Optionally, at the exit of the system call, the eBPF program detects whether the data write-through flag exists in the BPF Map. If it does, the corresponding diagnostic data is read from the data cache of the BPF Map and written to the user buffer, including: When the eBPF program executes at the sys_exit trace point corresponding to the system call, it uses the current process identifier and the parameters of the system call as the search criteria to match the data write-through marker in the BPF Map to be injected task area; Upon successful matching, the bpf_probe_write_user function is called to write the corresponding cached diagnostic data from kernel space to the user buffer.

[0012] Optional, also includes: When the target diagnostic process initiates a plugin opening system call, the Seccomp filter suspends the plugin opening system call and generates an opening user notification, the plugin opening system call carrying the plugin identifier; The proxy daemon receives the open user notification, allocates an operation handle according to the plugin identifier, and returns the allocated operation handle to the target diagnostic process through the Seccomp user notification mechanism, so that the target diagnostic process can use the operation handle in subsequent diagnostic data acquisition operations. The value of the operation handle is within a preset range.

[0013] Optionally, the lowest value of the preset range is greater than the default handle range allocated by the operating system kernel for local resources, so that the eBPF program can identify the operation handle to be proxied through numerical comparison.

[0014] This application also provides a unified management system for system diagnostic tools that adapt to heterogeneous plug-ins, including: The Seccomp filter configuration module is used to apply a Seccomp filter to the target diagnostic process of the system diagnostic tool, so that the system call initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin is suspended and a Seccomp user notification is generated. The system call carries the plugin identifier. The proxy daemon configuration module is used to receive the Seccomp user notification and obtain the plugin identifier and operation parameters. When it is determined that the cached diagnostic data is hit, it writes a data write-through flag to the BPF Map and returns the length through the Seccomp notification. When it is not hit, it selects the corresponding plugin backend adaptation logic according to the plugin identifier, obtains the diagnostic data, and writes it into the user buffer of the target diagnostic process through inter-process memory copy before returning. The eBPF program configuration module is mounted at the system call exit point. It is used to detect the data write-through flag in the BPF Map, and when the data write-through flag exists, retrieve diagnostic data from the data cache of the BPF Map, write it to the user buffer, and modify the return value register.

[0015] In the embodiments provided in this application, an external Seccomp filter is configured for the target diagnostic process of the system diagnostic tool. This causes system calls initiated by the process to obtain diagnostic data for specified heterogeneous plugins to be suspended at the entry point and a notification to be generated. The plugin identifier carried in the call allows the same interface to distinguish different plugins. After receiving the notification and extracting the plugin identifier and operation parameters, the proxy daemon process queries the BPF Map to see if the corresponding diagnostic data has been cached. When the cache is hit, the proxy daemon process only writes a direct write marker containing the data length to the BPF Map and returns the length through the Seccomp notification. The actual data movement is completed by the eBPF program at the system call exit. After the eBPF program detects the marker, it retrieves the diagnostic data from the data cache of the BPF Map, directly fills the data into the application-provided buffer using user-space write capabilities, and modifies the return value register, so that a data read returns the correct result without the user-space proxy participating in data movement. When the cache is missed, the proxy daemon process selects the corresponding plugin backend adaptation logic based on the plugin identifier to obtain the data, then writes it to the user buffer through inter-process memory copying and returns. At the same time, it writes the data to the BPF Map for subsequent hits. Throughout the process described above, the diagnostic tool consistently uses the same system call interface and carries the plugin identifier to request data from different plugins. It is unaware of the heterogeneity of the underlying plugins, and the proxy daemon uniformly schedules interactions between different plugin backends based on the plugin identifier. In common scenarios where the same diagnostic data is repeatedly retrieved, the data flow is a BPF Map to the user buffer, completed entirely in kernel space. This eliminates the necessary user-space proxy memory copying step in previous solutions, reducing context switching and memory bus usage. Thus, while maintaining non-intrusive and unified management of multiple heterogeneous plugins, it achieves data path efficiency commensurate with the plugin backend processing speed. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of the unified management method for system diagnostic tools for heterogeneous plug-in adaptation in the embodiments of this application; Figure 2 This is one of the flowcharts of the sub-steps of the unified management method for system diagnostic tools for heterogeneous plug-in adaptation in the embodiments of this application; Figure 3 This is the second flowchart of a sub-step in the unified management method for system diagnostic tools for heterogeneous plug-in adaptation in the embodiments of this application.

[0018] Figure 4 This is the third flowchart of a sub-step in the unified management method for system diagnostic tools for heterogeneous plug-in adaptation in the embodiments of this application.

[0019] Figure 5 This is the fourth sub-step flowchart of the unified management method for system diagnostic tools for heterogeneous plug-in adaptation in the embodiments of this application.

[0020] Figure 6 This is a schematic diagram of the structure of the unified management system for heterogeneous plug-in adaptation system diagnostic tools in the embodiments of this application. Detailed Implementation

[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0022] like Figure 1 As shown in the figure, this application provides a unified management method for system diagnostic tools with heterogeneous plug-in adaptation, including: S101: Configure a Seccomp filter for the target diagnostic process of the system diagnostic tool so that the system call initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin is suspended and a Seccomp user notification is generated, wherein the system call carries a plugin identifier. S102: The proxy daemon running outside the target diagnostic process receives the Seccomp user notification, obtains the plugin identifier and operation parameters in the system call, queries the BPF Map to see if there is corresponding cached diagnostic data based on the plugin identifier and operation parameters, writes a data write-through flag containing the data length to the BPF Map and returns the data length through the Seccomp user notification mechanism, and if there is no cached diagnostic data, selects the corresponding plugin backend adaptation logic based on the plugin identifier to obtain the diagnostic data, writes it to the user buffer specified by the system call through an inter-process memory copy operation, and returns the actual read length through the Seccomp user notification mechanism. The data write-through flag is used to instruct the eBPF program to perform direct writing to the user buffer. S103: At the exit of the system call, the eBPF program detects whether the data write-through flag exists in the BPF Map. If it does, the corresponding diagnostic data is read from the data cache of the BPF Map and written into the user buffer, and the return value register is modified to the data length in the data write-through flag.

[0023] In this embodiment, configuring the Seccomp filter for the target diagnostic process of the system diagnostic tool is completed during the startup phase of the target diagnostic process. The entire process does not involve any modification to the target diagnostic process's address space, nor does it require the target diagnostic process to load any additional code or library files. The Seccomp filter, as a system call filtering mechanism provided by the operating system kernel, can intercept and process system calls in the early stages of the kernel processing flow. The configuration process is completed through the standard system call interface provided by the operating system. After configuration, all system calls initiated by the target diagnostic process that conform to the filter rules will be processed according to preset actions. For system calls used to obtain diagnostic data from specified heterogeneous plugins, the filter sets its action to generate a user notification and suspend the execution of the system call until the external process responds to the notification. This configuration method makes the target diagnostic process completely unaware of the filter's existence; its execution flow and code logic are not affected in any way, and no adaptation modifications are required for the proxy layer. Configuring the Seccomp filter can be achieved in various ways. For example, filter rules can be applied by the system service manager when starting the target diagnostic process; filters can be configured for all processes within the container during container creation by the container runtime; or filter rules can be loaded by a privileged parent process before calling execve to start the target diagnostic process. Different configuration methods are suitable for different deployment scenarios, and can be selected according to the actual operating environment and needs.

[0024] In this application embodiment, the Seccomp filter is configured through the `seccomp(2)` system call. For example, this can be implemented through code snippets. Of course, the code snippets in this application are prior art, and this application does not limit them.

[0025] In this embodiment, the proxy daemon runs in an address space independent of the target diagnostic process, possessing its own process context and resource allocation. The proxy daemon obtains the notification file descriptor associated with the Seccomp filter of the target diagnostic process through the file descriptor passing mechanism provided by the operating system, and receives Seccomp user notifications from the kernel by listening to events on that file descriptor. File descriptor passing can be implemented using Unix domain sockets or through inter-process inheritance, depending on the configuration of the Seccomp filter. When the target diagnostic process initiates a system call to obtain diagnostic data, the kernel generates a notification containing call context information according to pre-configured filter rules and sends this notification to the proxy daemon. Upon receiving the notification, the proxy daemon extracts all necessary information related to the current operation from the parameters carried in the notification, including but not limited to the process identifier of the target diagnostic process, the plugin identifier carried in the system call, and the relevant parameters of the current operation.

[0026] In this embodiment, the plugin identifier carried in the system call is used to uniquely identify the heterogeneous plugin requested for access by the target diagnostic process. The plugin identifier can be transmitted in various forms, such as being embedded in the pathname of a file system call, being passed as a parameter of a system call, or being identified through a specific field of the operation handle. When the plugin identifier is embedded in the pathname, a specific virtual directory can be agreed upon as the access entry point for all heterogeneous plugins, and the part of the pathname after this virtual directory is the plugin identifier. When the agent daemon parses the pathname parameter of the file open system call, it extracts the part after the virtual directory as the plugin identifier. When the plugin identifier is passed as a system call parameter, it can be encoded into a parameter of the system call, and the agent daemon extracts this parameter as the plugin identifier when parsing the notification. When the plugin identifier is identified through a specific field of the operation handle, it can be encoded into the high-order field of the handle when allocating the operation handle, and the agent daemon can directly extract the plugin identifier from the operation handle in subsequent operations. Regardless of the method used, the proxy daemon can correctly parse the plugin identifier according to pre-agreed rules, thereby determining the specific heterogeneous plugin that needs to be accessed in this operation. This design allows access to different heterogeneous plugins to be completed through a unified system call interface. The target diagnostic process only needs to change the plugin identifier to access different plugins, without needing to develop separate interaction logic for each plugin.

[0027] In this embodiment, the plugin identifier is preferably embedded using a virtual file system path. The system convention is ` / dev / diag-plugin / `. <plugin-id>`serves as a unified access point for all heterogeneous plugins, where` <plugin-id>` is a globally unique identifier for the plugin. The Seccomp filter is configured to intercept all file system calls prefixed with ` / dev / diag-plugin / `, including open, read, write, ioctl, and close. System calls to other paths are allowed directly without processing. This design allows the target diagnostic process to access heterogeneous plugins using standard file operation interfaces without any modifications.

[0028] In this embodiment, after obtaining the plugin identifier and operation parameters, the agent daemon uses this information as a query key to search the BPF Map maintained by the kernel to determine whether cached diagnostic data corresponding to the current operation exists. The BPF Map, as a key-value storage structure provided by the kernel, enables efficient data sharing between user-mode processes and kernel-mode programs (eBPF programs). The BPF Map used in this application contains multiple functional areas, used to store diagnostic data cache, data write-through task markers, and plugin metadata information. Different functional areas can be implemented using different types of BPF Maps. For example, the data cache area can use a hash table-type BPF Map to achieve fast lookup and insertion operations; the task marker area can also use a hash table-type BPF Map, using a combination of process identifier and system call identifier as the key. The cache query operation performed by the agent daemon is completed through standard BPF system calls provided by the operating system. The time overhead of the query process is within an acceptable range and will not significantly affect the system's response performance.

[0029] In this embodiment, the data buffer uses a BPF Map of type `BPF_MAP_TYPE_LRU_HASH`. The data buffer is existing technology and will not be described in detail here.

[0030] In this embodiment, when the proxy daemon finds cached diagnostic data corresponding to the current operation in the BPF Map, it does not perform any data copying operation. Instead, it writes a data write-through marker to a specific area in the BPF Map. This data write-through marker contains information such as the process identifier, plugin identifier, operation parameters, and the length of the actual diagnostic data, which is used to instruct the subsequently running kernel-mode program to perform data injection operations. After completing the writing of the data write-through marker, the proxy daemon sends a response to the kernel through the Seccomp user notification mechanism, passing the length of the actual diagnostic data as the return value of the system call to the kernel. Upon receiving this response, the kernel resumes the execution flow of the suspended system call and passes the return value provided by the proxy daemon to the target diagnostic process. This processing method avoids the proxy daemon's involvement in data handling, reduces the number of data copies between user mode and kernel mode, and improves the efficiency of data reading.

[0031] In this embodiment, when the proxy daemon does not find cached diagnostic data corresponding to the current operation in the BPF Map, it selects the corresponding plugin backend adaptation logic based on the parsed plugin identifier and communicates with the backend of the heterogeneous plugin to obtain diagnostic data. Different heterogeneous plugins may use different communication protocols and data formats. The proxy daemon internally maintains a plugin adaptation logic mapping table, which can automatically route to the corresponding adaptation logic module based on the plugin identifier. The adaptation logic module is responsible for interacting with the plugin backend, sending data requests and receiving responses, and converting the obtained raw data into diagnostic data blocks in a unified format. After successfully obtaining the diagnostic data block, the proxy daemon uses the inter-process memory copy mechanism provided by the operating system to directly write the diagnostic data block to the user buffer address specified by the system call in the target diagnostic process. This memory copy mechanism allows a process to directly access the address space of another process with appropriate permissions, thereby avoiding the additional data copy overhead caused by traditional inter-process communication methods such as pipes or sockets. After completing the data writing, the proxy daemon sends a response to the kernel through the Seccomp user notification mechanism, passing the actual length of the read data as the return value to the kernel. At the same time, the proxy daemon will write the newly acquired diagnostic data block and its corresponding plugin identifier and operation parameter information into the data cache area of ​​the BPF Map, so that subsequent identical diagnostic data acquisition operations can directly retrieve data from the cache and avoid communicating with the plugin backend again.

[0032] In this embodiment, the kernel-mode program is mounted on the exit trace point of the system call used to obtain diagnostic data. When the system call completes its kernel-side processing and is ready to return to user space, the kernel-mode program is triggered. During execution, the kernel-mode program first checks a specific region in the BPF Map to determine if a data write-through marker exists corresponding to the current process and the current system call. If a data write-through marker is detected, the kernel-mode program reads the corresponding diagnostic data block from the data cache region of the BPF Map based on the information contained in the marker, and calls the user-space write function provided by the kernel to directly write the data into the user buffer of the target diagnostic process. After the data write is complete, the kernel-mode program modifies the contents of the return value register stored in the kernel stack, setting it to the data length recorded in the data write-through marker. Finally, the kernel-mode program clears the corresponding data write-through marker in the BPF Map, completing the data injection operation. This approach ensures that data movement during cache hits is entirely completed in kernel mode, eliminating the performance overhead of copying data in user space.

[0033] In some embodiments, the proxy daemon receives the Seccomp user notification and obtains the plugin identifier and operation parameters from the system call, including: The plugin identifier and operation parameters are extracted from the parameter information carried by the Seccomp user notification. The plugin identifier represents the heterogeneous plugin called by the target diagnostic process.

[0034] In this embodiment, the Seccomp user notification contains all parameter information passed to the kernel when the target diagnostic process initiates a system call. This parameter information is organized according to the system call parameter layout defined by the operating system, accurately reflecting the call intent of the target diagnostic process. Different system calls have different numbers and meanings of parameters. The operating system kernel saves the system call parameters in a specific order into a notification data structure so that user-mode processes can parse them. After receiving the Seccomp user notification, the proxy daemon extracts the values ​​of each parameter from the notification data structure according to the system call parameter format specified by the operating system. For example, for file open system calls, parameters typically include a file pathname pointer, open flag, and file permissions; for file read system calls, parameters typically include a file descriptor, user buffer address pointer, requested data length, and file offset. By parsing these parameters, the proxy daemon can fully understand all the details of the target diagnostic process's operation and extract plugin identifiers used to identify heterogeneous plugins, as well as other relevant operation parameters. Plugin identifiers can be embedded into system call parameters in various ways. The proxy daemon parses these parameters according to pre-agreed rules to ensure correct identification of the heterogeneous plugins requested by the target diagnostic process.

[0035] In some embodiments, querying the BPF Map for corresponding cached diagnostic data based on the plugin identifier and operation parameters includes: Using the plugin identifier and operation parameters as query keys, retrieve matching cached diagnostic data entries in the data cache area of ​​the BPF Map.

[0036] In this embodiment, the data cache area of ​​the BPF Map is organized using a hash table, with a combination of plugin identifier and operation parameters as the key. A hash table is an efficient data structure capable of constant-time lookup and insertion operations on average, making it ideal for caching scenarios. Hash table collision resolution mechanisms can employ linked lists or open addressing; the choice depends on performance requirements and implementation complexity. When the proxy daemon needs to query the cache, it combines the plugin identifier and operation parameters extracted from the Seccomp user notification to generate a query key, which is then used to search the data cache area of ​​the BPF Map. If a matching cache entry is found, the diagnostic data required for this operation has been cached and can be used directly; otherwise, data needs to be retrieved from the corresponding heterogeneous plugin backend. Operation parameters typically include all necessary information related to the diagnostic data retrieval operation, such as the operation handle, data offset, requested data length, and operation type. Different types of diagnostic operations may require different operation parameters; the proxy daemon extracts the appropriate operation parameters based on the system call type and plugin characteristics to participate in query key generation. By combining plugin identifiers and operation parameters as query keys, the cached data for different operations of different plugins can be prevented from being mixed up, ensuring the accuracy of cache queries. At the same time, this key-value design also allows for flexible adjustment of the cache granularity, which can be set to the entire plugin, a single operation, or a specific data block according to actual needs.

[0037] like Figure 2 As shown, the step of writing a data write-through flag containing the data length to the BPF Map when cached diagnostic data exists, and returning the data length through the Seccomp user notification mechanism, includes: S201: Construct a direct write tag carrying the data length and cache location information, and write it into the task area to be injected in the BPF Map; S202: Call the Seccomp notification interface to send the data length to the kernel, thereby triggering the system call to return with the data length.

[0038] In this embodiment, the data write-through marker is a lightweight data structure containing all the necessary information for performing the data injection operation. Besides the length of the diagnostic data, the data write-through marker may also contain the location index of the cached data in the BPF Map, data verification information, operation timestamps, and other auxiliary information. The location index of the cached data indicates which position in the BPF Map the kernel program should read the cached data from; the data verification information verifies the integrity and correctness of the cached data, preventing data tampering or corruption; the operation timestamp records the marker's generation time, facilitating timeout handling and garbage collection. When constructing the data write-through marker, the agent daemon ensures the accuracy of the information in the marker so that the kernel program can correctly perform the data injection operation. The constructed data write-through marker is written to the injection task area of ​​the BPF Map, which also uses a hash table organization, with a combination of process identifier and system call identifier as the key. The process identifier distinguishes different target diagnostic processes, and the system call identifier distinguishes different system calls within the same process. This ensures that the kernel program can accurately find the marker corresponding to the current system call, preventing marker confusion. The proxy daemon sends responses to the kernel by calling the Seccomp notification interface provided by the operating system. This interface is a system call interface specifically designed for handling Seccomp user notifications, allowing user-mode processes to pass the processing results of system calls to the kernel. When the proxy daemon calls this interface, the kernel writes the returned value to the kernel stack of the target diagnostic process and resumes the execution flow of the suspended system call. After the system call resumes execution, it directly returns the return value provided by the proxy daemon to the target diagnostic process without executing the original system call processing logic in the kernel. This approach allows the proxy daemon to completely control the return results of system calls, thereby achieving transparent proxying of heterogeneous plugin diagnostic data.

[0039] like Figure 3 As shown, in some embodiments, when no cached diagnostic data exists, the step of selecting the corresponding plugin backend adaptation logic based on the plugin identifier to obtain diagnostic data, writing it to the user buffer specified by the system call through an inter-process memory copy operation, and then returning the actual read length through the Seccomp user notification mechanism includes: S301: The proxy daemon process determines the corresponding adaptation logic based on the plugin identifier and obtains diagnostic data blocks from the plugin backend; S302: Call the inter-process memory copy function to write the diagnostic data block into the user buffer; S303: Return the length of the diagnostic data block to the kernel via the Seccomp notification mechanism.

[0040] In this embodiment, the agent daemon internally maintains a plugin adaptation logic mapping table, which stores the mapping relationship between plugin identifiers and corresponding plugin backend adaptation logic. The mapping table can be implemented using a hash table or an array, enabling quick lookup of the corresponding adaptation logic module based on the plugin identifier. When the agent daemon needs to obtain diagnostic data from a heterogeneous plugin backend, it searches the mapping table based on the parsed plugin identifier to find the corresponding adaptation logic module. The adaptation logic module encapsulates all the details of communicating with a specific plugin backend, including the implementation of the communication protocol, data format conversion, and error handling. Different adaptation logic modules can interact with the plugin backend using different communication methods, such as local sockets, network protocols, shared memory, or other inter-process communication methods. This design allows the system to flexibly support various types of heterogeneous plugins. When adding new plugin support, only the corresponding adaptation logic module needs to be developed and registered in the mapping table; no other parts of the system need to be modified. Inter-process memory copy operations are completed through standard system calls provided by the operating system. This system call allows a process with appropriate permissions to directly write data into the address space of another process. When executing this operation, the proxy daemon needs to provide the process ID of the target diagnostic process, the address of the target buffer, and the length and starting address of the data to be written. Upon receiving the system call, the operating system kernel performs a strict permission check to ensure that the proxy daemon has permission to access the target diagnostic process's address space. If the permission check passes, the kernel copies the data from the proxy daemon's address space to the specified location in the target diagnostic process's address space. This method avoids the overhead of transferring data through an intermediate buffer, improving data transfer efficiency. After writing the data, the proxy daemon returns the length of the diagnostic data block to the kernel via the Seccomp notification mechanism, and the kernel passes this length as the return value of the system call to the target diagnostic process.

[0041] In this embodiment, inter-process memory copying is implemented through the `process_vm_writev(2)` system call. This system call allows one process, with appropriate permissions, to directly write data into the address space of another process. Before performing the copy operation, the proxy daemon first reads ` / proc / ` <pid>The ` / maps` file is used to check if the target buffer address is within the writable memory region of the target process. If the target buffer is not writable, the error code `EFAULT` is returned.

[0042] In some embodiments, after returning the length of the diagnostic data block to the kernel via the Seccomp notification mechanism, the method further includes: The proxy daemon writes the diagnostic data block and its corresponding plugin identifier and operation parameters into the data cache area of ​​the BPF Map, as the cached diagnostic data for subsequent diagnostic data acquisition operations.

[0043] In this embodiment, after the proxy daemon completes data writing and sends a response to the kernel, it asynchronously performs a cache backfill operation. Asynchronous execution means that the cache backfill operation will not block the proxy daemon's processing of subsequent Seccomp user notifications, but will instead be executed in a separate background thread. This ensures the daemon's response performance and prevents delays in processing other requests due to the cache backfill operation. The cache backfill operation writes the diagnostic data block just obtained from the heterogeneous plugin backend and its corresponding metadata information into the BPF Map's data cache area. The metadata information includes the plugin identifier, operation parameters, data length, data generation time, and data expiration time. The data generation time records the data collection time, facilitating the assessment of data freshness; the data expiration time specifies the effective time of the data in the cache. Data exceeding the expiration time is considered invalid and needs to be removed from the cache. By setting the data expiration time, excessive expired data can be avoided in the cache, ensuring cache effectiveness and reasonable utilization of storage space. The BPF Map's data cache area employs an automatic cache eviction mechanism to prevent excessive cached data from exhausting memory resources. Cache eviction mechanisms can employ various strategies. For example, a Least Recently Used (LRU) strategy can evict cached data that hasn't been accessed for the longest time; a First-In-First-Out (FIFO) strategy can evict the earliest cached data; and a frequency-based strategy can evict the least frequently accessed cached data. Different eviction strategies can be selected based on the actual workload and application scenario to achieve the optimal cache hit rate and system performance. The proxy daemon periodically checks cache usage. When cache usage reaches a preset threshold, it triggers a cache eviction operation, freeing up memory space to store new cached data.

[0044] In this embodiment, the data cache employs an LRU (Least Recently Used) eviction policy. When the cache is full, the system automatically evicts the cache entry that has not been accessed for the longest time. Simultaneously, the system sets an expiration time for each cache entry, with a default expiration time of 5 seconds. When a cache entry exceeds its expiration time, it will be automatically evicted even if the cache is not full. The expiration time can be set individually for each plugin through a configuration file; for diagnostic data with a low update frequency, the expiration time can be appropriately extended.

[0045] like Figure 4 As shown, in some embodiments, at the exit of the system call, the eBPF program detects whether the data write-through flag exists in the BPF Map. If it does, the corresponding diagnostic data is read from the data cache of the BPF Map and written to the user buffer, including: S401: When the eBPF program executes at the sys_exit trace point corresponding to the system call, it uses the current process identifier and the parameters of the system call as the search basis to match the data write-through marker in the BPF Map to be injected task area; S402: When a match is successful, the bpf_probe_write_user function is called to write the corresponding cached diagnostic data from the kernel space to the user buffer.

[0046] In this embodiment, the kernel-mode program executes at the `sys_exit` trace point corresponding to the system call used to obtain diagnostic data. The `sys_exit` trace point is located at the end of the system call processing flow, at which point the kernel has completed all necessary cleanup work and is ready to return control to user space. Performing data injection at this location minimizes interference with the normal kernel execution flow while ensuring that the target diagnostic process receives the correct return value and data. Performing data injection at the `sys_enter` trace point might interfere with subsequent kernel processing, leading to system anomalies. When the kernel-mode program executes, it first obtains the process identifier of the current process and the parameter information of the current system call. The process identifier can be obtained through a helper function provided by the kernel, and the system call parameter information can be read from the kernel stack. Then, the kernel-mode program uses this information as a search criterion to search the injection task area in the BPF Map for a matching data direct write marker. If a matching marker is found, it means that the current system call requires data injection; if no matching marker is found, it means that the current system call does not require special processing, and the kernel-mode program directly allows the system call to return. When the kernel-mode program finds a matching data write-through marker in the region of the task to be injected, it reads the corresponding diagnostic data block from the data cache region of the BPF Map based on the cache location information provided in the marker. Then, the kernel-mode program calls the user-space write function provided by the kernel to write the read diagnostic data block into the target diagnostic process's user buffer. This user-space write function is a kernel-specific function for securely accessing user-space memory in kernel mode. It checks the validity and accessibility of the user buffer before writing data, preventing system crashes or security vulnerabilities. After the data writing is complete, the kernel-mode program modifies the contents of the return value register stored in the kernel stack, setting it to the data length recorded in the data write-through marker. Thus, when the system call returns to user space, the target diagnostic process considers the read operation successful and has obtained the correct diagnostic data. Finally, the kernel-mode program clears the corresponding data write-through marker in the BPF Map to prevent it from being incorrectly used by subsequent system calls.

[0047] like Figure 5 As shown, it also includes: S501: When the target diagnostic process initiates a plugin open system call, the Seccomp filter suspends the plugin open system call and generates an open user notification, wherein the plugin open system call carries the plugin identifier. S502: The agent daemon process receives the open user notification, allocates an operation handle according to the plugin identifier, and returns the allocated operation handle to the target diagnostic process through the Seccomp user notification mechanism, so that the target diagnostic process can use the operation handle in subsequent diagnostic data acquisition operations. The value of the operation handle is within a preset range.

[0048] In this embodiment, when the target diagnostic process needs to access a heterogeneous plugin, it first initiates a plugin open system call. This system call uses the same interface as a regular file open system call, and the call parameters carry a plugin identifier used to identify the target plugin. A pre-configured Seccomp filter intercepts the plugin open system call, suspends it, and generates an open user notification. After receiving the open user notification, the proxy daemon extracts the plugin identifier and open parameters from the notification. Then, the proxy daemon checks whether the corresponding plugin backend is reachable and available based on the plugin identifier. The check process includes establishing a connection with the plugin backend, sending heartbeat packets, or performing version negotiation to ensure that the plugin backend can provide services normally. If the plugin backend is unavailable, the proxy daemon returns the corresponding error code to the kernel through the Seccomp notification mechanism, which is then handled by the target diagnostic process. If the plugin backend is available, the proxy daemon allocates an operation handle from its maintained global handle pool. The handle pool is a data structure maintained internally by the proxy daemon to manage all allocated operation handles. The handle pool can be organized using a bitmap or a linked list, enabling efficient allocation and recycling of handles. Bitmap-based methods are suitable for scenarios with a fixed handle range, enabling quick identification of unused handles. Linked list-based methods are suitable for scenarios with a dynamically changing handle range, allowing for flexible management of handle resources. When allocating operation handles, the proxy daemon selects an unused handle from the handle pool and establishes a mapping relationship between this handle and the plugin identifier and the plugin's backend connection information, recording this in an internal handle mapping table. The handle mapping table can be implemented using a hash table, allowing for quick lookup of corresponding plugin and connection information based on the operation handle. After completing the allocation and mapping of operation handles, the proxy daemon returns the allocated operation handle to the kernel via the Seccomp user notification mechanism. Upon receiving the return value, the kernel resumes the execution flow of the suspended plugin open system call and returns the operation handle to the target diagnostic process. The target diagnostic process, upon receiving the operation handle, uses it as a regular file descriptor, passing it through subsequent diagnostic data acquisition, writing, and closing operations. This design allows the target diagnostic process to access the diagnostic data of heterogeneous plugins using standard file operation interfaces, without needing to learn new interfaces or modify existing code.

[0049] In this embodiment, the handle pool size is fixed at 65536, and a bitmap allocation algorithm is used. Each bit in the bitmap corresponds to a handle; a bit value of 0 indicates that the handle is not in use, and a bit value of 1 indicates that the handle is in use. The handle value range is from 100000 to 165535, ensuring that it is greater than the default handle range allocated by the operating system kernel. When allocating a handle, the system finds the first bit with a value of 0 in the bitmap, sets it to 1, and returns the corresponding handle value. When reclaiming a handle, the system sets the corresponding bit to 0. To avoid errors caused by handle reuse, the system adopts a delayed reclamation mechanism, delaying the reallocation of handles after they are reclaimed for 10 seconds.

[0050] In some embodiments, the lowest value of the preset range is greater than the default handle range allocated by the operating system kernel for local resources, so that the eBPF program can identify the operation handle to be proxied through numerical comparison.

[0051] In this embodiment, the value of the operation handle allocated by the proxy daemon process is within a preset range. The minimum value of this preset range is set to be greater than the maximum value of the default handle range allocated by the operating system kernel for local resources. When allocating handles for local files, sockets, pipes, and other resources, the operating system kernel typically starts with smaller values ​​and allocates them sequentially, usually starting from 3, because 0, 1, and 2 are occupied by standard input, standard output, and standard error, respectively. However, the operation handles allocated by the proxy daemon process start with larger values, such as 100000, which ensures that the proxy operation handle will not conflict with the local resource handles allocated by the kernel. This design allows kernel-mode programs to quickly identify whether a handle belongs to the operation handle allocated by the proxy daemon process through simple numerical comparison. When the kernel-mode program processes a system call, if it finds that the handle value is greater than the preset threshold, it can determine that the handle was allocated by the proxy daemon process and needs to be handled specially; if the handle value is less than or equal to the preset threshold, it means that the handle is a local resource handle allocated by the kernel and does not require proxy processing. This identification method is simple and efficient, requiring no maintenance of complex mapping tables or additional system calls, resulting in extremely high execution efficiency and no significant impact on overall system performance. Furthermore, this design allows the target diagnostic process to use both proxy operation handles and local resource handles simultaneously without conflict, improving system compatibility and flexibility. The target diagnostic process can access both local files and diagnostic data from heterogeneous plugins without any special processing.

[0052] In this embodiment, a monitoring system diagnostic tool needs to periodically collect CPU diagnostic information and storage system health status from the server. The CPU diagnostic plugin and the storage diagnostic plugin are developed by different providers and use different interface protocols and data formats. The diagnostic tool opens and reads the diagnostic data from both plugins at fixed time intervals to monitor the server's operating status in real time.

[0053] In this embodiment, when the diagnostic tool starts, the operations and maintenance platform configures Seccomp filter rules for it using a container orchestration tool and passes the notification file descriptor associated with the filter to the agent daemon running on the host operating system. The diagnostic tool itself is a standard executable program; its code logic contains no agent-related content and it is completely unaware of the agent's existence. After the diagnostic tool starts, it first calls the open operation sequentially, passing in paths containing CPU health and storage status identifiers respectively. Both of these open calls are intercepted by the Seccomp filter, generating corresponding open user notifications.

[0054] In this embodiment, after the proxy daemon detects an event on the notification file descriptor, it first reads and parses the first open notification, extracting the CPU health identifier. Then, the proxy daemon checks the status of the CPU diagnostic plugin backend to confirm its normal operation and reachability. After confirmation, the proxy daemon allocates an operation handle in a preset high-order range from the global handle pool and records the correspondence between the operation handle, the CPU health identifier, and the plugin backend connection information in its internal handle mapping table. Subsequently, the proxy daemon returns the allocated operation handle to the kernel via the Seccomp notification mechanism. The kernel resumes the suspended open call and returns the operation handle to the diagnostic tool. For open notifications with storage status identifiers, the proxy daemon performs a similar process, allocating another different operation handle and returning it to the diagnostic tool. After obtaining both operation handles, the diagnostic tool saves them as ordinary file descriptors for subsequent read operations.

[0055] In this embodiment, after obtaining the operation handle, the diagnostic tool first performs a read operation on the CPU plugin's operation handle, providing the user buffer address and the requested data length. This read system call is intercepted and suspended by the Seccomp filter, generating a read user notification. Upon receiving this notification, the proxy daemon extracts the operation handle and offset, among other operation parameters. Then, the proxy daemon searches for the corresponding plugin identifier in the internal handle mapping table based on the operation handle to obtain the CPU health identifier. Next, the proxy daemon uses the CPU health identifier and operation parameters as query keys to search the data cache area of ​​the BPF Map. Since this is the first read operation after the diagnostic tool starts, there is no corresponding cached data in the BPF Map, resulting in a cache miss.

[0056] In this embodiment, after detecting a cache miss, the proxy daemon searches for the corresponding adaptation logic module in the plugin adaptation logic mapping table based on the CPU health identifier. Once the adaptation logic module is found, the proxy daemon calls the module's interface to send a data request to the CPU diagnostic plugin backend. Upon receiving the request, the CPU diagnostic plugin backend collects the current CPU diagnostic information and returns the data to the proxy daemon. After receiving the returned diagnostic data, the proxy daemon performs format conversion and verification to ensure data integrity and correctness. Then, the proxy daemon calls the inter-process memory copy function to directly write the diagnostic data block to the user buffer address provided by the diagnostic tool. After completing the data writing, the proxy daemon returns the actual length of data read to the kernel through the Seccomp notification mechanism. The kernel resumes the suspended read call and returns the length to the diagnostic tool. Simultaneously, the proxy daemon asynchronously writes the newly acquired diagnostic data block, along with its corresponding plugin identifier and operation parameters, into the data cache area of ​​the BPF Map in the background, forming a cache entry so that subsequent identical read operations can hit the cache.

[0057] In this embodiment, when the read system call reaches the exit trace point, the kernel-mode program mounted at that trace point is triggered to execute. The kernel-mode program first obtains the process identifier of the current process and the parameter information of the current system call, and then uses this information to search in the task to be injected region of the BPF Map. Since the cache miss occurred in this operation, the agent daemon did not write the data write-through flag, so the kernel-mode program did not find a matching flag and directly allowed the system call to return. The diagnostic tool obtains the correct data length from the read system call, and its user buffer has been filled with CPU diagnostic data. The entire read process is completely transparent to the diagnostic tool.

[0058] In this embodiment, after one acquisition cycle, the diagnostic tool initiates a read operation again on the same offset of the same CPU plug-in operation handle. This read system call is again intercepted by the Seccomp filter, generating a notification. Upon receiving the notification, the agent daemon performs the same parameter parsing and cache lookup operations as before. Since the agent daemon had already written the diagnostic data to the BPF Map's data cache area after the previous read, this query hits the cached data.

[0059] In this embodiment, after detecting a cache hit, the proxy daemon does not perform any communication operations with the plugin backend, nor does it perform any data copying operations. Instead, it constructs a data write-through marker, which includes the process identifier, plugin identifier, operation parameters, and the length and location information of the cached data. Then, the proxy daemon writes this data write-through marker to the injection task area of ​​the BPF Map. After completing the marker writing, the proxy daemon returns the length of the cached data to the kernel through the Seccomp notification mechanism. The kernel then resumes the execution flow of the suspended read system call.

[0060] In this embodiment, when the system call reaches the exit trace point, the kernel-mode program is triggered to execute. After obtaining the process ID and system call parameters of the current process, the kernel-mode program searches the task area to be injected in the BPF Map and successfully finds the data write-through marker corresponding to this operation. Then, based on the cache location information provided in the marker, the kernel-mode program reads the corresponding CPU diagnostic data block from the data cache area of ​​the BPF Map. Next, the kernel-mode program calls the user-space write function provided by the kernel to directly write the diagnostic data block to the user buffer address provided by the diagnostic tool. After completing the data writing, the kernel-mode program modifies the contents of the return value register stored in the kernel stack, setting it to the data length recorded in the data write-through marker. Finally, the kernel-mode program clears the corresponding data write-through marker in the BPF Map. After the system call completes all processing steps, it returns the return value to the diagnostic tool. The diagnostic tool obtains the correct data length from the system call, and its user buffer is filled with the latest CPU diagnostic data. Throughout the entire process, the agent daemon does not participate in any data transfer operations.

[0061] In this embodiment, if the diagnostic tool alternately reads the operation handle of the storage plugin during the acquisition cycle, its processing flow is similar to that of the CPU plugin. When the diagnostic tool initiates its first read operation on the storage plugin's operation handle, a cache miss occurs. The agent daemon process obtains data from the storage diagnostic plugin's backend through the storage plugin's adaptation logic, writes it to the diagnostic tool's user buffer, returns the length, and simultaneously writes the data to the cache. Subsequent read operations that hit the cache follow a fast processing path, with the kernel-mode program handling the data injection.

[0062] In this embodiment, after the diagnostic tool completes the collection of diagnostic data for a plugin, it calls a shutdown operation to close the corresponding operation handle. This shutdown system call is intercepted by the Seccomp filter, generating a shutdown user notification. Upon receiving this notification, the proxy daemon extracts the operation handle from it. Then, based on the operation handle, the proxy daemon finds the corresponding plugin identifier and plugin backend connection information in its internal handle mapping table and sends a request to the plugin backend to close the connection. Upon receiving the request, the plugin backend closes the connection and releases related resources. After receiving confirmation from the plugin backend, the proxy daemon reclaims the corresponding operation handle from the global handle pool and clears the corresponding entry from the internal handle mapping table. Finally, the proxy daemon sends a success response to the kernel via the Seccomp notification mechanism. The kernel then resumes the execution flow of the suspended shutdown system call and passes the success return value to the diagnostic tool.

[0063] In this embodiment, when the diagnostic tool completes all data collection tasks and exits, the kernel triggers a process exit event. The kernel-mode program mounted on the process exit tracking point detects this event and writes the process exit information to a specific area in the BPF Map. The agent daemon periodically polls this area, and when it detects a process exit, it cleans up all resources related to that process, including closing all unclosed agent operation handles, clearing all cached data and task markers related to that process in the BPF Map, etc. Simultaneously, the agent daemon also listens for the closing event of the notification file descriptor associated with the target diagnostic process. When it detects that a file descriptor is closed, it also performs resource cleanup operations to ensure that there are no resource leaks in the heterogeneous plugin backend.

[0064] In this embodiment, the system has a robust error handling mechanism to handle various possible anomalies. When a network error or plugin backend failure occurs during communication between the agent daemon and the heterogeneous plugin backend, appropriate measures are taken based on the type and severity of the error. For temporary errors, the agent daemon performs a limited number of retries to resend the data request. The number and interval of retries can be configured according to actual needs to balance system response performance and fault tolerance. For permanent errors or errors that cannot be resolved after retries, the agent daemon returns the corresponding error code to the kernel through the Seccomp notification mechanism for processing by the target diagnostic process. The target diagnostic process can perform appropriate error handling based on the returned error code, such as logging, retrying, or displaying error messages to the user. When a kernel-mode program performs a data injection operation, if it finds that the user buffer address is invalid or inaccessible, it will abandon the data injection operation, record the error information in the system log, and keep the original system call return value unchanged to avoid causing the target diagnostic process to crash. When the BPF Map's storage space is insufficient, the proxy daemon will trigger a cache eviction mechanism, releasing some infrequently used cached data to make room for new cached data. If there is still not enough storage space after cache eviction, the proxy daemon will temporarily suspend cache refilling operations until sufficient storage space is available.

[0065] In this embodiment, the system employs various performance optimization measures to improve overall system performance and response speed. The agent daemon adopts a multi-threaded architecture, using a thread pool to handle concurrent Seccomp user notifications, avoiding the overhead of frequent thread creation and destruction. The size of the thread pool can be configured according to the number of CPU cores and actual concurrency requirements to achieve optimal performance. The size and number of BPF Maps can be flexibly configured according to the actual workload to adapt to systems of different sizes and different numbers of heterogeneous plugins. For scenarios with a large amount of cached data, the size of the data cache area can be appropriately increased to improve the cache hit rate. For scenarios with many concurrent requests, the number of BPF Maps can be appropriately increased to reduce lock contention. The kernel-mode program code has been carefully optimized to minimize unnecessary operations and improve execution efficiency. For example, when the kernel-mode program performs numerical comparison to identify the agent handle, it only performs a simple integer comparison, without performing complex table lookup operations. The system also supports data prefetching functionality. The agent daemon can prefetch potentially needed diagnostic data into the BPF Map based on the access pattern and update frequency of diagnostic data, further improving the cache hit rate and system performance. In addition, the system supports batch processing, which can process multiple consecutive or related diagnostic data requests in batches, reducing the number of system calls and the overhead of context switching.

[0066] In this embodiment, the system handles the differences between different kernel versions through conditional compilation. For example, for kernel versions 5.8 and above, the `bpf_probe_write_user()` function is used to write to the user buffer; for kernel versions below 5.8, the `bpf_copy_to_user()` function is used. The system automatically detects the target kernel version when compiling the eBPF program and selects the corresponding function implementation. Simultaneously, the system provides a kernel version detection function to check at runtime whether the current kernel version supports the required BPF features. In this embodiment, to handle race conditions when multiple proxy daemons or eBPF programs access the BPF Map simultaneously, the system uses BPF spinlocks to protect concurrent access to the BPF Map. For frequently accessed data buffers, the system employs a fragmented locking mechanism, dividing the buffer into multiple independent fragments, each using a separate spinlock. This reduces lock contention and improves concurrent access performance.

[0067] In this application embodiment, the system supports multiple deployment scenarios and can adapt to various application environments. In a physical server deployment scenario, the agent daemon runs on the physical server's operating system, providing unified heterogeneous plugin management services for all system diagnostic tool processes on the server. This deployment method is suitable for traditional physical server environments and can fully utilize server hardware resources. In a virtual machine deployment scenario, the agent daemon can run inside a virtual machine, providing services to diagnostic tool processes within the virtual machine, or it can run on the host machine, providing shared agent services to all virtual machines. The deployment method running inside a virtual machine offers better isolation, as agent services between different virtual machines will not interfere with each other; the deployment method running on the host machine allows for resource sharing, improving resource utilization. In a container deployment scenario, the agent daemon can run inside each container, providing services to a single diagnostic tool process within the container, or it can run on the host machine, providing shared agent services to all containers. The deployment method running inside each container offers the best isolation and is suitable for multi-tenant environments; the deployment method running on the host machine reduces resource consumption and improves overall system performance. In cloud platform deployment scenarios, the system can be provided to users as a basic service of the cloud platform. Users only need to select the corresponding options when creating a diagnostic tool instance to automatically obtain the ability to manage heterogeneous plugins in a unified manner without any additional configuration or modification.

[0068] In this embodiment, the system exhibits excellent scalability, readily supporting new heterogeneous plugins and functionalities. When adding support for a new heterogeneous plugin, only the corresponding plugin backend adaptation logic module needs to be developed and registered in the plugin adaptation logic mapping table of the proxy daemon process; no other parts of the system need to be modified. The adaptation logic module can be implemented as a dynamic link library, supporting dynamic loading and unloading during the proxy daemon process's operation without requiring a restart of the proxy daemon process. This dynamic loading mechanism allows the system to add new plugin support without interrupting service, improving system availability and maintainability. When supporting new system calls or new operation types is required, only the corresponding system calls need to be added to the Seccomp filter rules, and the corresponding processing logic implemented in the proxy daemon process and kernel-mode program. The system architecture adopts a modular and layered approach, with low coupling between modules, making system expansion and maintenance more convenient. Each module has clearly defined responsibilities and interfaces; modifying one module will not affect the functionality of other modules.

[0069] In this embodiment, the system exhibits robust security, effectively protecting system and data security. The Seccomp filter, a kernel-provided security mechanism, effectively restricts process system call permissions, preventing unauthorized operations. The proxy daemon runs in an independent process context, possessing minimal necessary permissions and accessing only resources required for its operation, posing no security threat to the target diagnostic process or other parts of the system. Kernel-mode programs run in the kernel context, but their code undergoes rigorous review and verification to prevent the introduction of security vulnerabilities. Furthermore, the system employs multiple security measures, such as permission checks, data verification, access control, and security auditing, effectively preventing various security attacks. When processing plugin opening requests, the proxy daemon performs strict permission checks, ensuring only authorized diagnostic processes can access the corresponding heterogeneous plugins. Permission checks can be based on process user ID, group ID, process ID, or other attributes, ensuring only legitimate processes can access sensitive diagnostic data. The system also records all diagnostic data access operations, generating detailed audit logs for subsequent security auditing and problem investigation. Audit logs contain information such as the accessed plugin identifier, access time, process identifier, user identifier, and operation result, which can help administrators track and analyze security incidents.

[0070] In this embodiment, when using the Seccomp user notification mechanism alone to achieve unified management of heterogeneous plugins, all diagnostic data acquisition operations need to be processed by the proxy daemon. For each read operation, the proxy daemon needs to obtain data from the heterogeneous plugin backend and then write the data to the target diagnostic process's user buffer through inter-process memory copying. Although this method can achieve transparent proxy and unified management of heterogeneous plugins, each read operation involves two context switches and two data copies, resulting in significant performance overhead. This performance overhead is particularly pronounced in monitoring scenarios that require frequent collection of diagnostic data, potentially impacting the real-time performance of diagnostic tools and the overall system performance. When using a kernel-mode program alone to achieve unified management of heterogeneous plugins, although data reading and injection can be completed in kernel mode, avoiding data copying between user mode and kernel mode, the kernel-mode program cannot directly initiate network requests or block and wait for external events to complete. When the required diagnostic data is not in the cache, the kernel-mode program cannot obtain data from the heterogeneous plugin backend and can only return an error or allow the system call to continue executing the original kernel processing logic. This makes it impossible to achieve complete unified management of heterogeneous plugins using kernel-mode programs alone; they can only serve as an auxiliary means to accelerate certain specific operations. Combining the Seccomp user notification mechanism, the proxy daemon, and the kernel-mode program can fully leverage the advantages of each while avoiding their respective shortcomings. The Seccomp user notification mechanism is responsible for intercepting all system calls for obtaining diagnostic data and delegating operations that require blocking and waiting for external events to the proxy daemon. As a user-mode process, the proxy daemon can easily initiate network requests, communicate with various heterogeneous plugin backends, and handle complex adaptation and business logic. The kernel-mode program is responsible for performing data injection operations at the system call exit point, directly writing cached diagnostic data into the target diagnostic process's user buffer, avoiding the performance overhead of copying user-mode data. The three communicate and synchronize efficiently through a BPF Map, forming a complete and high-performance unified management solution for heterogeneous plugins. The Seccomp user notification mechanism and the kernel-mode program play roles at different stages of the system call, forming a seamless processing flow. The Seccomp filter intercepts the call at the entry stage of the system call and hands control over to the proxy daemon. After completing decision-making and necessary external interactions in user space, the proxy daemon passes the return value to the kernel via the Seccomp notification mechanism and transmits data injection instructions to the kernel-mode program through the BPF Map. The kernel-mode program performs the data injection operation at the exit stage of the system call, completing the entire diagnostic data acquisition process. This processing flow fully utilizes the lifecycle of the system call, scheduling the most appropriate components to execute corresponding tasks at different stages, thereby optimizing the performance and functionality of the entire system.By introducing a caching mechanism, frequently accessed hot diagnostic data is stored in a kernel-level BPF Map, allowing most diagnostic data retrieval operations to hit the cache and follow the fast processing path. In this fast processing path, the agent daemon only needs to perform simple cache lookups and tag writes, without requiring network access or data copying. The kernel-level program then performs the data injection operation in kernel space, involving only one data copy in the entire process. This design improves the read performance of the hot path, approaching the read performance of a local file system. While cold data read operations still require a slower processing path, the lower access frequency of cold data minimizes the impact on overall system performance.

[0071] In this embodiment, the system can automatically adjust the cached content based on the access and update frequency of diagnostic data. The agent daemon can periodically clean up expired and infrequently accessed cached data based on the access time, access frequency, and data generation time, making room for new, frequently accessed data. This adaptive cache management mechanism ensures that the cache always stores the most frequently used diagnostic data, improving the cache hit rate and further enhancing the overall system performance. Simultaneously, the system supports dynamic configuration of caching strategies. Administrators can configure independent caching strategies for each plugin based on its characteristics and application scenarios, such as cache size, expiration time, and eviction policies, to achieve optimal caching results.

[0072] As can be seen from the above embodiments, this application identifies the inherent characteristic of cold and hot path differentiation in diagnostic data acquisition, and utilizes this characteristic to accurately relay the blocking slow path capability of Seccomp user notification and the non-blocking fast path capability of eBPF within the lifecycle of the system call through a lightweight data direct write-to-mark protocol. Specifically, the agent daemon makes complex decisions at the Seccomp hang point. If a cache hit occurs, it does not perform a regular user-space data copy, but only writes a mark carrying length and position information to the BPF Map. This is a very simple instruction transmission. Subsequently, at the newly introduced execution point of the system call exit, the eBPF program directly completes data injection in kernel mode based on this mark, completely bypassing the context switching and memory copying of the agent process. This application breaks through the inherent limitation of eBPF programs being unable to undertake complete proxy functions due to their non-blocking nature. At the same time, it solves the problem that user-space proxies become the bottleneck for data transfer in pure Seccomp user notification schemes. It decouples a complete proxy operation into control plane decision-making at the entry point and data plane injection at the exit point. The two coordinate asynchronously through a lock-free shared state constructed by BPF Map. Thus, under the strict constraints of not needing to intrude into the target process or modify the diagnostic tool code, it achieves unified management of heterogeneous plugins with performance comparable to local calls.

[0073] like Figure 6 As shown in the embodiments of this application, a unified management system for system diagnostic tools that adapt to heterogeneous plug-ins is also provided, including: The Seccomp filter configuration module is used to apply a Seccomp filter to the target diagnostic process of the system diagnostic tool, so that the system call initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin is suspended and a Seccomp user notification is generated. The system call carries the plugin identifier. The proxy daemon configuration module is used to receive the Seccomp user notification and obtain the plugin identifier and operation parameters. When it is determined that the cached diagnostic data is hit, it writes a data write-through flag to the BPF Map and returns the length through the Seccomp notification. When it is not hit, it selects the corresponding plugin backend adaptation logic according to the plugin identifier, obtains the diagnostic data, and writes it into the user buffer of the target diagnostic process through inter-process memory copy before returning. The eBPF program configuration module is mounted at the system call exit point. It is used to detect the data write-through flag in the BPF Map, and when the data write-through flag exists, retrieve diagnostic data from the data cache of the BPF Map, write it to the user buffer, and modify the return value register.

[0074] Those skilled in the art will understand that the embodiments of this application are not limited to the specific examples described above. Without departing from the spirit and scope of this application, those skilled in the art can make various modifications and variations to the technical solutions of this application. For example, the technical solutions of this application can be applied to other types of software authentication scenarios, or equivalent substitutions can be made to the technical features of this application. These modifications and variations should all fall within the protection scope of this application. Further details are omitted here.< / pid>

Claims

1. A system diagnostic tool uniform management method for heterogeneous plug-in adaptation, characterized by, include: Configure a Seccomp filter on the target diagnostic process of the system diagnostic tool to suspend system calls initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin and generate a Seccomp user notification, wherein the system call carries a plugin identifier. A proxy daemon running outside the target diagnostic process receives the Seccomp user notification, obtains the plugin identifier and operation parameters from the system call, queries the BPF Map to see if there is corresponding cached diagnostic data based on the plugin identifier and operation parameters, writes a data write flag containing the data length to the BPF Map, and returns the data length through the Seccomp user notification mechanism, and if there is no cached diagnostic data, selects the corresponding plugin backend adaptation logic based on the plugin identifier to obtain the diagnostic data, writes it to the user buffer specified by the system call through an inter-process memory copy operation, and returns the actual read length through the Seccomp user notification mechanism. The data write flag is used to instruct the eBPF program to perform direct writing to the user buffer. At the exit of the system call, the eBPF program checks whether the data write-through flag exists in the BPF Map. If it does, it reads the corresponding diagnostic data from the data cache of the BPF Map and writes it into the user buffer, and modifies the return value register to the data length in the data write-through flag.

2. The method according to claim 1, characterized in that, The proxy daemon receives the Seccomp user notification and obtains the plugin identifier and operation parameters from the system call, including: The plugin identifier and operation parameters are extracted from the parameter information carried by the Seccomp user notification. The plugin identifier represents the heterogeneous plugin called by the target diagnostic process.

3. The method according to claim 1, characterized in that, The step of querying the BPF Map for corresponding cached diagnostic data based on the plugin identifier and operation parameters includes: Using the plugin identifier and operation parameters as query keys, retrieve matching cached diagnostic data entries in the data cache area of ​​the BPF Map.

4. The method according to claim 1, characterized in that, When cached diagnostic data exists, writing a data write-through flag containing the data length to the BPFMap and returning the data length through the Seccomp user notification mechanism includes: Construct a direct-write tag carrying the data length and cache location information, and write it into the task area to be injected in the BPF Map; The Seccomp notification interface is invoked to send the data length to the kernel, thereby triggering the system call to return with the data length.

5. The method according to claim 1, characterized in that, When no cached diagnostic data exists, the process involves selecting the corresponding plugin backend adaptation logic based on the plugin identifier to obtain the diagnostic data, writing it to the user buffer specified by the system call via an inter-process memory copy operation, and then returning the actual read length through the Seccomp user notification mechanism. This includes: The proxy daemon process determines the corresponding adaptation logic based on the plugin identifier and obtains diagnostic data blocks from the plugin backend. The diagnostic data block is written to the user buffer by calling the inter-process memory copy function. The length of the diagnostic data block is returned to the kernel via the Seccomp notification mechanism.

6. The method according to claim 5, characterized in that, After returning the length of the diagnostic data block to the kernel via the Seccomp notification mechanism, the following is also included: The proxy daemon writes the diagnostic data block and its corresponding plugin identifier and operation parameters into the data cache of the BPFMap, which serves as the cached diagnostic data for subsequent diagnostic data acquisition operations.

7. The method according to claim 1, characterized in that, At the exit of the system call, the eBPF program checks whether the data write-through flag exists in the BPF Map. If it does, the corresponding diagnostic data is read from the data cache of the BPF Map and written to the user buffer, including: When the eBPF program executes at the sys_exit trace point corresponding to the system call, it uses the current process identifier and the parameters of the system call as the search criteria to match the data write-through marker in the BPF Map to be injected task area; Upon successful matching, the bpf_probe_write_user function is called to write the corresponding cached diagnostic data from kernel space to the user buffer.

8. The method according to claim 1, characterized in that, Also includes: When the target diagnostic process initiates a plugin opening system call, the Seccomp filter suspends the plugin opening system call and generates an opening user notification, the plugin opening system call carrying the plugin identifier; The proxy daemon receives the open user notification, allocates an operation handle according to the plugin identifier, and returns the allocated operation handle to the target diagnostic process through the Seccomp user notification mechanism, so that the target diagnostic process can use the operation handle in subsequent diagnostic data acquisition operations. The value of the operation handle is within a preset range.

9. The method according to claim 8, characterized in that, The minimum value of the preset range is greater than the default handle range allocated by the operating system kernel for local resources, so that the eBPF program can identify the operation handle to be proxied through numerical comparison.

10. A unified management system for system diagnostic tools that adapt to heterogeneous plug-ins, characterized in that, include: The Seccomp filter configuration module is used to apply a Seccomp filter to the target diagnostic process of the system diagnostic tool, so that the system call initiated by the target diagnostic process to obtain diagnostic data of a specified heterogeneous plugin is suspended and a Seccomp user notification is generated. The system call carries the plugin identifier. The proxy daemon configuration module is used to receive the Seccomp user notification and obtain the plugin identifier and operation parameters. When it is determined that the cached diagnostic data is hit, it writes a data write-through flag to the BPF Map and returns the length through the Seccomp notification. When it is not hit, it selects the corresponding plugin backend adaptation logic according to the plugin identifier, obtains the diagnostic data, and writes it into the user buffer of the target diagnostic process through inter-process memory copy before returning. The eBPF program configuration module is mounted at the system call exit point. It is used to detect the data write-through flag in the BPF Map, and when the data write-through flag exists, retrieve diagnostic data from the data cache of the BPF Map, write it to the user buffer, and modify the return value register.

Images