Process state monitoring method and device based on kernel instrumentation, equipment and medium

Abstract

The invention discloses a process state monitoring method, device and equipment based on kernel instrumentation and a medium, and relates to the technical field of process state monitoring, and the method comprises the following steps: analyzing a command line parameter input by a user to obtain a to-be-monitored process number, and writing the to-be-monitored process number into an eBPF map; adding and loading a registration process probe in a kernel; and registering an annular buffer area through a user mode program, transmitting an eBPF map to read process change information in the annular buffer area, analyzing the process change information by using a callback function to generate a process monitoring log, and giving an alarm. A probe is arranged in a kernel instrumentation through an eBPF to obtain a jump point of a process state and collect process change information, then low-delay data collection is achieved through an annular buffer area, process state changes can be responded in real time with microsecond-level precision, the method can be used for a high-frequency and real-time monitoring environment, the key state jump point causing process abnormity is accurately positioned, and the stability of the system is improved. And the kernel module does not need to be recompiled and loaded, so that the process monitoring stability and reliability are improved.

Description

Technical Field

[0001] This invention relates to the field of process status monitoring technology, and in particular to a process status monitoring method, apparatus, device and medium based on kernel instrumentation. Background Technology

[0002] A process is the basic unit of resource allocation and scheduling in a Linux system. It forms the foundation of the Linux operating system architecture and is characterized by dynamism, independence, and concurrency. To ensure the stable operation of the Linux operating system, promptly detect potential faults, and optimize resource scheduling and utilization, monitoring process status can quickly identify process anomalies such as unresponsiveness and memory leaks, preventing service crashes or response delays. It can also identify malware, unauthorized resource access, and other abnormal behaviors early, ensuring Linux system security, and tracing the root cause of program crashes or response anomalies, shortening problem localization time.

[0003] Monitoring process status can be achieved using polling-based user-space tools, which periodically execute commands like `ps` and `top` to obtain the running status of current Linux system processes. Alternatively, a user-defined kernel module approach can be used, where a custom kernel module is written, compiled, loaded, and run, with kernel logs recording process state changes. Dynamic tracing tools such as SystemTap can also be employed, converting SystemTap scripts into C code, compiling them into kernel modules, loading and running them, and collecting data via probes and transmitting it to user space. However, polling mechanisms incur high system overhead, custom kernel modules require recompiling the kernel or loading kernel objects, potentially leading to kernel crashes and systemic risks, and can also cause API compatibility issues between different versions. Dynamic tracing tools rely on context capture and logging, which can result in significant latency and performance degradation. Especially when faced with instantaneous changes in process state, it is difficult to accurately capture these changes in real time, making it challenging to locate and trace process failures. Summary of the Invention

[0004] This invention provides a process state monitoring method, apparatus, device, and medium based on kernel instrumentation to solve the technical problem of being unable to accurately capture instantaneous changes in process state in real time.

[0005] In a first aspect, embodiments of the present invention provide a process state monitoring method based on kernel instrumentation, comprising:

[0006] S101 parses the command-line parameters input by the user through the eBPF user-space program, obtains the process ID to be monitored, and writes the process ID to be monitored into the eBPF map.

[0007] S102, process probes are added and registered in the kernel through the eBPF kernel-mode program. The process probes are used to monitor the state changes of the process to be monitored. When the process probe is triggered, it can obtain process change information and write it into the eBPFmap.

[0008] S103 loads the eBPF kernel-mode program in the kernel through the eBPF user-mode program, and loads the process probe;

[0009] S104: Register a circular buffer and pass the eBPF map parameter through the eBPF user-space program, poll and read the process change information in the eBPF map, and parse the read process change information through a callback function to generate a process monitoring log. Based on the process monitoring log, issue an alarm for processes in abnormal states.

[0010] Furthermore, S102 includes:

[0011] eBPF kernel-mode programs configure process switching probes, process exit probes, process suspension probes, and process wait probes through hook functions to monitor the state changes of the process to be monitored.

[0012] When the state of the process to be monitored changes, the corresponding probe is triggered. The probe obtains the process change information and writes it into the eBPF map. The eBPF map uses the process ID to be monitored as the key and the process change information corresponding to the process ID to be monitored as the value. The process change information includes the process's state identifier, state transition timestamp, and state transition process resource information.

[0013] Furthermore, S103 includes:

[0014] eBPF user-space programs load eBPF kernel-space programs in the kernel using the _bpf_open_and_load() function, and load process probes in the kernel using the _bpf_attach() function.

[0015] Furthermore, S104 includes:

[0016] eBPF user-space programs register a ring buffer using the ring_buffer_new() function and pass the eBPF map as an argument to poll and read process change information from the eBPF map to fill it.

[0017] When the process probe is triggered, the eBPF program executes synchronously in the kernel context, writing process change information directly into the ring buffer. At this time, the kernel will notify the eBPF user-space program that is waiting for data in the ring buffer. The eBPF user-space program is woken up through the epoll or poll mechanism, and uses the callback function to read and parse the process change information in the ring buffer, generating process status timing information, process resource usage information, and process abnormal status information.

[0018] Based on process status timing information, process resource usage information, and process abnormal status information, process monitoring logs are generated, and alerts are issued for processes in abnormal states based on the process monitoring logs.

[0019] Furthermore, the step of using a callback function to parse the read process change information and generate process state timing information, process resource usage information, and process abnormal state information includes:

[0020] The callback function calculates the difference between two adjacent timestamps based on the timestamps of process state transitions, counts the duration of the process in each state, and generates process state timing information.

[0021] The callback function generates process resource usage information based on the process's memory usage and CPU usage in different states;

[0022] The callback function generates process exception status information based on the exit code when the process exits abnormally and the states of its parent and child processes.

[0023] Furthermore, the method also includes:

[0024] Once the callback function has finished parsing the process change information, the eBPF user-mode program enters a sleep state. If no process change information has ever been generated, the eBPF user-mode program will always remain in a sleep state.

[0025] Furthermore, the method also includes:

[0026] The eBPF kernel-mode program and the eBPF user-mode program are encapsulated, and a command-line interface is provided for users to call to monitor the status of a specified process.

[0027] Secondly, embodiments of the present invention provide a process state monitoring device based on kernel instrumentation, comprising:

[0028] The process to be monitored module is used to parse the command line parameters input by the user through the eBPF user-space program, obtain the process ID to be monitored, and write the process ID to be monitored into the eBPF map.

[0029] The probe registration module is used to add and register process probes in the kernel via eBPF kernel-mode programs;

[0030] The probe loading module is used to load the eBPF kernel-mode program into the kernel via the eBPF user-mode program, and to load the process probe.

[0031] The change information parsing module is used to register a circular buffer and pass parameters to the eBPF map through the eBPF user-space program. At the same time, it parses the read process change information through a callback function, generates process monitoring logs, and issues alarms for processes in abnormal states based on the process monitoring logs.

[0032] Thirdly, embodiments of the present invention provide an electronic device, including:

[0033] One or more processors;

[0034] Storage device for storing one or more programs.

[0035] When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described kernel instrumentation-based process state monitoring method.

[0036] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the aforementioned kernel-instrument-based process state monitoring method.

[0037] This invention provides a process state monitoring method, apparatus, device, and medium based on kernel instrumentation. The method obtains the process ID to be monitored by parsing user-input command-line parameters and writes it into an eBPF map. A process probe for monitoring process state changes is set up in the Linux kernel. After the eBPF user-space program guides the eBPF kernel-space loading, the process probe is loaded, allowing process state information to be obtained when the process state changes. This enables monitoring and information collection of different process states, forming process change information, which is then written into the eBPF map. The eBPF user-space program reads the process change information by registering a circular buffer and passing parameters to the eBPF map. The program then parses the read process change information through a callback function, generates a process monitoring log, and alerts processes in abnormal states. By introducing eBPF technology, the traditional "polling sampling" mode is transformed into an "event-triggered" mode. eBPF instrumentation in the Linux kernel sets probes to obtain process state transition points and collect process change information. Then, a circular buffer is used to achieve low-latency data acquisition, which can respond to process state changes in real time with microsecond precision. This avoids the performance loss caused by frequent context switching and data copying between user space and kernel space in traditional monitoring tools (such as ps, top, etc.), as well as the problem of missing short-lifecycle processes due to polling intervals. It can be used in high-frequency, real-time monitoring environments, accurately locates key state transition points that cause process abnormalities, and pre-filters irrelevant events, reporting only critical information. It has high real-time performance, security, and reliability. It does not require recompiling and loading kernel modules, avoiding the possibility of system kernel crashes due to monitoring program defects, and greatly improving the stability and reliability of process monitoring. Attached Figure Description

[0038] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0039] Figure 1 This is a flowchart of a process status monitoring method based on kernel instrumentation as described in Embodiment 1 of the present invention;

[0040] Figure 2 This is a flowchart of a process status monitoring method based on kernel instrumentation as described in Embodiment 2 of the present invention;

[0041] Figure 3 The flowchart is a process status monitoring method based on kernel instrumentation as described in Embodiment 3 of the present invention;

[0042] Figure 4 This is a schematic diagram of the structure of a process status monitoring device based on kernel instrumentation as described in Embodiment 4 of the present invention;

[0043] Figure 5 This is a structural diagram of the electronic device described in Embodiment 5 of the present invention. Detailed Implementation

[0044] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0045] Example 1

[0046] Figure 1 The process state monitoring method based on kernel instrumentation described in Embodiment 1 of this invention involves setting up process probes in the kernel using a dBPF kernel-mode program to obtain process state change information. An eBPF user-mode program then parses the read process change information through callback functions, generates process monitoring logs, and issues alerts for processes in abnormal states. The specific steps include:

[0047] S101 parses the command-line parameters input by the user through the eBPF user-space program, obtains the process ID to be monitored, and writes the process ID to be monitored into the eBPF map.

[0048] eBPF (extended Berkeley Packet Filter) enables the secure and efficient execution of custom programs within the kernel without modifying the Linux kernel source code or compiling and loading traditional kernel modules. After starting and initializing the user-space monitoring program (i.e., the eBPF user-space program), the eBPF user-space program uses the CLI11 library to parse the command-line arguments input from user space, obtaining the process to be monitored and its process ID from the user input command, and identifying it as the process ID to be monitored. The process ID to be monitored is then written to the eBPF map, which is a key-value table storing process states. The process ID to be monitored is the key, and the process state and state changes are the corresponding values. By reading this key-value table and parsing its contents, the process state changes can be determined.

[0049] S102, process probes are added and registered in the kernel through the eBPF kernel-mode program. The process probes are used to monitor the state changes of the process to be monitored. When the process probes are triggered, they can obtain process change information and write it into the eBPFmap.

[0050] By using eBPF kernel-mode programs, probe points are set in the kernel. These probe points are located at the entry points of kernel functions related to process state, i.e., instrumentation. Once the kernel code is detected to have entered the instrumented function, the corresponding probe is triggered. At this time, the current timestamp is recorded, and changes in process state, such as resource usage, are captured. These process change information is recorded as values ​​in the eBPF map.

[0051] S103 loads the eBPF kernel-mode program in the kernel via the eBPF user-mode program, and loads the process probe.

[0052] eBPF user-mode programs load eBPF kernel-mode programs into the kernel by calling functions. Then, process probes are loaded into the kernel accordingly, and the process probes are attached to the corresponding kernel probe points. When the process state changes, the process probes are triggered to collect the corresponding process change data.

[0053] S104: Register a circular buffer and pass the eBPF map parameter through the eBPF user-space program, poll and read the process change information in the eBPF map, and parse the read process change information through a callback function to generate a process monitoring log. Based on the process monitoring log, issue an alarm for processes in abnormal states.

[0054] User space registers a circular buffer through the eBPF user-space program and passes the eBPF map as a parameter to the circular buffer. This allows the program to enter a polling loop, asynchronously and with low latency reading process change information from the eBPF map through the circular buffer. A callback function is specified to parse each piece of process change information. The program analyzes the process state identifier, timestamp, and other information in the process change information to understand the process state changes, the duration of different states, process resource usage during state changes, and the states of parent and child processes. This information is used to generate process monitoring logs. The logs can be used to identify abnormal process states and issue corresponding alarms for different abnormal states (such as abnormal process exit or resource overruns), allowing users to monitor process status and take timely warnings or appropriate actions.

[0055] This embodiment obtains the process ID to be monitored by parsing the command-line parameters input by the user and writes them into the eBPF map. A process probe is set up in the Linux kernel to monitor process state changes. After the eBPF user-space program boots the eBPF kernel mode, it loads the process probe, which can obtain process state information when the process state changes. Then, it can monitor and collect information on different process states, form process change information, and write it into the eBPF map. The eBPF user-space program reads the process change information by registering a circular buffer and passing parameters to the eBPF map. It then parses the read process change information through a callback function, generates process monitoring logs, and alerts processes in abnormal states. By introducing eBPF technology, the traditional "polling sampling" mode is transformed into an "event-triggered" mode. eBPF instrumentation in the Linux kernel sets probes to obtain process state transition points and collect process change information. Then, a circular buffer is used to achieve low-latency data acquisition, which can respond to process state changes in real time with microsecond precision. This avoids the performance loss caused by frequent context switching and data copying between user space and kernel space in traditional monitoring tools (such as ps, top, etc.), as well as the problem of missing short-lifecycle processes due to polling intervals. It can be used in high-frequency, real-time monitoring environments, accurately locates key state transition points that cause process abnormalities, and pre-filters irrelevant events, reporting only critical information. It has high real-time performance, security, and reliability. It does not require recompiling and loading kernel modules, avoiding the possibility of system kernel crashes due to monitoring program defects, and greatly improving the stability and reliability of process monitoring.

[0056] Optionally, the method further includes: encapsulating the eBPF kernel-mode program and the eBPF user-mode program, and providing a command-line interface for users to call to monitor the status of a specified process.

[0057] The eBPF kernel-mode program and the eBPF user-mode program are encapsulated together into a standalone command-line tool, such as ". / ky_bpf_process_state_monitor", used to monitor the status of all system processes and print monitoring logs to the terminal; or ". / ky_bpf_process_state_monitor -p xxx –o log_path", used to monitor a process with a specified process ID and its parent and child processes (-p parameter), and save the monitoring logs to the specified directory log_path (-o parameter). This command-line tool provides users with a corresponding command-line interface through which they can input command-line parameters for process status monitoring, invoke the eBPF kernel-mode program and the eBPF user-mode program to dynamically monitor the specified processes in real time, automatically generate monitoring logs, and issue alarms based on the abnormal status of the monitored processes. The monitoring logs can also be dynamically output to the monitoring terminal or a specified log file for monitoring the corresponding programs and system status or for record keeping. By packaging it as a ready-to-use command-line tool, users do not need to worry about the complex kernel compilation and module loading process. They can perform in-depth monitoring of specific processes with simple command-line parameters, which greatly reduces the complexity of operation and maintenance and the threshold for use, and improves the agility and convenience of deployment.

[0058] Example 2

[0059] Figure 2 This is a flowchart of a process state monitoring method based on kernel instrumentation as described in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S104 is specifically optimized as follows:

[0060] eBPF user-space programs register a ring buffer using the ring_buffer_new() function and pass the eBPF map as an argument to poll and read process change information from the eBPF map to fill it.

[0061] When the process probe is triggered, the eBPF program executes synchronously in the kernel context, writing process change information directly into the ring buffer. At this time, the kernel will notify the eBPF user-space program that is waiting for data in the ring buffer. The eBPF user-space program is woken up through the epoll or poll mechanism, and uses the callback function to read and parse the process change information in the ring buffer, generating process status timing information, process resource usage information, and process abnormal status information.

[0062] Based on process status timing information, process resource usage information, and process abnormal status information, process monitoring logs are generated, and alerts are issued for processes in abnormal states based on the process monitoring logs.

[0063] Accordingly, the process state monitoring method based on kernel instrumentation provided in this embodiment specifically includes:

[0064] S201 parses the command-line parameters input by the user through the eBPF user-space program, obtains the process ID to be monitored, and writes the process ID to be monitored into the eBPF map.

[0065] S202, process probes are added and registered in the kernel through the eBPF kernel-mode program. The process probes are used to monitor the state changes of the process to be monitored. When the process probe is triggered, it can obtain process change information and write it into the eBPFmap.

[0066] S203 loads the eBPF kernel-mode program into the kernel via the eBPF user-mode program, and loads the process probe.

[0067] S204, the eBPF user-space program registers a ring buffer through the ring_buffer_new() function and passes the parameter eBPFmap to poll and read process change information in the eBPF map to fill it.

[0068] eBPF user-space programs initialize the ring buffer manager by calling the `ring_buffer_new()` API function, passing the eBPF map and a pointer to the `handle_event()` callback function used for data parsing as parameters. The user reads process change information from the eBPF map and uses the callback function to parse the information to obtain the process state changes. After initialization, the ring buffer manager internally calls the `epoll_wait()` function to put the current user-space program into a sleep state, reducing CPU resource consumption.

[0069] S205. When the process probe is triggered, the eBPF program executes synchronously in the kernel context, writing process change information directly into the ring buffer. At this time, the kernel will notify the eBPF user-space program that is waiting for data in the ring buffer. The eBPF user-space program is woken up through the epoll or poll mechanism, and uses the callback function to read and parse the process change information in the ring buffer, generating process state timing information, process resource usage information, and process abnormal state information.

[0070] When a process probe in the kernel is triggered, the eBPF kernel-mode program writes the captured process change information to the eBPF Map and then submits the event to the ring buffer (ringbuffer) via mechanisms such as ring_buffer_submit(). Simultaneously, a kernel notification event is generated, waking up the user-mode program that is sleeping on epoll_wait(). After the user-mode program is awakened, the ring_buffer_poll() function begins working, reading newly arrived data packets from the ring buffer according to the kernel notification. For each read data packet, the previously registered callback function handle_event() is automatically called for processing. For example, the eBPF kernel-mode program acts as the data producer, and the eBPF user-mode program acts as the data consumer. When the monitored process is detected to enter the hang state at time t1, a probe is triggered to simultaneously obtain resource information and timestamps from the process structure and write them to the eBPF map. Subsequently, when the monitored process is detected to enter the running state at time t2, a probe is also triggered to obtain resource information and timestamps from the process structure and write them to the eBPF map. The user-mode program reads the eBPF map repeatedly to count the transition times of the process states and calculates the duration of the process in the hang state (t2-t1). In this way, the user-mode program can count the duration of each process state, the transition times, and the process resource information at each transition time. This allows it to issue alerts for abnormal process states such as hang states and abnormal exits, and generate resource usage reports and process monitoring logs.

[0071] Specifically, the callback function is used to parse the read process change information, including:

[0072] The callback function calculates the difference between two adjacent timestamps based on the timestamps of process state transitions, counts the duration of the process in each state, and generates process state timing information.

[0073] The callback function handle_event() extracts the process state identifier and the timestamp of the state transition from the data packet. It compares the current process state identifier with the previously recorded process state identifier. If there is a change, it calculates the difference between the two timestamps to determine the duration of the process in the previous state and generates process state timing information, which can be in the form of a timing diagram.

[0074] The callback function generates process resource usage information based on the process's memory usage and CPU usage in different states.

[0075] The callback function handle_event() extracts process resource information recorded in the data packet, including the CPU utilization and memory usage of the process in different states, and generates process resource usage information.

[0076] The callback function generates process exception status information based on the exit code when the process exits abnormally and the states of its parent and child processes.

[0077] The callback function handle_event() can also handle specific abnormal states. For example, when a process exits abnormally, it can record its exit code and obtain the status of its parent and child processes, which can be used to diagnose zombie processes or orphan processes. When a process is found to be in the D state for a long time, it can be combined with process resource information for fault diagnosis and alarm.

[0078] In one optional implementation of this embodiment, after the callback function has finished parsing the process change information, the eBPF user-mode program enters a sleep state. If no process change information has ever been generated, the eBPF user-mode program will always remain in a sleep state.

[0079] To reduce system resource overhead, when there is no readable data in the ring buffer (i.e., no new probe trigger events or new process change information), `ring_buffer_poll()` will call `epoll_wait()` again after the callback function finishes executing, causing the user-mode program to re-enter a sleep state and wait for the next kernel event notification, thus forming an efficient event-driven processing loop. If no probe trigger events or process change information occur from the beginning, the ring buffer will remain in a sleep state after initialization and the `epoll_wait()` function is called to put the user-mode program to sleep, and will never wake the user-mode program up.

[0080] S206. Generate process monitoring logs based on process status timing information, process resource usage information, and process abnormal status information, and issue alerts for processes in abnormal states based on the process monitoring logs.

[0081] After parsing the process change information, the callback function generates process state timing information, process resource usage information, and process abnormal state information. This information is then organized into a structured monitoring log. Based on the content of the monitoring log, an alarm can be triggered according to preset alarm rules (such as abnormal exit / non-zero exit code, CPU / memory usage consistently exceeding 80%). For example, the alarm rules primarily involve triggering an alarm when the process state is abnormal. Abnormal states include: abnormal process exit (exit code non-zero), zombie process, orphan process (when a process exits abnormally, its child processes may become zombie or orphan processes), process entering hang state (uninterruptible D state), process paused T state, etc.; an abnormal spike in process context switching count, possibly due to insufficient memory, frequent I / O operations, etc.; and abnormal process resource usage, such as a spike in CPU and memory usage, for example, process memory usage exceeding 80% of system memory, or a continuously increasing process memory usage.

[0082] This embodiment combines a circular buffer with callback functions, ensuring that eBPF user-space programs are only awakened and processed when process change information arrives. Process state change events directly reach the wake-up buffer, with a state transition detection time of <1ms. This allows for the capture of short-lived processes with a lifespan of <1ms, while avoiding unnecessary CPU polling. In most cases where no monitoring events occur, it consumes almost no computing resources, minimizing performance overhead. All probes are automatically unloaded upon program exit, and no external kernel modules are required. The callback function timestamps the state transitions. The difference calculation can accurately measure the duration of a process in each state (such as suspended or sleeping), providing key quantitative indicators for performance bottleneck diagnosis (such as I / O blocking, excessively long sleep, etc.), achieving fine-grained process status monitoring and reducing alarm latency to <1ms. By synchronously parsing the process exit code, parent and child process states, and resource snapshots in the same callback function, the causal relationship between process anomalies and system context can be directly constructed. It can immediately detect whether the abnormal exit of a process (exit code non-zero) has caused its child processes to become zombie processes, greatly improving the fault diagnosis and localization capabilities.

[0083] Example 3

[0084] Figure 3 This is a flowchart of a process state monitoring method based on kernel instrumentation as described in Embodiment 3 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S102 is specifically optimized as follows:

[0085] eBPF kernel-mode programs configure process switching probes, process exit probes, process suspension probes, and process wait probes through hook functions to monitor the state changes of the process to be monitored.

[0086] When the state of the process to be monitored changes, the corresponding probe is triggered. The probe obtains the process change information and writes it into the eBPF map. The eBPF map uses the process ID to be monitored as the key and the process change information corresponding to the process ID to be monitored as the value. The process change information includes the process's state identifier, state transition timestamp, and state transition process resource information.

[0087] Accordingly, the process state monitoring method based on kernel instrumentation provided in this embodiment specifically includes:

[0088] S301 parses the command-line parameters input by the user through the eBPF user-space program, obtains the process ID to be monitored, and writes the process ID to be monitored into the eBPF map.

[0089] S302, the eBPF kernel-mode program configures process switching probes, process exit probes, process suspension probes, and process wait probes through hook functions to monitor the state changes of the process to be monitored.

[0090] eBPF kernel-mode programs can use three types of hooks—kprobe, tracepoint, and raw_tracepoint—to capture process state change events and process resource usage. Specifically, four types of probes can be configured: sched_switch (process switching probe), sched_process_exit (process exit probe), sched_process_hang (process suspension probe), and sched_process_wait (process wait probe). These probes track different process states and obtain information such as process status and resources. For example, the tp / sched / sched_switch probe can be configured to monitor process switching events; the tp / sched / sched_process_exit probe can be configured to monitor process exit events; the tracepoint / sched / sched_process_hang probe can be configured to monitor process suspension events; and the raw_tracepoint / sched / sched_process_wait probe can be configured to monitor process wait events. Probes (instruments) are placed at the entry points of kernel functions related to process states. They can capture when the kernel enters a specific state function at a certain moment. Once the kernel code is detected to have entered the instrumented function, the probe and the eBPF kernel-mode program are triggered, recording information such as timestamps and process resource usage. For example, when a process exits, it will always enter the `exit` kernel function. Therefore, a probe is added at the `exit` function. Once the kernel code enters this function, it will trigger the probe and collect data, writing it to the eBPF map. The user-mode program can loop and wait for probe trigger events. Once a probe trigger event occurs, it reads the structure data of the eBPF map through the ring buffer `ring_buffer` for parsing.

[0091] S303, when the state of the process to be monitored changes, the corresponding probe is triggered. The probe obtains the process change information and writes it into the eBPF map. The eBPF map uses the process ID to be monitored as the key and the process change information corresponding to the process ID to be monitored as the value. The process change information includes the process's state identifier, state transition timestamp, and state transition process resource information.

[0092] When the state of a monitored process changes, a corresponding probe is triggered, capturing process change information while recording a timestamp. This captured information is stored in real-time using an eBPF map, which is a key-value table. The key is the process ID (PID), and the value is the corresponding process change information, including the process ID (PID), state identifier (running / sleeping / suspended / exited, etc.), timestamp of the state change, and snapshots of the process's CPU and memory resources at that moment (process resource information during the state change). If two consecutive state events captured by the probe are different, meaning the kernel code enters different kernel state functions, this can be identified by comparing the process's state identifier, indicating a state change. For example, if the first probe trigger occurs when the kernel enters the `hang` state function, and the second probe trigger occurs when the kernel enters the `running` state function, it indicates a state change from `hang` to `running`. Different kernel state function probe triggers write the corresponding process state identifiers into the eBPF map, allowing user-space programs to compare these identifiers to determine if a state change has occurred.

[0093] S304 loads the eBPF kernel-mode program in the kernel via the eBPF user-mode program, and loads the process probe.

[0094] Specifically, the eBPF user-space program loads the eBPF kernel-space program in the kernel through the _bpf_open_and_load() function, and loads the process probe in the kernel through the _bpf_attach() function.

[0095] In eBPF user-space programs, the `_bpf_open_and_load()` function loads the eBPF kernel-space program into the kernel. This is typically a pre-compiled eBPF object file (.o file) on disk. The kernel's eBPF verifier performs a rigorous security check on this program to ensure it does not compromise kernel stability. After the eBPF kernel-space program is successfully loaded, the user-space program iterates through each probe and calls the `_bpf_attach()` function to associate each probe with a corresponding probe point in the kernel. At this point, the process probes are officially activated and begin capturing state transition events of the monitored processes.

[0096] S305 registers a circular buffer and passes the eBPF map as a parameter through the eBPF user-space program. It then polls and reads the process change information in the eBPF map. At the same time, it parses the read process change information through a callback function, generates a process monitoring log, and issues an alert for processes in abnormal states based on the process monitoring log.

[0097] This embodiment uses predefined trace points in the Linux kernel as probe mounting points and hooks four types of scheduling events: switching, exiting, suspending, and waiting, to achieve full lifecycle monitoring of processes. This significantly reduces the missed detection rate of short-lived processes. Furthermore, calling the BPF function ensures that the entire kernel instrumentation process is under the strict security management of the operating system, guaranteeing system security. Simultaneously, by writing the process ID to be monitored into the eBPF map, event filtering is performed at the kernel level, capturing only state changes related to the monitored process. This achieves non-intrusive and accurate process monitoring, reducing unnecessary data copying and processing overhead compared to pushing all events to user space for filtering. Moreover, the non-dynamic hooking of kernel functions via kprobe effectively avoids function symbol changes or API incompatibility issues caused by kernel version iterations, improving overall efficiency and ensuring long-term stable operation of the monitoring program across different kernel versions.

[0098] Example 4

[0099] Figure 4 This is a schematic diagram of a kernel instrumentation-based process status monitoring device according to Embodiment 4 of the present invention. In this embodiment, the kernel instrumentation-based process status monitoring device includes:

[0100] The process to be monitored module 810 is used to parse the command line parameters input by the user through the eBPF user-space program, obtain the process ID to be monitored, and write the process ID to be monitored into the eBPF map.

[0101] The probe registration module 820 is used to add and register process probes in the kernel via eBPF kernel-mode programs.

[0102] The probe loading module 830 is used to load the eBPF kernel-mode program in the kernel through the eBPF user-mode program, and load the process probe;

[0103] The change information parsing module 840 is used to register a circular buffer and pass parameters to eBPFmap through the eBPF user-space program. At the same time, it parses the read process change information through a callback function, generates process monitoring logs, and issues alarms for processes in abnormal states based on the process monitoring logs.

[0104] In this embodiment, the process ID to be monitored is obtained by parsing the command line parameters input by the user through the process determination module and written into the eBPF map. The process probe is mounted in the kernel through the probe registration module and loaded in the kernel through the probe loading module. The process change information obtained when the probe is triggered is parsed by the change information parsing module to generate process monitoring logs and alarms for abnormal states. By introducing eBPF technology, the traditional "polling sampling" mode is transformed into an "event-triggered" mode. eBPF instrumentation in the Linux kernel sets probes to obtain process state transition points and collect process change information. Then, a circular buffer is used to achieve low-latency data acquisition, which can respond to process state changes in real time with microsecond precision. This avoids the performance loss caused by frequent context switching and data copying between user space and kernel space in traditional monitoring tools (such as ps, top, etc.), as well as the problem of missing short-lifecycle processes due to polling intervals. It can be used in high-frequency, real-time monitoring environments, accurately locates key state transition points that cause process abnormalities, and pre-filters irrelevant events, reporting only critical information. It has high real-time performance, security, and reliability. It does not require recompiling and loading kernel modules, avoiding the possibility of system kernel crashes due to monitoring program defects, and greatly improving the stability and reliability of process monitoring.

[0105] The kernel instrumentation-based process status monitoring device provided in this embodiment of the invention can execute the kernel instrumentation-based process status monitoring method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0106] Example 5

[0107] Figure 5 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 5 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 5 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0108] like Figure 5 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0109] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0110] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0111] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0112] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0113] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 5 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0114] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the kernel instrumentation-based process status monitoring method provided in the embodiments of the present invention.

[0115] Example 6

[0116] Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the kernel instrumentation-based process state monitoring method provided in the above embodiments.

[0117] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0118] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0119] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0120] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A kernel plug-in based process state monitoring method, characterized in that, Comprise: S101, the command line parameters input by the user are parsed through the eBPF user state program, the process number to be monitored is obtained, and the process number to be monitored is written into the eBPF map; S102, a process probe is added and registered in the kernel through the eBPF kernel state program, the process probe is used for monitoring the state change of the process to be monitored, and when the process probe is triggered, the process change information can be obtained and written into the eBPF map; S103, the eBPF kernel state program is loaded in the kernel through the eBPF user state program, and the process probe is loaded; S104, the ring buffer is registered and the eBPF map is parameterized through the eBPF user state program, the process change information in the eBPF map is polled and read, and the read process change information is parsed through a callback function to generate a process monitoring log, and the process in an abnormal state is alarmed according to the process monitoring log.

2. The method of claim 1, wherein, The S102 comprises: The eBPF kernel state program configures process switching probes (sched_switch), process exit probes (sched_process_exit), process hanging probes (sched_process_hang) and process waiting probes (sched_process_wait) through hook functions, which are used for monitoring the state change of the process to be monitored; When the process to be monitored changes state, the corresponding probe is triggered, the probe obtains process change information and writes it into the eBPF map, the eBPF map takes the process number to be monitored as the key, and the value is the process change information corresponding to the process number to be monitored, the process change information includes the state identifier of the process, the state jump timestamp and the state jump process resource information.

3. The method of claim 1, wherein, The S103 comprises: The eBPF user state program loads the eBPF kernel state program in the kernel through the _bpf_open_and_load() function, and loads the process probe in the kernel through the _bpf_attach() function.

4. The method of claim 1, wherein, The S104 comprises: The eBPF user state program registers the ring buffer through the ring_buffer_new() function and parameterizes the eBPF map to poll and read the process change information in the eBPF map for filling; When the process probe is triggered, the eBPF program is executed synchronously in the kernel context, and the process change information is directly written into the ring buffer, at this time the kernel notifies the eBPF user state program waiting for the data of the ring buffer, the eBPF user state program is awakened through the epoll or poll mechanism, the process change information in the ring buffer is read and parsed through the callback function, and the process state time sequence information, the process resource occupation information and the process abnormal state information are generated; According to the process state time sequence information, the process resource occupation information and the process abnormal state information, a process monitoring log is generated, and a process in an abnormal state is alarmed according to the process monitoring log.

5. The method of claim 4, wherein, The callback function is used to parse the read process change information, generate process state time sequence information, process resource occupation information and process abnormal state information, which comprises: The callback function calculates the difference between the timestamps of two adjacent state jumps of the process according to the timestamps of the state jumps, and generates process state timing information by counting the duration of the process in each state. The callback function generates process resource occupation information according to the memory usage and CPU usage of the process in different states. The callback function generates process exception state information according to the exit code of the process when it abnormally exits and the states of its parent and child processes.

6. The method of claim 4, wherein, The method further comprises: When the callback function finishes parsing the process change information, the eBPF user space program enters a sleep state, and if no process change information has been generated since the beginning, the eBPF user space program always remains in the sleep state.

7. The method of claim 1, wherein, The method further comprises: The eBPF kernel space program and the eBPF user space program are packaged, and a command line interface is provided for user invocation to monitor the state of a specified process.

8. A kernel plug-in based process state monitoring apparatus, comprising: It comprises: A process to be monitored determination module is configured to parse command line parameters input by a user through an eBPF user space program, obtain a process number to be monitored, and write the process number to be monitored into an eBPF map; A probe registration module is configured to add and register a process probe in a kernel through an eBPF kernel space program; A probe loading module is configured to load an eBPF kernel space program and a process probe in a kernel through an eBPF user space program; A change information parsing module is configured to register a ring buffer and pass an eBPF map as a parameter through an eBPF user space program, and parse process change information read through a callback function to generate a process monitoring log and alarm a process in an abnormal state according to the process monitoring log.

9. An electronic device, comprising: The electronic device comprises: One or more processors; A storage device configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the kernel plug-based process state monitoring method as claimed in any one of claims 1-7.

10. A storage medium containing computer executable instructions for executing the kernel plug-based process state monitoring method as claimed in any one of claims 1-7 when executed by a computer processor.

Images