Software monitoring method and device

Abstract

The invention provides a software monitoring method and device, and belongs to the technical field of computers. The method comprises the following steps: acquiring a configuration file corresponding to a service, and analyzing the configuration file to generate a task structure body; determining a target type corresponding to the service based on the task structure body; obtaining an execution strategy corresponding to the target type; and processing the service based on the execution strategy. In this way, the task structural body is generated based on the configuration file to determine the target type corresponding to the service, so that the service is processed based on the execution strategy, and services of different target types can be precisely processed according to the corresponding execution strategy.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a software monitoring method and apparatus. Background Technology

[0002] With the widespread application of the Linux operating system in critical business areas such as industrial automation, cloud computing, and the Internet of Things, various software running on it (such as transaction processing services, equipment control programs, and data transmission processes) have become the core support for business continuity. Any abnormal interruption or freeze of a service can lead to serious incidents. Therefore, high demands are placed on the real-time and reliable monitoring of the software lifecycle and its rapid self-healing capabilities after failures.

[0003] Currently, monitoring solutions for Linux software mainly fall into two categories. The first is the user-space daemon process solution, represented by Systemd. Systemd defines service startup, dependency, and restart policies through service unit files, utilizes cgroups for resource control and status monitoring, and can automatically restart services that exit abnormally. However, this solution runs in user space, and its monitoring capabilities depend on the survival and scheduling of user-space processes. When system resources are scarce or the user-space environment is compromised, its monitoring reliability is difficult to guarantee. Furthermore, its monitoring granularity is limited; it typically only responds to process exit events and cannot effectively identify processes that are "frozen" (i.e., processes that have not exited but have stopped responding to business requests or stopped performing "watchdog feeding" operations), resulting in monitoring blind spots. The second category is the traditional kernel-level monitoring solution, usually implemented as a kernel module, capturing process events through kernel hook functions. However, this type of solution has limited functionality, generally lacks a detection mechanism for "watchdog feeding" behavior, and self-healing operations often require a return to user space for triggering, leading to long fault recovery chains and high latency, making it difficult to meet the requirements for second-level recovery. In addition, existing kernel modules have compatibility risks with specific kernel versions (such as Linux 5.10.160) in terms of process scheduling, memory management, and other interfaces, which may cause kernel instability after deployment. Summary of the Invention

[0004] The purpose of this application is to provide a software monitoring method and apparatus to solve the technical problems of limited functionality and high self-healing latency in traditional kernel-level monitoring schemes in the prior art, thereby achieving precise processing of services. The specific technical solution is as follows: In a first aspect of this application, a software monitoring method is provided, applied in kernel mode, the method comprising: Obtain the configuration file corresponding to the service, parse the configuration file, and generate a task structure; Based on the task structure, determine the target type corresponding to the service; Obtain the execution strategy corresponding to the target type; The service is processed based on the execution strategy.

[0005] In an optional implementation, parsing the configuration file to generate a task structure includes: Obtain parameters corresponding to at least one target field from the configuration file; The task structure is generated based on the parameters corresponding to the at least one target field.

[0006] In an optional implementation, obtaining the execution strategy corresponding to the target type includes: Retrieve the preset task lifecycle management method table; Based on the environment type corresponding to the service, the execution strategy corresponding to the target type is obtained from the preset task lifecycle management method table.

[0007] In one optional implementation, the execution strategy includes: a listening method, a startup method, and a destruction method; The processing of the service based on the execution strategy includes: Start the service according to the startup method described above; The operational status of the service is monitored according to the aforementioned monitoring method; When an abnormal operating status of the service is detected, the service is terminated according to the destruction method.

[0008] In an optional implementation, starting the service according to the startup method includes: If the startup method is user-mode startup, then a kernel thread is created; The service is started by calling a user-mode helper function through the kernel thread; If the startup method is container-mode startup, then the configuration file and root file system path corresponding to the container runtime tool will be generated; The container runtime tool is invoked based on the configuration file and root file system path to start the service.

[0009] In an optional implementation, monitoring the service's operational status according to the listening method includes: If the monitoring method is the dog-feeding monitoring mode, then set the reception duration; According to the stated reception duration, the heartbeat signal of the service is received through the kernel driver interface; If the monitoring method is a non-dog-feeding monitoring mode, then set the query time interval; Query the process liveness status of the service according to the specified query time interval.

[0010] In one optional implementation, terminating the service according to the destruction method includes at least one of the following: The service is terminated by sending a container termination signal to the corresponding container; The service is terminated by sending a process termination signal to the termination process.

[0011] In an optional implementation, the termination process is determined in the following manner: Obtain the process identifier of the service; Based on the process identifier, traverse the process tree to obtain the child processes; The process of the service and its child processes are designated as the terminated processes.

[0012] In an optional implementation, the termination process is determined by: Retrieve the process list and the startup information of the service; The startup information of the service is matched with the command line information corresponding to each process in the process list to obtain the terminated process.

[0013] In a second aspect of this application, a software monitoring device is also provided, applied in kernel mode, the device comprising: The task structure generation module is used to obtain the configuration file corresponding to the service, parse the configuration file, and generate the task structure. The target type determination module is used to determine the target type corresponding to the service based on the task structure. An execution strategy acquisition module is used to acquire the execution strategy corresponding to the target type. The service processing module is used to process the service based on the execution strategy.

[0014] In a third aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the software monitoring method described in any one of the first aspects above.

[0015] In a fourth aspect of the embodiments of this application, a storage medium is also provided, wherein the storage medium stores instructions that, when run on a computer, cause the computer to execute any of the software monitoring methods described in the first aspect above.

[0016] In a fifth aspect of the embodiments of this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the software monitoring methods described in the first aspect above.

[0017] The technical solution provided in this application involves obtaining a configuration file corresponding to a service, parsing the configuration file to generate a task structure, determining the target type of the service based on the task structure, obtaining the execution strategy corresponding to the target type, and processing the service based on the execution strategy. By generating a task structure based on the configuration file to determine the target type of the service, and then processing the service based on the execution strategy, it is possible to accurately process services of different target types according to the corresponding execution strategy. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 A schematic diagram illustrating the implementation process of a software monitoring method provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of another software monitoring method provided in this application embodiment; Figure 3 A schematic diagram illustrating the implementation process of another software monitoring method provided in this application embodiment; Figure 4 A schematic diagram illustrating the implementation process of a service startup method provided in this application embodiment; Figure 5 A schematic diagram illustrating the implementation process of a monitoring service method provided in this application embodiment; Figure 6 This is a schematic diagram of another security protection framework provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a software monitoring device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0024] To address the shortcomings of traditional kernel-level monitoring solutions, which are typically implemented as kernel modules and capture process events through kernel hook functions, this approach suffers from limitations. These solutions generally lack detection mechanisms for "feeding the dog" (a common practice in monitoring processes that rely on external sensors or hooks), and their self-healing operations often require a return to user space, resulting in long fault recovery chains, high latency, and an inability to meet the requirements for second-level recovery. This application provides a software monitoring method and apparatus that obtains and parses the configuration file corresponding to a service to generate a task structure. Based on the task structure, the target type of the service is determined; the execution strategy corresponding to the target type is obtained; and the service is processed based on the execution strategy. By generating a task structure based on the configuration file to determine the target type of the service and then processing the service according to the execution strategy, it is possible to accurately process services of different target types according to the corresponding execution strategy.

[0025] like Figure 1 The diagram shown is a schematic representation of the implementation flow of a software monitoring method provided in this application embodiment, applied in the kernel mode, and specifically includes the following steps: S101: Obtain the configuration file corresponding to the service, parse the configuration file, and generate the task structure.

[0026] The aforementioned services refer to software entities that need to be monitored, such as a background daemon, a transaction processor, or a device control process.

[0027] The configuration file described above is a structured file used to define the service's lifecycle parameters, runtime environment, and monitoring rules. It can generally be in JSON format. It contains all the configuration information for service startup, operation, monitoring, and self-healing.

[0028] The aforementioned task structure can be a structure variable defined in kernel memory, generated after parsing the configuration file. It is used to store complete configuration information for the storage service (adapting to the kernel-mode data storage specification), facilitating the kernel module to quickly read, modify, and transfer the service configuration, and avoiding repeated parsing of the configuration file.

[0029] In this embodiment, the configuration file corresponding to the service is obtained, and the configuration file is parsed to generate a task structure. Specifically, the kernel can read the user-defined configuration file from a predefined storage path, and use a lightweight parsing library adapted to the kernel (such as the cjson library after modifying the memory allocation function) to read the key-value pair information in the configuration file, converting the unstructured / semi-structured configuration data into structure fields that the kernel can directly recognize, thereby obtaining the task structure. This embodiment does not limit the scope of this embodiment.

[0030] S102, Based on the task structure, determine the target type corresponding to the service.

[0031] In this embodiment of the application, the target type corresponding to the service is determined based on the structure generated by the above steps. The target type is used to characterize the type of the service in order to distinguish the service's operating environment, monitoring mode and lifecycle management method.

[0032] Specifically, the target service type can be determined based on the service's feeding mode (non-feeding mode, feeding mode) and blocking mode (blocking task, non-blocking task). The target service types are blocking feeding task, non-blocking feeding task, blocking non-feeding task, and non-blocking non-feeding task.

[0033] S103, obtain the execution strategy corresponding to the target type.

[0034] In this embodiment of the application, based on the target type corresponding to the service determined in the above steps, the execution strategy corresponding to the target type is obtained. The execution strategy is used to define the execution rules for the service, such as the service startup method, status monitoring method, anomaly detection logic, fault self-healing process, destruction method, etc., so as to realize the processing of different types of services.

[0035] S104, Process the service based on the execution policy.

[0036] In this embodiment, services are processed based on execution strategies. Specifically, services can be processed according to the rules corresponding to the execution strategy, such as the entire lifecycle of "startup → runtime monitoring → exception self-healing → normal destruction," ensuring that every stage of the service from startup to destruction is monitored and there are no blind spots in management. For example, the service is started according to the startup method corresponding to the execution strategy.

[0037] Based on the above description of the technical solution provided in the embodiments of this application, by obtaining the configuration file corresponding to the service, parsing the configuration file, generating a task structure; determining the target type corresponding to the service based on the task structure; obtaining the execution strategy corresponding to the target type; and processing the service based on the execution strategy, it is possible to accurately process services of different target types according to the corresponding execution strategy by generating a task structure based on the configuration file to determine the target type corresponding to the service and then processing the service based on the execution strategy.

[0038] like Figure 2 The diagram shown illustrates the implementation flow of another software monitoring method provided in this application, which may specifically include the following: S201, obtain the configuration file corresponding to the service.

[0039] In this embodiment of the application, this step is similar to step S101 above, and will not be described in detail here.

[0040] S202, Obtain at least one parameter corresponding to a target field from the configuration file.

[0041] In this embodiment, at least one parameter corresponding to a target field is obtained from the configuration file. The target field refers to the field used for managing services such as starting, destroying, and monitoring. Examples include environment fields such as isolated-mode (whether to isolate the environment) and rootfs (path to the isolated environment); monitoring fields such as feed (whether to feed the watchdog) and timeout (timeout period); and management fields such as block (whether to block), cmd (startup command), and argv (startup parameters).

[0042] The parameter corresponding to the target value field refers to the specific value of the target field in the configuration file. For example, if the target field is "isolated-mode" and is defined as isolated-mode:true in the configuration file, then the parameter of the target field "isolated-mode" is "true".

[0043] Specifically, a lightweight kernel-mode JSON parsing library (such as the cjson library used to modify kmalloc memory allocation) can be used to traverse the key-value pairs in the configuration file, filter out target fields and extract parameters, filter invalid fields (such as redundant comments), and ensure that the parameter format is compliant (e.g., feed only supports 0 / 1, and timeout must be a positive integer). For example, if the feed field in the configuration file is mistakenly written as "2", the parsing library will determine that the parameter is invalid, return an error, and terminate the task creation, thus avoiding subsequent monitoring logic anomalies.

[0044] S203, Generate a task structure based on the parameters corresponding to at least one target field.

[0045] In this embodiment, a task structure is generated based on parameters corresponding to at least one target field. The task structure is a structured data carrier defined in kernel-mode memory, used to persist core configuration parameters for storage services, avoiding repeated parsing of configuration files in subsequent monitoring and execution stages. At the same time, the structure format is compatible with kernel-mode data interaction specifications and can be directly passed to components such as timer modules and executor modules, improving data processing efficiency.

[0046] Specifically, contiguous memory space can be allocated first using kernel memory allocation functions (such as kmalloc). Then, the target field parameters extracted in step S202 above (such as isolated-mode: true, cmd: " / usr / bin / sensor-service") are filled into the corresponding members of the structure one by one. Finally, the structure is mounted to the kernel task management linked list (for unified scheduling). If the parameters have abnormal formats (such as a negative timeout), the generation is terminated and an error log is returned. The kernel task management linked list is used to uniformly manage the task structures of all services, supporting fast traversal, query, and deletion operations, which facilitates batch monitoring of service status by the executor module.

[0047] S204, based on the task structure, determine the target type corresponding to the service.

[0048] In this embodiment of the application, this step is similar to step S101 above, and will not be described in detail here.

[0049] S205, obtain the preset task lifecycle management method table.

[0050] In this embodiment, a preset task lifecycle management method table is obtained, wherein the preset task lifecycle management method table is a kernel-defined target type-execution strategy mapping table. Specifically, the preset task lifecycle management method table can be shown in Table 1 below. The target type corresponds to the "task type" in the table, "running environment" refers to the current service's running environment, and "startup method", "listening method", and "destruction method" are the corresponding execution strategies.

[0051] Table 1

[0052] S206. Based on the environment type corresponding to the service, obtain the execution strategy corresponding to the target type from the preset task lifecycle management method table.

[0053] In this embodiment, based on the environment type corresponding to the service, the execution strategy corresponding to the target type is obtained from a preset task lifecycle management method table. The environment type is a classification of the service's operating environment ("isolated environment" or "non-isolated environment," which can be determined by the isolated_mode field of the task structure). The environment type can be used as a first-level filtering condition for the table query to narrow the query scope (e.g., filtering out all entries whose operating environment is isolated), thus improving strategy matching efficiency. The execution strategy is a set of full lifecycle management rules for the target type, which may include "startup, listening, destruction," etc., but this embodiment does not limit this.

[0054] Specifically, the isolated_mode can be read from the task structure to determine the environment type (e.g., "isolated environment"). By calling the find_task_policy function, the entries in the preset task lifecycle management method table are first filtered according to the environment type, such as the entries whose running environment is isolated. Among the filtered entries, a unique execution policy is matched according to the target type (e.g., blocking non-dog-feeding task). If no match is found (e.g., target type definition error), the default policy (non-isolated environment - non-blocking non-dog-feeding task policy) is returned and an error log is recorded.

[0055] S207, Process services based on execution policies.

[0056] In this embodiment of the application, this step is similar to step S104 above, and will not be described in detail here.

[0057] like Figure 3 The diagram shown illustrates the implementation flow of another software monitoring method provided in this application, which may specifically include the following: S301: Obtain the configuration file corresponding to the service, parse the configuration file, and generate the task structure.

[0058] In this embodiment of the application, this step is similar to step S101 above, and will not be described in detail here.

[0059] S302, based on the task structure, determine the target type corresponding to the service.

[0060] In this embodiment of the application, this step is similar to step S102 above, and will not be described in detail here.

[0061] S303, obtain the execution strategy corresponding to the target type. The execution strategy includes: listening method, startup method, and destruction method.

[0062] In this embodiment of the application, the execution strategy corresponding to the target type is obtained. The execution strategy includes: listening method, startup method, and destruction method. For details, please refer to the listening method, startup method, and destruction method shown in Table 1.

[0063] S304, Start the service according to the startup method.

[0064] In this embodiment, the service is started according to the startup method. For example, it is started in user space using Kthread.

[0065] For details on how to start the service based on the startup method, please refer to the following: Figure 4 The method shown. (As illustrated) Figure 4 The diagram shown illustrates the implementation flow of a service startup method provided in this application embodiment, which may specifically include the following steps: S401: If the startup mode is user mode, then a kernel thread is created.

[0066] In this embodiment, the startup method involves creating a kernel thread during user-mode startup to avoid user-mode resource dependencies (such as startup failure due to user-mode process crashes). User-mode startup refers to the service running directly in the host user space (non-isolated environment), suitable for services with `isolated_mode: false`. A kernel thread (kthread) is a lightweight execution unit in kernel space, created by the `kthread_create` function, independent of user-mode processes, and offers higher stability. Specifically, `kthread_create(launch_user_service, task, "log-collect-thread")` can be called, where `launch_user_service` is the startup callback function, and `task` is a pointer to a task structure (passing parameters such as `cmd "argv"`) to create a kernel thread.

[0067] S402 starts the service by calling a user-mode helper function through a kernel thread.

[0068] In this embodiment, the service is started by calling a user-mode helper function through a kernel thread. The user-mode helper function refers to the call_usermodehelper interface provided by the kernel, which is used to safely execute user-mode programs in a kernel thread (avoiding direct calls to user-mode interfaces that could cause kernel crashes).

[0069] Specifically, in the kernel thread callback function (such as launch_user_service), the call_usermodehelper parameters (including cmd path, argv array, environment variables) are initialized, the call_usermodehelper_exec function is called to execute the parameters, the user-mode service is started, and the service PID is recorded into the task structure (task->task_pid=pid) for easy monitoring later.

[0070] S403 If the startup method is container mode startup, then the configuration file and root file system path corresponding to the container runtime tool will be generated.

[0071] In this embodiment, when the startup method is container-mode startup, a configuration file and root file system path are generated as prerequisites for container startup. Container-mode startup refers to the service running in a runc container (isolated environment), suitable for services with isolated_mode: true; the container runtime tool refers to runc (the standard Linux container runtime); the container configuration file refers to config.json (required for runc startup, containing namespaces, cgroups, startup commands, etc.), automatically generated by seaaway-guard (based on parameters such as rootfs "cmd" in the task structure); the root file system path (rootfs) refers to the container's root directory (e.g., / home / rsl / log-container / rootfs), containing the dependencies required for service operation. Specifically, the rootfs field of the task structure (e.g., / home / rsl / log-container) is read, a config.json file is generated in the rootfs directory, populated with namespaces (PID, NET, etc.), cgroup restrictions, startup commands (cmd and argv), and the integrity of rootfs is verified (ensuring the inclusion of basic commands such as / bin / sh).

[0072] S404 invokes the container runtime tools based on the configuration file and root file system path to start the service.

[0073] In this embodiment, the container runtime tool is invoked based on the configuration file and root file system path to start the service. This can be understood as invoking `runc` to start the service based on the configuration file and root file system path. Specifically, a kthread kernel thread is created (to avoid user-mode thread dependencies), and the `call_usermodehelper` function is called within the thread to execute the `runc` command: `runc run --bundle / home / rsl / log-container log-collect-container` (where `--bundle` specifies the directory containing the rootfs and `config.json`, and `log-collect-container` is the container name); `runc inspect` is called to obtain the container PID, which is recorded in the `container_pid` field of the task structure, completing the startup process.

[0074] S305 monitors the running status of services based on the listening method.

[0075] In this embodiment of the application, the service operation status is monitored according to the listening method to detect anomalies (such as process crashes, logic false liveness), specifically divided into "dog-feeding monitoring mode" and "non-dog-feeding monitoring mode".

[0076] For details on how to monitor the service's running status based on the listening method, please refer to... Figure 5 The method shown. (As illustrated) Figure 5 The diagram shown is a flowchart illustrating the implementation of a monitoring service method provided in this application embodiment, which may specifically include the following steps: S501, if the listening method is dog-feeding monitoring mode, then set the receiving duration.

[0077] In this embodiment, when the monitoring method is the "dog-feeding" monitoring mode, a receiving duration is set. The dog-feeding monitoring mode is suitable for services that need to detect "logically false liveness" (such as a process that is alive but not processing business). The core is to listen for the "heartbeat signal" actively sent by the service. The receiving duration refers to the maximum allowed heartbeat interval (consistent with the timeout field of the task structure, such as 1500ms). If no heartbeat is received within the timeout period, the service is considered abnormal. Specifically, the timeout value (such as 1500ms) is read from the task structure and assigned to the "timeout threshold" of the timer module. After the timer starts, a countdown begins, and the countdown is reset each time a heartbeat is received.

[0078] S502 receives the service's heartbeat signal through the kernel driver interface according to the reception duration.

[0079] In this embodiment, heartbeat signals are received via the kernel driver interface according to the reception duration. The kernel driver interface refers to the ` / dev / seaway-guard` device file (a character device interface registered by seaaway-guard). The service writes data (heartbeat signals) to this interface using the `write` function. The heartbeat signal can be empty data (only requiring a `write` operation to be triggered). seaaway-guard matches services (such as ` / usr / bin / log-service`) using cmdline to determine the corresponding task structure. Specifically, after the service starts, `write(fd,&gr,sizeof(gr))` (where `fd` is the file descriptor of ` / dev / seaway-guard`) is called every 1000ms to trigger the seaaway-guard's `write` driver function. The task structure is matched using `current->comm` (the current process name) to call `timer_reset` to reset the timer (the reception duration counts down again by 1500ms). If no `write` operation is triggered within 1500ms, the timer callback function `heartbeat_timeout_cb` is called, indicating a service error.

[0080] S503, if the listening method is non-dog-feeding monitoring mode, then set the query time interval.

[0081] In this embodiment, when the monitoring method is non-dog-feeding monitoring mode, a query time interval is set. The non-dog-feeding monitoring mode is suitable for services that only need to detect "process crashes" (such as lightweight services without complex business logic), to query the existence of the service process at time intervals. The query time interval is consistent with the timeout field of the task structure (e.g., 2000ms). Too short an interval will consume too many kernel resources, while too long an interval will lead to delayed anomaly detection. Specifically, the timeout value (e.g., 2000ms) can be read from the task structure to initialize an "interval query timer." Each time the timer expires, a process liveness query is triggered.

[0082] S504, query the process liveness status of the service according to the query time interval.

[0083] In this embodiment, the process liveness status of the service is queried according to the query time interval. The process liveness status query can be implemented through kernel functions. For example: in a non-isolated environment, the find_get_pid function is called, and the task_pid of the task structure is input. If NULL is returned, the process has crashed; in an isolated environment, the function corresponding to the container is called. If the status is "exited", the process has crashed.

[0084] Specifically, when the interval query timer expires, the check_process_alive_cb function is triggered to query the service process status (e.g., find_get_pid(task->task_pid) in a non-isolated environment). If the query result is "process does not exist", the service is determined to be abnormal and the destruction process is triggered; if the query result is "process exists", the timer is reset and the system waits for the next query.

[0085] S306: When an abnormal service status is detected, the service will be terminated according to the destruction method.

[0086] In this embodiment, when a service anomaly is detected, the service is terminated according to the destruction method to avoid resource leakage or business disruption. The anomaly states include: heartbeat timeout in dog-feeding mode, process non-dog-feeding mode not existing, and non-zero startup exit code. The destruction method is defined by the execution strategy, such as using the PID to kill child processes in non-isolated blocking mode, matching cmdline to kill processes in non-isolated non-blocking mode, and using runc stop in container mode.

[0087] Specifically, terminating a service based on the destruction method includes at least one of the following: terminating the service by sending a container termination signal to the corresponding container; or terminating the service by sending a process termination signal to the termination process.

[0088] In another embodiment of this application, the process can be terminated by obtaining the process identifier of the service, traversing the process tree based on the process identifier to obtain the child process, and using the service process and the child process as the termination process.

[0089] Specifically, the process identifier for obtaining the service is used to traverse the process tree to obtain child processes. This may include obtaining the process identifier of the service's main process in response to service runtime anomalies. Using the main process's process identifier as the root node, a depth-first search traversal is performed on the process tree to recursively obtain the process identifiers of all child processes, thus identifying the terminated process. Because blocking tasks are directly started and waited for by the kernel thread of the seaaway-guard (security protection module), their process tree structure is completely preserved, and the parent-child relationship between the main process and child processes is clear. By traversing the process tree, all processes related to the service can be accurately and thoroughly cleaned up, avoiding the creation of orphan processes or residual processes that could lead to resource leaks. Therefore, this method is primarily suitable for blocking tasks.

[0090] In another embodiment of this application, process termination can also be achieved by obtaining the process list and service startup information, matching the service startup information with the command line information corresponding to each process in the process list, and thus obtaining the terminated process.

[0091] Specifically, the process of obtaining the process list and service startup information involves matching the service startup information with the command-line information corresponding to each process in the process list to identify terminated processes. This may include retrieving service startup information from the task structure in response to service runtime anomalies. The startup information includes at least the startup command path and its parameter list. The current global process list is retrieved and iterated through, reading the command-line information for each process. The service startup information is then matched against the command-line information of each process. All processes whose command-line information matches the service startup information are identified as the set of terminated processes. Since the parent process of a non-blocking task may exit after startup, causing the child process to be taken over by the init process (PID=1), the original process tree structure is disrupted, making it impossible to trace through parent-child relationships. By precisely matching the command-line information (including the complete path and parameters), all processes derived from the service startup command can be reliably identified, regardless of their current position in the process tree, thus ensuring thorough cleanup. This method does not rely on parent-child relationships between processes and is robust to changes in the process tree structure. Therefore, this method is primarily suitable for non-blocking tasks.

[0092] like Figure 6 The diagram shown is a structural schematic of another security protection framework provided in this application embodiment, which may specifically include: The security protection framework can be divided into five parts: configuration driver module, file parsing module, data serialization module, timer module, and executor module.

[0093] As a kernel module, the security protection module first loads the user-space configuration file after power-on and obtains the raw data by parsing the configuration file.

[0094] The data serialization module summarizes all the data obtained from parsing the configuration file, checks if there is a file with the same name in the configuration file, merges environment variables, processes the data in the configuration file into a task structure, creates a run group based on the task structure, and passes it to the timer and executor.

[0095] The executor categorizes tasks into isolated and non-isolated environments based on the task structure. It creates kernel threads to launch user-mode programs using the `call_usermodehleper` function, while simultaneously monitoring the user-mode program's status. If an abnormal user-mode program status is detected, the application is restarted. The timer module categorizes services into watchdog-feeding and non-watchdog-feeding programs based on the target type. For watchdog-feeding programs, it checks the status at preset intervals; failure to do so indicates a program error. For non-watchdog-feeding programs, it checks the task status at preset time intervals; failure to do so indicates a program error.

[0096] The timer module is used to prevent unresponsive abnormal states such as task deadlock.

[0097] The kernel interface module serves as a portal for interaction between user space and kernel space. After the kernel starts, it registers as a kernel driver module. In user space, it opens the / dev / seaway-guard device descriptor and writes the countdown timer for data updates.

[0098] It should be noted that the security protection module primarily uses kernel threads and the `call_usermodehleper` function to keep the application alive. Therefore, the data parsed from the configuration file needs to be re-serialized. During this re-serialization process, the environment variable hash table needs to be merged to further differentiate environment variable types. System variables that support appending are appended, while environment variables that do not support appending are overwritten. Wildcards, regular expressions, and references for environment variables are also implemented, ultimately merging user-space environment variables and default environment variables. Different task configurations are generated based on the task type. For example, non-isolated tasks directly start the user-space application using kernel threads, while isolated tasks generate a container `bundle config.json` file for the isolated environment based on the task's configured environment variables and execution parameters, and then execute the application through this isolated container.

[0099] The executor module is used to start, monitor, and destroy applications. Different start, monitoring, and destruction methods are employed depending on the task execution environment, execution parameters, and dongle feeding method, improving the availability and reliability of security protection. See Table 1 above for details.

[0100] Corresponding to the above method embodiments, this application also provides a software monitoring device, such as... Figure 7 As shown, the device is applied in kernel mode and may include a task structure generation module 701, a target type determination module 702, an execution strategy acquisition module 703, and a service processing module 704.

[0101] The task structure generation module 701 is used to obtain the configuration file corresponding to the service, parse the configuration file, and generate the task structure. The target type determination module 702 is used to determine the target type corresponding to the service based on the task structure; The execution strategy acquisition module 703 is used to acquire the execution strategy corresponding to the target type; Service processing module 704 is used to process services based on execution policies.

[0102] This application also provides an electronic device, such as... Figure 8As shown, it includes a processor 801, a communication interface 802, a memory 803, and a communication bus 804. The processor 801, communication interface 802, and memory 803 communicate with each other via the communication bus 804. Memory 803 is used to store computer programs; In one embodiment of this application, when the processor 801 executes a program stored in the memory 803, it performs the following steps: Obtain the configuration file corresponding to the service, parse the configuration file to generate a task structure; based on the task structure, determine the target type corresponding to the service; obtain the execution strategy corresponding to the target type; and process the service based on the execution strategy.

[0103] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0104] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0105] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0106] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0107] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the software monitoring methods described in the above embodiments.

[0108] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the software monitoring methods described in the above embodiments.

[0109] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0110] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0111] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0112] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.

Claims

1. A software monitoring method, characterized in that, Applied to kernel mode, the method includes: Obtain the configuration file corresponding to the service, parse the configuration file, and generate a task structure; Based on the task structure, determine the target type corresponding to the service; Obtain the execution strategy corresponding to the target type; The service is processed based on the execution strategy.

2. The method according to claim 1, characterized in that, The step of parsing the configuration file to generate a task structure includes: Obtain parameters corresponding to at least one target field from the configuration file; The task structure is generated based on the parameters corresponding to the at least one target field.

3. The method according to claim 1, characterized in that, The step of obtaining the execution strategy corresponding to the target type includes: Retrieve the preset task lifecycle management method table; Based on the environment type corresponding to the service, the execution strategy corresponding to the target type is obtained from the preset task lifecycle management method table.

4. The method according to claim 1, characterized in that, The execution strategy includes: monitoring method, startup method, and destruction method; The processing of the service based on the execution strategy includes: Start the service according to the startup method described above; The operational status of the service is monitored according to the aforementioned monitoring method; When an abnormal operating status of the service is detected, the service is terminated according to the destruction method.

5. The method according to claim 4, characterized in that, Starting the service according to the startup method includes: If the startup method is user-mode startup, then a kernel thread is created; The service is started by calling a user-mode helper function through the kernel thread; If the startup method is container-mode startup, then the configuration file and root file system path corresponding to the container runtime tool will be generated; The container runtime tool is invoked based on the configuration file and root file system path to start the service.

6. The method according to claim 4, characterized in that, The monitoring of the service's operational status according to the listening method includes: If the monitoring method is the dog-feeding monitoring mode, then set the reception duration; According to the stated reception duration, the heartbeat signal of the service is received through the kernel driver interface; If the monitoring method is a non-dog-feeding monitoring mode, then set the query time interval; Query the process liveness status of the service according to the specified query time interval.

7. The method according to claim 4, characterized in that, The termination of the service according to the destruction method includes at least one of the following: The service is terminated by sending a container termination signal to the corresponding container; The service is terminated by sending a process termination signal to the termination process.

8. The method according to claim 7, characterized in that, The termination process is determined in the following way: Obtain the process identifier of the service; Based on the process identifier, traverse the process tree to obtain the child processes; The process of the service and its child processes are designated as the terminated processes.

9. The method according to claim 7, characterized in that, The termination process is determined in the following ways, including: Retrieve the process list and the startup information of the service; The startup information of the service is matched with the command line information corresponding to each process in the process list to obtain the terminated process.

10. A software monitoring device, characterized in that, Applied to kernel mode, the device includes: The task structure generation module is used to obtain the configuration file corresponding to the service, parse the configuration file, and generate the task structure. The target type determination module is used to determine the target type corresponding to the service based on the task structure. An execution strategy acquisition module is used to acquire the execution strategy corresponding to the target type. The service processing module is used to process the service based on the execution strategy.

Images