File handle leakage monitoring method and device, vehicle and storage medium

Abstract

The invention relates to a file handle leakage monitoring method and device, a vehicle and a storage medium, and relates to the technical field of computers.The method comprises the steps that in the operation process of an operating system kernel, in response to file handle distribution, an eBPF is used for monitoring a distribution event of file handles, and a distributed file descriptor value is obtained; comparing the file descriptor value with a preset leakage judgment threshold value; generating a file handle leakage event in response to the file descriptor value exceeding a leakage determination threshold; and reporting the file handle leakage event. According to the invention, the real-time performance and the response speed of monitoring can be obviously improved; unnecessary system calling and context switching are greatly reduced, the resource consumption in the monitoring process is remarkably reduced, and the overall monitoring efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, vehicle, and storage medium for monitoring file handle leakage. Background Technology

[0002] In computer operating systems, when applications need to access files or other system resources (such as devices and network connections) stored on persistent media (such as hard drives and solid-state drives), they cannot directly operate using the file pathname. To efficiently and securely manage access to these resources, the operating system introduces the core concept of a "file handle." A file handle, also known as a file descriptor (fd), is an abstract identifier returned to the application by the operating system after successfully opening a file or resource. This identifier is typically a non-negative integer and is unique within the context of a single process. When an application has programming flaws, such as failing to properly close files or network connections, the file descriptor may continuously grow, eventually exhausting the process's available fd limit, leading to serious failures such as service unavailability and connection denial—a situation known as file handle leakage.

[0003] In existing technologies, monitoring for file handle leakage can be achieved by polling the number of file descriptors (fds) of the corresponding process at fixed time intervals. However, this method consumes a lot of system resources, resulting in low monitoring efficiency and significant reporting latency, which leads to poor real-time monitoring results and affects user experience.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] To overcome the problems existing in related technologies, this disclosure provides a method, device, vehicle, and storage medium for monitoring file handle leakage.

[0006] According to a first aspect of the present disclosure, a method for monitoring file handle leakage is provided, comprising: During the operation of the operating system kernel, in response to the allocation of file handles, the extended Berkeley packet filter eBPF is used to monitor the allocation event of file handles and obtain the value of the allocated file descriptor. Compare the file descriptor value with a preset leakage detection threshold; A file handle leakage event is generated in response to the file descriptor value exceeding the leakage determination threshold; Report the aforementioned file handle leak incident.

[0007] In some possible embodiments of this disclosure, in response to the allocation of a file handle, the allocation event of the file handle is monitored using the Extended Berkeley Packet Filter (eBPF) to obtain the value of the allocated file descriptor, including: The eBPF program is dynamically mounted to the file descriptor mapping function via kernel tracking to monitor the allocation events of the file handle; In response to the invocation of the file descriptor mapping function, the eBPF program is executed to obtain the file descriptor value.

[0008] In some possible embodiments of this disclosure, the file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value.

[0009] In some possible embodiments of this disclosure, generating a file handle leakage event includes: Allocate memory space for the circular buffer managed by the eBPF; The PID and the file descriptor value are filled into the memory space to construct the file handle leakage event; The file handle leak event is submitted to the circular buffer.

[0010] In some possible embodiments of this disclosure, it also includes: Generate the file handle leakage event identifier; The file handle leakage event also includes: the file handle leakage event identifier.

[0011] In some possible embodiments of this disclosure, reporting the file handle disclosure event includes: The circular buffer is used to report the file handle leakage event from kernel mode to the user-mode monitoring daemon.

[0012] In some possible embodiments of this disclosure, the circular buffer is used to report the file handle leakage event from kernel mode to a user-mode monitoring daemon, including: The user-mode monitoring daemon asynchronously reads the file handle leakage event from the circular buffer.

[0013] In some possible embodiments of this disclosure, it also includes: After the file handle leakage event is first generated, the baseline value of the file descriptor of the corresponding target process is recorded; The eBPF is used to monitor the value of newly allocated file descriptors of the target process. In response to the increment of the value of newly allocated file descriptors relative to the baseline value reaching a preset interval threshold, an updated file handle leakage event is regenerated. The updated file handle leakage incident was reported.

[0014] In some possible embodiments of this disclosure, it also includes: After the user-mode monitoring daemon first receives the file handle leakage event, it starts a leakage monitoring timer for the corresponding target process using the user-mode monitoring daemon. Within the timeout period of the leak monitoring timer, the collection of runtime context information of the target process is triggered.

[0015] In some possible embodiments of this disclosure, triggering the collection of runtime context information of the target process includes: Collect the function call stack information of the target process in kernel mode and / or user mode, and generate leak diagnostic data based on the function call stack information.

[0016] Some possible embodiments of this disclosure also include: In response to the user-mode monitoring daemon not receiving a file handle leakage event for the target process within the timeout period of the leakage monitoring timer, after the leakage monitoring timer expires, the user-mode monitoring daemon controls the eBPF to reset the monitoring status of the target process to a non-crawling state.

[0017] Some possible embodiments of this disclosure also include: The user-mode monitoring daemon generates a leak monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process. The leak monitoring logs were uploaded to the cloud platform.

[0018] Some possible embodiments of this disclosure also include: The system receives the leakage handling policy issued by the cloud platform and uses the user-space monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling policy.

[0019] According to a second aspect of the present disclosure, a method for monitoring file handle leakage is provided, comprising: Receive at least one leak monitoring log reported by a target host; wherein, the leak monitoring log is generated by a user-space monitoring daemon running on the target host when it controls eBPF to monitor file handle allocation events and determines that a file handle leak event has occurred; Root cause analysis was performed based on the leak monitoring logs to obtain the leak analysis results.

[0020] In some possible embodiments of this disclosure, the leak monitoring log carries the runtime context information of the target process corresponding to the leak; The root cause analysis based on the leak monitoring logs includes: Root cause analysis is performed on the runtime context information to identify the code path or behavior pattern that leads to file handle leakage.

[0021] In some possible embodiments of this disclosure, it also includes: Based on the leak analysis results, a leak diagnosis report is generated; The leak diagnosis report describes the location of the leak, the cause of the leak, and remediation recommendations.

[0022] In some possible embodiments of this disclosure, it also includes: A leak handling policy is generated and distributed to the target host so that the user-space monitoring daemon running on the target host can perform anomaly recovery processing based on the leak handling policy.

[0023] According to a third aspect of the present disclosure, a file handle leakage monitoring device is provided, comprising: The value acquisition unit is used to monitor the file handle allocation event and obtain the allocated file descriptor value in response to the allocation of file handles during the operation of the operating system kernel. A numerical comparison unit is used to compare the file descriptor value with a preset leakage determination threshold. An event generation unit is used to generate a file handle leakage event in response to the file descriptor value exceeding the leakage determination threshold. The event reporting unit is used to report the file handle leakage event.

[0024] In some possible embodiments of this disclosure, the numerical acquisition unit is configured as follows: The eBPF program is dynamically mounted to the file descriptor mapping function via kernel tracking to monitor the allocation events of the file handle; In response to the invocation of the file descriptor mapping function, the eBPF program is executed to obtain the file descriptor value.

[0025] In some possible embodiments of this disclosure, the file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value.

[0026] In some possible embodiments of this disclosure, the event generation unit is configured as follows: Allocate memory space for the circular buffer managed by the eBPF; The PID and the file descriptor value are filled into the memory space to construct the file handle leakage event; The file handle leak event is submitted to the circular buffer.

[0027] In some possible embodiments of this disclosure, the event reporting unit is configured as follows: The circular buffer is used to report the file handle leakage event from kernel mode to the user-mode monitoring daemon.

[0028] In some possible embodiments of this disclosure, an update reporting unit is further included, for: After the file handle leakage event is first generated, the baseline value of the file descriptor of the corresponding target process is recorded; The eBPF is used to monitor the value of newly allocated file descriptors of the target process. In response to the increment of the value of newly allocated file descriptors relative to the baseline value reaching a preset interval threshold, an updated file handle leakage event is regenerated. The updated file handle leakage incident was reported.

[0029] In some possible embodiments of this disclosure, a context acquisition unit is further included, for: After the user-mode monitoring daemon first receives the file handle leakage event, it starts a leakage monitoring timer for the corresponding target process using the user-mode monitoring daemon. Within the timeout period of the leak monitoring timer, the collection of runtime context information of the target process is triggered.

[0030] In some possible embodiments of this disclosure, a log uploading unit is further included, for: The user-mode monitoring daemon generates a leak monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process. The leak monitoring logs were uploaded to the cloud platform.

[0031] In some possible embodiments of this disclosure, an exception handling unit is further included, for: The system receives the leakage handling policy issued by the cloud platform and uses the user-space monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling policy.

[0032] According to a fourth aspect of the present disclosure, a file handle leakage monitoring device is provided, comprising: A data receiving unit is used to receive leakage monitoring logs reported by at least one target host; wherein, the leakage monitoring logs are generated by a user-space monitoring daemon running on the target host when it controls eBPF to monitor file handle allocation events and determines that a file handle leakage event has occurred; The root cause analysis unit is used to perform root cause analysis based on the leakage monitoring logs to obtain leakage analysis results.

[0033] In some possible embodiments of this disclosure, the leak monitoring log carries the runtime context information of the target process corresponding to the leak; The root cause analysis unit is configured as follows: Root cause analysis is performed on the runtime context information to identify the code path or behavior pattern that leads to file handle leakage.

[0034] In some possible embodiments of this disclosure, a data analysis unit is further included, for: Based on the leak analysis results, a leak diagnosis report is generated; The leak diagnosis report describes the location of the leak, the cause of the leak, and remediation recommendations.

[0035] In some possible embodiments of this disclosure, it further includes: a policy distribution unit, used for: A leak handling policy is generated and distributed to the target host so that the user-space monitoring daemon running on the target host can perform anomaly recovery processing based on the leak handling policy.

[0036] According to a fifth aspect of the present disclosure, a vehicle is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to implement the steps of any of the file handle leakage monitoring methods described in the first aspect above.

[0037] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, which, when instructions in the storage medium are executed by a vehicle's processor, enables the vehicle to perform any of the file handle leakage monitoring methods described in the first aspect.

[0038] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects: This disclosure utilizes eBPF to monitor file handle allocation events during operating system kernel runtime, in response to file handle allocation, to obtain the allocated file descriptor value; compare the file descriptor value with a preset leak detection threshold; generate a file handle leak event when the file descriptor value exceeds the leak detection threshold; and report the file handle leak event. By leveraging eBPF, real-time monitoring is achieved, capturing the behavior the moment a file descriptor is allocated, avoiding the detection delay caused by time intervals in polling mechanisms. When the file descriptor value exceeds the threshold, a leak event is immediately generated and reported, significantly improving the real-time performance and response speed of monitoring. Compared to periodic polling, by directly listening to critical allocation events in kernel mode using eBPF, lightweight processing logic is executed only when the event occurs, eliminating the need for active polling. This greatly reduces unnecessary system calls and context switching, significantly lowering the resource consumption of the monitoring process itself and improving overall monitoring efficiency.

[0039] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

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

[0041] Figure 1 This is a flowchart illustrating a file handle leakage monitoring method according to an exemplary embodiment of the present disclosure. Figure 1 .

[0042] Figure 2 This is a flowchart illustrating the implementation process of step S110 according to an exemplary embodiment of the present disclosure.

[0043] Figure 3 This is a flowchart illustrating a file handle leakage monitoring method according to an exemplary embodiment of the present disclosure. Figure 2 .

[0044] Figure 4 This is a flowchart illustrating a file handle leakage monitoring method according to another exemplary embodiment of this disclosure.

[0045] Figure 5 This is a file handle leakage monitoring device frame shown according to an exemplary embodiment of the present disclosure. Figure 1 .

[0046] Figure 6 This is a file handle leakage monitoring device frame shown according to an exemplary embodiment of the present disclosure. Figure 2 .

[0047] Figure 7 This is a block diagram illustrating a vehicle according to an exemplary embodiment of the present disclosure. Detailed Implementation

[0048] Exemplary embodiments of this disclosure will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0049] The embodiments described below, which are examples of some of the embodiments of this disclosure, do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0050] The specific implementation methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0051] Figure 1 This is a flowchart illustrating a file handle leakage monitoring method according to an exemplary embodiment of the present disclosure. Figure 1 ,like Figure 1 As shown, the file handle leakage monitoring method can be used on electronic devices, including but not limited to smartphones, wearable devices, and smart tablets, as well as vehicles, such as new energy vehicles (EVs) and plug-in hybrid electric vehicles (PHEVs). It is understood that both electronic devices and vehicles contain a host computer with an operating system installed, such as Unix / Linux or Android systems.

[0052] Figure 1 The file handle leakage monitoring method shown includes the following steps.

[0053] In step S110, during the operation of the operating system kernel, in response to the allocation of file handles, the allocation event of file handles is monitored using the extended Berkeley packet filter eBPF to obtain the value of the allocated file descriptor.

[0054] In some exemplary embodiments of this disclosure, in the operating system, when an application opens a file, the kernel allocates a file handle, also known as a file descriptor (fd). eBPF can be used to monitor the file handle allocation event to obtain the value of the allocated file descriptor (fd).

[0055] It should be noted that eBPF (Extended Berkeley Packet Filter) is a packet filtering technology that is an extension of BPF (Berkeley Packet Filter) technology. It can be used to implement network traffic statistics, CPU / IO / memory monitoring, etc.

[0056] In step S120, the file descriptor value is compared with a preset leakage judgment threshold.

[0057] It's important to note that when allocating file descriptors (fds), the kernel always follows a principle for efficiency: allocating the smallest currently available number. For example, suppose a process starts and opens three files sequentially, typically acquiring fd numbers 3, 4, and 5. If this process then closes fd4, the next newly opened file will reuse this smallest free number, 4. Under normal circumstances, a process's fd numbers will fluctuate within a small range (e.g., tens to hundreds) because files are closed promptly after opening, and freed numbers are reused. However, if a file handle leak occurs, meaning a file is opened but not closed, and because fd numbers are allocated incrementally, prioritizing the smallest free number, if all lower numbers are occupied, only newer, larger numbers can be used. As the leak continues, the number of fds a process needs will increase. Therefore, the largest fd number currently allocated to a process directly reflects the number of file handles that process is currently using.

[0058] In this embodiment, by comparing the currently monitored assigned file descriptor (fd) value with a preset leakage threshold, it can be determined whether file handle leakage has occurred. That is, if the file descriptor value does not exceed the preset leakage threshold, then no file handle leakage has occurred. It is understood that the leakage threshold is preset and can be set according to system characteristics and monitoring objectives. Its specific value and setting method can be flexibly configured to adapt to different application scenarios and accuracy requirements, and this embodiment does not limit this. For example, a specific value can be set, such as 2000, 3000, or 80% of the maximum number of fds allowed for a single process by the system. Alternatively, a corresponding value can be set individually for each monitored process. For example, the average and peak values ​​of the historical fd usage of each process can be statistically analyzed, and a safety margin can be added based on the peak and / or average values ​​as the process's exclusive leakage threshold, making it more targeted and effectively reducing false alarms. Furthermore, behavior prediction can be performed based on historical usage, and the leakage threshold value can be dynamically adjusted to adapt to the actual needs of different operational stages. You can also set multi-level thresholds, that is, set different values ​​to correspond to different severity levels. For example, 2000 corresponds to the warning threshold, 3000 corresponds to the severe threshold, and 5000 corresponds to the critical threshold, so as to achieve more refined monitoring.

[0059] In step S130, a file handle leakage event is generated in response to the file descriptor value exceeding the leakage determination threshold.

[0060] It should be noted that when the file descriptor value exceeds the leakage judgment threshold, it proves that a file handle leakage has occurred. By generating a file handle leakage event, a structured and actionable event signal is generated to issue an alarm.

[0061] In step S140, a file handle leakage event is reported.

[0062] In the exemplary implementation of this disclosure, file handle leakage events can be reported from kernel space to a user space monitoring daemon via eBPF. It should be noted that user space refers to the non-privileged mode in which ordinary applications run, and the monitoring daemon is a long-running background program in user space responsible for receiving, processing, storing, and reporting monitoring data, such as generating alarms and writing logs.

[0063] Understandably, eBPF programs run in kernel mode and can directly access kernel data and events, but they cannot interact with users. Structured event data can be passed to user-mode monitoring programs via a secure channel such as a shared BPF Map (e.g., a Ring Buffer) for subsequent alerting, logging, and further analysis. A BPF Map is an efficient key-value store provided by the kernel, accessible to both eBPF and user-mode programs.

[0064] As can be seen from the above steps, the file handle leakage monitoring method provided in the embodiments of this disclosure monitors file handle allocation events using eBPF during the operation of the operating system kernel in response to file handle allocation, obtains the allocated file descriptor value, compares the file descriptor value with a preset leakage judgment threshold, generates a file handle leakage event in response to the file descriptor value exceeding the leakage judgment threshold, and reports the file handle leakage event. By utilizing eBPF, real-time monitoring can be achieved, capturing the behavior the moment a file descriptor is allocated, avoiding the detection delay caused by time intervals in polling mechanisms. When the file descriptor value exceeds the threshold, a leakage event is immediately generated and reported, significantly improving the real-time performance and response speed of monitoring. Compared to periodic polling, by using eBPF to directly listen to critical allocation events in kernel mode, lightweight processing logic is executed only when the event occurs, eliminating the need for active polling, greatly reducing unnecessary system calls and context switching, significantly reducing the resource consumption of the monitoring process itself, and improving overall monitoring efficiency.

[0065] Furthermore, this embodiment of the present disclosure immediately compares the file descriptor value obtained each time with a preset leakage judgment threshold, avoiding the possibility of missing brief but drastic file descriptor growth behavior due to excessively long sampling intervals in polling methods. This improves the detection accuracy for gradual or sudden leakage, reduces false positives and false negatives, and enhances detection accuracy. Moreover, eBPF technology allows the deployment of monitoring logic without modifying kernel source code, restarting the system, or intruding on the target application, offering good security and maintainability. This embodiment of the present disclosure implements file handle allocation behavior monitoring in a non-intrusive manner, is applicable to various deployed production environments, is compatible with different Linux distributions and kernel versions, and can adapt to various systems, exhibiting broad applicability and deployment flexibility.

[0066] In some exemplary embodiments of this disclosure, the implementation process of step S110 is as follows: Figure 2 As shown, the steps include the following.

[0067] In step S210, the eBPF program is dynamically mounted to the file descriptor mapping function through kernel tracing to monitor file handle allocation events.

[0068] In step S220, in response to the call to the file descriptor mapping function, the eBPF program is executed to obtain the file descriptor value.

[0069] In some embodiments of this disclosure, an eBPF program can be pre-developed, designed to monitor file operations. This eBPF program can be written with the entry function `regs`, a pointer to a register structure. When `kprobe` (kernel dynamic tracing) is triggered, the register's state is saved. According to system call conventions, in the ARM64 architecture, the first parameter of a function call is typically stored in register x0 (or `regs[0]`). The first parameter of the `fd_install` function is `fd` (file descriptor), so the file descriptor value can be obtained by checking the value of register `regs[0]`.

[0070] The eBPF program needs to be hooked onto a specific kernel function, namely the file descriptor mapping (fd_install) function, which is responsible for the actual file handle allocation. In practice, this can be achieved using the hook point "kprobe / enter_fd_install", which inserts the eBPF program at the entry point of the fd_install function. Whenever the fd_install function is called, the eBPF code will run first. kprobe is a debugging mechanism in the Linux kernel that allows a "probe" to be dynamically inserted at the entry (enter_) or exit (exit_) point of almost any kernel instruction (or function). When the kernel executes the fd_install function, which is "hooked" by the probe, it will first jump to execute the eBPF program, and then return to continue executing the original function.

[0071] It's important to note that the `fd_install` function is a function in the Linux kernel used to associate a file object (struct file) with a file descriptor (fd). It is typically called when opening files, creating pipes, sockets, or other types of file descriptors in the kernel.

[0072] It's important to note that each time a file is opened, the corresponding file descriptor (fd) allocation algorithm function is `__get_unused_fd_flags`. This function searches for unused file descriptors in the current process's file descriptor table (`files_struct`). The kernel prioritizes allocating the smallest unused file descriptor, and since `fd` is an integer, monitoring its value allows us to monitor the maximum number of files currently used by the process.

[0073] For example, the list of all file descriptors owned by the process with process ID (PID) 9841 is as follows: suiren: / proc / 9841 / fd # ls 0 104 11 115 17 22 28 33 39 44 5 55 60 66 71 77 82 88 93 99 1 105 110 12 18 23 29 34 4 45 50 56 61 67 72 78 83 89 94 10 106 111 13 19 24 3 35 40 46 51 57 62 68 73 79 84 9 95 101 107 112 14 2 25 30 36 41 47 52 58 63 69 74 8 85 90 96 102 108 113 15 20 26 31 37 42 48 53 59 64 7 75 80 86 91 97 103 109 114 16 21 27 32 38 43 49 54 6 65 70 76 81 87 92 98 As you can see, the file descriptor (fd) numbers start from 0, but are not consecutive; missing numbers represent those fds that have been closed and released. The largest number in the list is 115, meaning that at the current moment, the largest fd number the process is using is 115. This number (115) is itself approximately equal to the number of files the process currently has open.

[0074] In some exemplary embodiments of this disclosure, a file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value. This records key information for locating the root cause of the problem and quantifies the severity of the leakage, providing the necessary and sufficient information set for subsequent intervention. This simplifies the process to an immediate response to a clearly recorded event, significantly reducing the difficulty of operation and maintenance and the requirements for professional experience, and improving overall operational efficiency. Thus, it can carry the most accurate fault information (who, how severe, why) when reporting, with minimal performance overhead.

[0075] Understandably, file handle leakage events can be further expanded to include other auxiliary information, such as timestamps, hostnames, and specific values ​​of trigger thresholds, for a more comprehensive record.

[0076] In some exemplary embodiments of this disclosure, the process of generating a file handle leakage event may include the following steps: allocating memory space in the ring buffer managed by eBPF; filling the memory space with the PID and file descriptor values ​​to construct a file handle leakage event; and submitting the file handle leakage event to the ring buffer.

[0077] eBPF programs can use BPF maps for storage, and user programs typically need to interact with eBPF programs running in the kernel through BPF maps. eBPF programs collect kernel runtime state and store it in the maps, and user programs then read this state from the maps.

[0078] In practice, when the eBPF program determines a file handle leak in kernel mode, it first calls the `bpf_ringbuf_reserve()` function to pre-allocate a contiguous block of memory of a specified size from the circular buffer shared by the eBPF program and the user-space program. It's important to note that the allocated space must be large enough to accommodate the defined file handle leak event structure (which typically contains fields such as PID and fd). Furthermore, `bpf_ringbuf_reserve()` is a non-blocking, efficient operation, ensuring that memory is acquired immediately when space is available in the buffer, avoiding the overhead and uncertainty of dynamic memory allocation. After acquiring the reserved memory space, the eBPF program treats it as a pointer to a `struct leak_event` (or a similar custom structure). The eBPF program then assigns the currently captured target process identifier (PID) and file descriptor value (fd) to the corresponding members of this structure. After the data is filled, the eBPF program calls the bpf_ringbuf_submit() function to formally submit the previously reserved memory space to the ring buffer, thus making the file handle leakage event immediately visible to the user space monitoring program, providing a reliable event notification mechanism.

[0079] In some exemplary embodiments of this disclosure, to accurately distinguish and track file handle leakage events, the provided file handle leakage monitoring method further includes: generating a file handle leakage event identifier. That is, using an eBPF program to generate a unique file handle leakage event identifier corresponding to the file handle leakage event, and filling it into memory space to construct a file handle leakage event. In other words, in some exemplary embodiments, the file handle leakage event further includes: a file handle leakage event identifier.

[0080] In practice, generating file handle leak event identifiers can be done using kernel timestamps, or an atomic counter can be used. An atomic variable can be defined as a counter in the eBPF global data structure; each time a new event is generated, this counter is atomically incremented, and the current count value is used as the corresponding event identifier. Alternatively, event identifiers can be generated based on the event type.

[0081] By generating file handle leakage event identifiers, the system can clearly distinguish different events, achieving accurate event deduplication, avoiding duplicate alarms, and reducing operational interference. Furthermore, it provides a full-chain tracing clue for each leakage event, greatly simplifying the troubleshooting and auditing process.

[0082] In some exemplary embodiments of this disclosure, reporting a file handle leakage event includes: using a circular buffer to report the file handle leakage event from kernel mode to a user-mode monitoring daemon.

[0083] It's important to note that reporting file handle leak events from kernel space to the user-space monitoring daemon using a ring buffer is essentially a typical asynchronous transmission process. Specifically, the producer is the eBPF program running in kernel space, and the consumer is the monitoring daemon running in user space. The transmission channel is the BPF ring buffer. The kernel-space eBPF program, acting as the "producer," posts events to the ring buffer in a non-blocking manner and returns immediately, without caring about or waiting for when the user-space "consumer" processes them. The user-space monitoring daemon retrieves and processes file handle leak events from the ring buffer in an event-driven manner.

[0084] In some exemplary embodiments of this disclosure, a circular buffer is used to report file handle leakage events from kernel mode to a user-mode monitoring daemon. This includes the user-mode monitoring daemon asynchronously reading the file handle leakage events from the circular buffer. This ensures the efficiency and low overhead of kernel monitoring while allowing user-mode programs to handle complex subsequent logic flexibly and safely.

[0085] In some exemplary embodiments of this disclosure, a flow of a file handle leakage monitoring method is shown. Figure 2 ,like Figure 3 As shown. Figure 3 Steps S310 to S340 and Figure 1 Steps S110 to S140 correspond to each other and will not be repeated here. Figure 1 In addition to the implementation process shown, the following steps are also included.

[0086] In step S350, after the file handle leakage event is first generated, the baseline value of the file descriptor of the corresponding target process is recorded.

[0087] In step S360, eBPF is used to monitor the value of newly allocated file descriptors in the target process. In response to the increment of the newly allocated file descriptor value relative to the baseline value reaching a preset interval threshold, an updated file handle leakage event is regenerated.

[0088] In step S370, the updated file handle leakage event is reported.

[0089] It should be noted that after the file handle leakage event is generated for the first time, the baseline value of the file descriptor of the corresponding target process is recorded. That is, the file descriptor allocation value corresponding to the triggering of the file handle leakage event is used as the baseline value. For example, if the obtained file descriptor is 2105, which exceeds the preset leakage judgment threshold (2000), the baseline value is recorded as 2105.

[0090] A pre-compiled eBPF program continuously monitors the number of newly allocated file descriptors for the target process. If file handle leakage continues, the number of newly allocated file descriptors will keep increasing until the increment of the newly allocated file descriptor value relative to the baseline value reaches a preset interval threshold, at which point an updated file handle leakage event is generated. The preset interval threshold can be a fixed value or dynamically adjusted. For example, it could be 100, meaning that every time the operating system adds 100 file descriptors, an updated file handle leakage event is re-reported. This creates a "dynamic profile" of the leaking process, allowing operations personnel to intuitively determine whether the leakage is growing linearly, exponentially, or has stabilized, thus more accurately assessing the risk level. Compared to alerting for every file descriptor increase (leading to an alert storm) or only alerting once (resulting in missing information), periodic reporting based on an incremental threshold achieves a good balance between timeliness and noise control, ensuring that critical information is continuously delivered without overwhelming users.

[0091] In some exemplary embodiments of this disclosure, a file handle leakage monitoring method is provided, in Figure 1 or Figure 3 Based on the process shown, it also includes: after the user-mode monitoring daemon first receives a file handle leakage event, it uses the user-mode monitoring daemon to start a leakage monitoring timer for the corresponding target process; within the timeout period of the leakage monitoring timer, it triggers the collection of the target process's runtime context information.

[0092] In practice, the collection of runtime context information of the target process is triggered, including: collecting the function call stack (Stack Trace) information of the target process in kernel mode and / or user mode, and generating leak diagnostic data based on the function call stack information.

[0093] It should be noted that the timeout period of the leak monitoring timer can be set to a fixed duration, such as 20 minutes. Within this time window, runtime information of the target process can be continuously or periodically collected to locate leaked code. eBPF's stack trace support, combined with kprobe hooks at system call entry points such as sys_open and sys_socket, can be used to collect kernel stack traces, directly pinpointing which kernel path opened the file descriptor (fd). eBPF's uprobe hooks can be used at libc functions such as fopen, socket, and connect, or language-specific APIs (such as Java's Socket). <init>The system collects user-mode call stack traces to pinpoint which line of application code opened the resource. The collected function call stack information is then correlated with file descriptor (fd) values ​​to generate structured data, which is the leak diagnostic data.

[0094] Accordingly, the file handle leakage monitoring method provided in this disclosure further includes: in response to the user-mode monitoring daemon not receiving a file handle leakage event for the target process within the timeout period of the leakage monitoring timer, after the leakage monitoring timer expires, using the user-mode monitoring daemon to control the eBPF to reset the monitoring state of the target process to a non-crawling state. By sending a state update instruction to the eBPF program in the kernel, or updating the shared configuration state, the eBPF program resets the monitoring state of the corresponding target process to a non-crawling state, that is, stops the collection of the call stack, thereby reducing the runtime performance interference to the target process.

[0095] It should be noted that after generating the leak diagnostic data, the system needs to perform leak processing on the file handle leak. In an exemplary embodiment of this disclosure, a closed-loop leak processing can be formed through collaboration with a cloud platform, thereby improving the processing speed and effectiveness of file handle leaks.

[0096] In some embodiments of this disclosure, a file handle leakage monitoring method is provided, which further includes: using a user-space monitoring daemon to generate a leakage monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process; and uploading the leakage monitoring log to a cloud platform.

[0097] It should be noted that the log collection process is automated, automatically capturing relevant runtime logs and diagnostic information and uploading them to the cloud platform for centralized analysis and alerting. Runtime context information may include: leak diagnostic data, resource metrics such as memory usage and CPU utilization, and fragments of key business logs. The leak monitoring logs are then uploaded to the cloud platform in packaged form via encrypted channels (such as HTTPS and TLS). This can be achieved through methods such as batch uploading to reduce network overhead, resuming interrupted uploads, and compressed transmission to improve efficiency.

[0098] In some exemplary embodiments disclosed herein, the cloud platform can receive log data uploaded from multiple hosts, perform centralized analysis, visualization, automated response, and promote problem closure. The uploaded log data can be parsed, key fields extracted, and stored in the corresponding database for subsequent analysis. Big data technologies are used to perform in-depth analysis of the logs, such as: Pattern recognition: identifying common leakage patterns, such as frequent socket creation and opening files without closing them; Root cause localization: locating the source function of the leak through stack trace analysis; Trend analysis: statistically analyzing the leakage frequency of different business modules and service teams, generating heatmaps for intuitive perception by operations and maintenance personnel; Correlation analysis: associating file descriptor (fd) leaks with other resource anomalies (such as memory growth) to determine if it is a complex problem.

[0099] The cloud platform can also locate the root cause, notify the relevant business personnel of the file handle leakage, receive their feedback on the handling solution, generate a leakage handling strategy based on the feedback and distribute it to the corresponding host for abnormal recovery handling, and determine whether the leakage has been resolved based on the subsequently uploaded leakage monitoring logs, thus forming a closed-loop monitoring and recovery process.

[0100] Accordingly, the file handle leakage monitoring method provided in this disclosure also includes: receiving a leakage handling strategy issued by a cloud platform, and using a user-mode monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling strategy.

[0101] It should be noted that leak handling strategies may include: Proactively closing abnormal file descriptors: specifying the closure of certain types of unreleased file descriptors (such as sockets that have not been read or written for a long time). Restarting the target process: performing a secure restart on processes confirmed to have serious leaks. Rate limiting or isolation: temporarily reducing the business traffic of the process to prevent further resource exhaustion.

[0102] A user-space monitoring daemon running on the target host continuously listens for policy instructions from the cloud platform. After receiving the leak handling policy through a trusted channel, it calls the system interface to perform recovery operations on the target process. After the recovery operation is complete, the monitoring daemon can also report the execution result (success / failure / partial success) to the cloud platform, forming an execution loop.

[0103] This disclosed embodiment reduces manual intervention and improves operational efficiency by distributing policies through a cloud platform and implementing a user-mode monitoring and daemon process recovery mechanism. This reduces manual intervention, improves operational efficiency, and achieves precise governance. A complete governance chain is formed from detection, analysis, decision-making to execution and feedback.

[0104] This disclosed embodiment monitors file descriptor allocation each time, accurately recording the file descriptor growth process. Combined with eBPF context acquisition capabilities, runtime information such as the call stack and process state that triggered the allocation can be obtained synchronously. This provides high-precision diagnostic data for subsequent root cause analysis of the cloud platform, helping to quickly locate the specific code path of unclosed resources and improving problem-solving efficiency. In contrast, traditional polling methods can only provide a snapshot at a certain moment, making it difficult to trace the complete leakage process.

[0105] This disclosure also provides a method for monitoring file handle leakage, such as... Figure 4 As shown, the file handle leakage monitoring method can be applied to cloud platforms.

[0106] like Figure 4 As shown, the steps include the following.

[0107] In step S410, at least one leak monitoring log reported by a target host is received.

[0108] It should be noted that the leakage monitoring log is generated by the user-space monitoring daemon running on the target host, which controls eBPF to monitor file handle allocation events and determines when a file handle leakage event occurs. The generation process of the leakage monitoring log on the target host has been specifically described in the above embodiments and will not be repeated here.

[0109] In step S420, root cause analysis is performed based on the leakage monitoring logs to obtain leakage analysis results.

[0110] It should be noted that the leak monitoring log is a structured data packet generated by the eBPF program on the target host and the user-space monitoring daemon and reported to the cloud platform. It may include: basic event information (timestamp, target process identifier PID, target process name, target host name, user identifier, etc.), resource usage trends (the growth curve of file descriptor values, the fd value when the leak judgment threshold is first triggered, and subsequent incremental reporting records), and runtime context information (kernel-space call stack, user-space call stack).

[0111] The cloud platform can normalize and parse at least one leak monitoring log, aggregating leak events by dimensions such as process name, service name, deployment cluster, and time period. It performs cluster analysis on the call stacks of multiple leak events, matching the clustering results with a known leak pattern library to determine the leak type, such as "resource not released" or "child process inheritance leak."

[0112] In some embodiments of this disclosure, the leak monitoring log carries the runtime context information of the target process corresponding to the leak. Step S420 may specifically include: performing root cause analysis on the runtime context information to identify the code path or behavior pattern leading to the file handle leak. Based on the call stack, the code function or call point most likely to cause the leak can be located. Furthermore, code repository information can be combined to associate with maintenance personnel or assess the severity of the leak. This allows the system to automatically output actionable root cause conclusions without manual log review and supports rapid decision generation.

[0113] Accordingly, the file handle leakage monitoring method provided in this disclosure further includes: generating a leakage diagnosis report based on the leakage analysis results; wherein the leakage diagnosis report describes the leakage location, the leakage cause, and remediation suggestions. The leakage location indicates the code location where the leakage occurred, and the leakage cause indicates the root cause of the leakage. The remediation suggestions provide specific and actionable code remediation suggestions.

[0114] In specific embodiments, the generated leak diagnosis report supports multiple output formats: PDF / HTML format: for manual review; JSON format: for integration with other systems (such as CI / CD, knowledge base); automatic push: sent to the relevant operation and maintenance personnel or R&D team through email, office software and other channels; associated work order: automatically bound to the defect task and embedded as an attachment.

[0115] In some embodiments of this disclosure, the file handle leakage monitoring method further includes: generating a leakage handling policy and distributing the leakage handling policy to a target host, so that a user-mode monitoring daemon running on the target host can perform anomaly recovery processing based on the leakage handling policy.

[0116] It should be noted that the leakage handling strategy can be automatically generated based on the leakage diagnosis report, or it can be generated by notifying the relevant business personnel of the file handle leakage, receiving their feedback on the handling solution, and generating the leakage handling strategy based on the feedback; or it can be generated by combining the feedback and the leakage diagnosis report and utilizing the processing capabilities of a large model. The embodiments disclosed herein will not be elaborated upon further.

[0117] As can be seen, the file handle leakage monitoring scheme provided in this disclosure offers a real-time, accurate, efficient, and flexible solution. Leveraging eBPF's ability to respond to system events in real time, without waiting for polling cycles, monitoring becomes more timely and responsive. Compared to traditional polling methods that require periodic checks of system status, which may introduce additional performance overhead, eBPF's event-driven nature triggers processing only when an event occurs, thus reducing unnecessary performance loss. Polling methods may miss some instantaneous events due to long polling intervals, while eBPF reduces this risk through real-time monitoring, minimizing data loss and ensuring the integrity of monitoring data. Furthermore, the eBPF program runs in a restricted sandbox environment, ensuring the security of the monitoring process and preventing any impact on system stability. Moreover, through closed-loop monitoring and processing between the host and the cloud platform, big data can be used to monitor and analyze file handle leakage issues, eliminating the need for reproduction and efficiently resolving the problem.

[0118] It should be noted that the acquisition, storage, use, and processing of information or data in this disclosed technical solution comply with the relevant provisions of national laws and regulations.

[0119] Figure 5 This is a file handle leakage monitoring device frame shown in some exemplary embodiments of the present disclosure. Figure 1 . Reference Figure 5 This device is applied to electronic devices and can also be used in vehicles. The file handle leakage monitoring device 500 includes: a value acquisition unit 501, a value comparison unit 502, an event generation unit 503, and an event reporting unit 504.

[0120] The value acquisition unit 501 is used to monitor the allocation event of the file handle and obtain the value of the allocated file descriptor in response to the allocation of the file handle during the operation of the operating system kernel. The numerical comparison unit 502 is used to compare the file descriptor value with the preset leakage judgment threshold. Event generation unit 503 is used to generate a file handle leakage event in response to the file descriptor value exceeding the leakage determination threshold. Event reporting unit 504 is used to report file handle leakage events.

[0121] In some embodiments of this disclosure, the numerical acquisition unit 501 is configured to: The eBPF program is dynamically mounted to the file descriptor mapping function through kernel tracking, and the file handle allocation event is monitored. In response to the call to the function that establishes the file descriptor mapping, the eBPF program is executed to obtain the file descriptor value.

[0122] In some embodiments of this disclosure, a file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value.

[0123] In some embodiments of this disclosure, the event generation unit 503 is configured to: Allocate memory space in the circular buffer managed by eBPF; Fill the memory space with the PID and file descriptor values ​​to construct a file handle leak event; Submit the file handle leak event to the circular buffer.

[0124] In some embodiments of this disclosure, the event reporting unit 504 is configured to: A circular buffer is used to report file handle leakage events from kernel space to a user-space monitoring daemon.

[0125] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: an update reporting unit, configured to: record the baseline value of the file descriptor of the corresponding target process after the file handle leakage event is first generated; monitor the value of the newly allocated file descriptor of the target process using eBPF; and regenerate the updated file handle leakage event in response to the increment of the newly allocated file descriptor value relative to the baseline value reaching a preset interval threshold; and report the updated file handle leakage event.

[0126] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: a context acquisition unit, used for: After the user-space monitoring daemon first receives a file handle leakage event, it starts a leakage monitoring timer for the corresponding target process. Within the timeout period of the leak monitoring timer, the collection of runtime context information of the target process is triggered.

[0127] In some embodiments of this disclosure, the context acquisition unit is configured as follows: Collect function call stack information of the target process in kernel mode and / or user mode, and generate leak diagnostic data based on the function call stack information.

[0128] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: a status reset unit, used for: In response to the user-space monitoring daemon not receiving a file handle leak event for the target process within the timeout period of the leak monitoring timer, the user-space monitoring daemon controls eBPF to reset the monitoring status of the target process to a non-crawling state after the leak monitoring timer expires.

[0129] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: a log uploading unit, used for: The user-space monitoring daemon generates a leak monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process. The leaked monitoring logs were uploaded to the cloud platform.

[0130] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: an exception handling unit, used for: Receive the leakage handling policy issued by the cloud platform, and use the user-space monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling policy.

[0131] Figure 6 This is a file handle leakage monitoring device frame shown in some exemplary embodiments of the present disclosure. Figure 2 . Reference Figure 6 The file handle leakage monitoring device 600 is applied to the cloud platform. The device includes: a data receiving unit 601 and a root cause analysis unit 602.

[0132] The data receiving unit 601 is used to receive leakage monitoring logs reported by at least one target host; wherein, the leakage monitoring logs are generated by the user-space monitoring daemon running on the target host when it controls eBPF to monitor file handle allocation events and determines when a file handle leakage event occurs; The root cause analysis unit 602 is used to perform root cause analysis based on the leak monitoring logs and obtain the leak analysis results.

[0133] In some embodiments of this disclosure, the leakage monitoring log carries the runtime context information of the target process corresponding to the leakage; wherein, the root cause analysis unit 602 is configured to perform root cause analysis on the runtime context information to identify the code path or behavior pattern that caused the file handle leakage.

[0134] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: a data analysis unit, used to: generate a leakage diagnosis report based on the leakage analysis results; wherein the leakage diagnosis report describes the leakage location, leakage cause, and remediation suggestions.

[0135] In some embodiments of this disclosure, the provided file handle leakage monitoring device further includes: a processing policy distribution unit, configured to: generate a leakage handling policy and distribute the leakage handling policy to the target host, so that the user-mode monitoring daemon running on the target host can perform abnormal recovery processing based on the leakage handling policy.

[0136] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0137] Figure 7 This is a block diagram illustrating a vehicle 700 according to an exemplary embodiment. For example, vehicle 700 can be a hybrid vehicle, a non-hybrid vehicle, an electric vehicle, a fuel cell vehicle, or other types of vehicle. Vehicle 700 can be an autonomous vehicle, a semi-autonomous vehicle, or a non-autonomous vehicle.

[0138] Reference Figure 7 The vehicle 700 may include various subsystems, such as an infotainment system 710, a perception system 720, a decision control system 730, a drive system 740, a computing platform 750, and a battery system 760. The vehicle 700 may also include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of the vehicle 700 can be interconnected via wired or wireless means.

[0139] In some embodiments, the infotainment system 710 may include a communication system, an entertainment system, and a navigation system, etc.

[0140] The perception system 720 may include several sensors for sensing information about the environment surrounding the vehicle 700. For example, the perception system 720 may include a global positioning system (which may be GPS, BeiDou, or other positioning systems), an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0141] The decision control system 730 may include a computing system, a vehicle controller, a steering system, a throttle, and a braking system.

[0142] The drive system 740 may include components that provide powered motion to the vehicle 700. In one embodiment, the drive system 740 may include an engine, an energy source, a transmission system, and wheels. The engine may be one or a combination of internal combustion engines, electric motors, and compressed air engines. The engine is capable of converting energy provided by the energy source into mechanical energy.

[0143] Some or all of the functions of vehicle 700 are controlled by computing platform 750. Computing platform 750 may include at least one processor 751 and memory 752, and processor 751 may execute instructions 753 stored in memory 752.

[0144] The processor 751 can be any conventional processor, such as a commercially available CPU. The processor may also include a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system on a chip (SOC), an application-specific integrated circuit (ASIC), or a combination thereof.

[0145] The memory 752 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0146] In addition to instruction 753, memory 752 can also store data, such as road maps, route information, vehicle position, direction, speed, and other data. The data stored in memory 752 can be used by computing platform 750.

[0147] In this embodiment of the disclosure, the processor 751 may execute instructions 753 to complete all or part of the steps of the file handle leakage monitoring method described above.

[0148] In this embodiment of the disclosure, the battery system 760 may include a battery management system (BMS) or the like to provide electrical energy to the vehicle 700.

[0149] In some embodiments of this disclosure, a non-transitory computer-readable storage medium, when instructions in the storage medium are executed by a vehicle's processor, enables the vehicle to perform the file handle leakage monitoring method described above.

[0150] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0151] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.< / init>

Claims

1. A method for monitoring file handle leakage, characterized in that, include: During the operation of the operating system kernel, in response to the allocation of file handles, the extended Berkeley packet filter eBPF is used to monitor the allocation event of file handles and obtain the value of the allocated file descriptor. Compare the file descriptor value with a preset leakage detection threshold; A file handle leakage event is generated in response to the file descriptor value exceeding the leakage determination threshold; Report the aforementioned file handle leak incident.

2. The file handle leakage monitoring method according to claim 1, characterized in that, In response to file handle allocation, the extended Berkeley packet filter eBPF is used to monitor file handle allocation events and obtain the allocated file descriptor value, including: The eBPF program is dynamically mounted to the file descriptor mapping function via kernel tracking to monitor the allocation events of the file handle; In response to the invocation of the file descriptor mapping function, the eBPF program is executed to obtain the file descriptor value.

3. The file handle leakage monitoring method according to claim 1, characterized in that, The file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value.

4. The file handle leakage monitoring method according to claim 3, characterized in that, Generate file handle leakage events, including: Allocate memory space for the circular buffer managed by the eBPF; The PID and the file descriptor value are filled into the memory space to construct the file handle leakage event; The file handle leak event is submitted to the circular buffer.

5. The file handle leakage monitoring method according to claim 4, characterized in that, Also includes: Generate the file handle leakage event identifier; The file handle leakage event also includes: the file handle leakage event identifier.

6. The file handle leakage monitoring method according to claim 4 or 5, characterized in that, Report the aforementioned file handle leakage incidents, including: The circular buffer is used to report the file handle leakage event from kernel mode to the user-mode monitoring daemon.

7. The file handle leakage monitoring method according to claim 6, characterized in that, The circular buffer is used to report the file handle leakage event from kernel mode to the user-mode monitoring daemon, including: The user-mode monitoring daemon asynchronously reads the file handle leakage event from the circular buffer.

8. The file handle leakage monitoring method according to claim 6, characterized in that, Also includes: After the file handle leakage event is first generated, the baseline value of the file descriptor of the corresponding target process is recorded; The eBPF is used to monitor the value of newly allocated file descriptors of the target process. In response to the increment of the value of newly allocated file descriptors relative to the baseline value reaching a preset interval threshold, an updated file handle leakage event is regenerated. The updated file handle leakage incident was reported.

9. The file handle leakage monitoring method according to claim 7 or 8, characterized in that, Also includes: After the user-mode monitoring daemon first receives the file handle leakage event, it starts a leakage monitoring timer for the corresponding target process using the user-mode monitoring daemon. Within the timeout period of the leak monitoring timer, the collection of runtime context information of the target process is triggered.

10. The file handle leakage monitoring method according to claim 9, characterized in that, Triggering the collection of runtime context information of the target process, including: Collect the function call stack information of the target process in kernel mode and / or user mode, and generate leak diagnostic data based on the function call stack information.

11. The file handle leakage monitoring method according to claim 9, characterized in that, Also includes: In response to the user-mode monitoring daemon not receiving a file handle leakage event for the target process within the timeout period of the leakage monitoring timer, after the leakage monitoring timer expires, the user-mode monitoring daemon controls the eBPF to reset the monitoring status of the target process to a non-crawling state.

12. The file handle leakage monitoring method according to claim 9, characterized in that, Also includes: The user-mode monitoring daemon generates a leak monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process. The leaked monitoring logs were uploaded to the cloud platform.

13. The file handle leakage monitoring method according to claim 12, characterized in that, Also includes: The system receives the leakage handling policy issued by the cloud platform and uses the user-space monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling policy.

14. A method for monitoring file handle leakage, characterized in that, include: Receive at least one leak monitoring log reported by a target host; wherein, the leak monitoring log is generated by a user-space monitoring daemon running on the target host when it controls eBPF to monitor file handle allocation events and determines that a file handle leak event has occurred; Root cause analysis was performed based on the leak monitoring logs to obtain the leak analysis results.

15. The file handle leakage monitoring method according to claim 14, characterized in that, The leak monitoring log carries the runtime context information of the target process corresponding to the leak; The root cause analysis based on the leak monitoring logs includes: Root cause analysis is performed on the runtime context information to identify the code paths or behavior patterns that lead to file handle leakage.

16. The file handle leakage monitoring method according to claim 14, characterized in that, Also includes: Based on the leak analysis results, a leak diagnosis report is generated; The leak diagnosis report describes the location of the leak, the cause of the leak, and remediation recommendations.

17. The file handle leakage monitoring method according to claim 14, characterized in that, Also includes: A leak handling policy is generated and distributed to the target host so that the user-space monitoring daemon running on the target host can perform anomaly recovery processing based on the leak handling policy.

18. A file handle leakage monitoring device, characterized in that, include: The value acquisition unit is used to monitor the file handle allocation event and obtain the allocated file descriptor value in response to the allocation of file handles during the operation of the operating system kernel. A numerical comparison unit is used to compare the file descriptor value with a preset leakage determination threshold. An event generation unit is used to generate a file handle leakage event in response to the file descriptor value exceeding the leakage determination threshold. The event reporting unit is used to report the file handle leakage event.

19. The file handle leakage monitoring device according to claim 18, characterized in that, The value acquisition unit is configured as follows: The eBPF program is dynamically mounted to the file descriptor mapping function via kernel tracking to monitor the allocation events of the file handle; In response to the invocation of the file descriptor mapping function, the eBPF program is executed to obtain the file descriptor value.

20. The file handle leakage monitoring device according to claim 18, characterized in that, The file handle leakage event includes at least: the target process identifier (PID) that triggered the leakage event and the file descriptor value.

21. The file handle leakage monitoring device according to claim 20, characterized in that, The event generation unit is configured as follows: Allocate memory space for the circular buffer managed by the eBPF; The PID and the file descriptor value are filled into the memory space to construct the file handle leakage event; The file handle leak event is submitted to the circular buffer.

22. The file handle leakage monitoring device according to claim 21, characterized in that, The event reporting unit is configured as follows: The circular buffer is used to report the file handle leakage event from kernel mode to the user-mode monitoring daemon.

23. The file handle leakage monitoring device according to claim 22, characterized in that, Also includes: The update reporting unit is used for: After the file handle leakage event is first generated, the baseline value of the file descriptor of the corresponding target process is recorded; The eBPF is used to monitor the value of newly allocated file descriptors of the target process. In response to the increment of the value of newly allocated file descriptors relative to the baseline value reaching a preset interval threshold, an updated file handle leakage event is regenerated. The updated file handle leakage incident was reported.

24. The file handle leakage monitoring device according to claim 23, characterized in that, Also includes: Context acquisition unit, used for: After the user-mode monitoring daemon first receives the file handle leakage event, it starts a leakage monitoring timer for the corresponding target process using the user-mode monitoring daemon. Within the timeout period of the leak monitoring timer, the collection of runtime context information of the target process is triggered.

25. The file handle leakage monitoring device according to claim 23, characterized in that, Also includes: The log upload unit is used for: The user-mode monitoring daemon generates a leak monitoring log based on the collected runtime context information of the target process and the file handle leakage event corresponding to the target process. The leaked monitoring logs were uploaded to the cloud platform.

26. The file handle leakage monitoring device according to claim 25, characterized in that, Also includes: The exception handling unit is used for: The system receives the leakage handling policy issued by the cloud platform and uses the user-space monitoring daemon to perform abnormal recovery processing on the target process based on the leakage handling policy.

27. A file handle leakage monitoring device, characterized in that, include: A data receiving unit is used to receive leakage monitoring logs reported by at least one target host; wherein, the leakage monitoring logs are generated by a user-space monitoring daemon running on the target host when it controls eBPF to monitor file handle allocation events and determines that a file handle leakage event has occurred; The root cause analysis unit is used to perform root cause analysis based on the leakage monitoring logs to obtain leakage analysis results.

28. The file handle leakage monitoring device according to claim 27, characterized in that, The leak monitoring log carries the runtime context information of the target process corresponding to the leak; The root cause analysis unit is configured as follows: Root cause analysis is performed on the runtime context information to identify the code paths or behavior patterns that lead to file handle leakage.

29. The file handle leakage monitoring device according to claim 27, characterized in that, Also includes: Data analysis unit, used for: Based on the leak analysis results, a leak diagnosis report is generated; The leak diagnosis report describes the location of the leak, the cause of the leak, and remediation recommendations.

30. The file handle leakage monitoring device according to claim 27, characterized in that, Also includes: The processing strategy distribution unit is used for: A leak handling policy is generated and distributed to the target host so that the user-space monitoring daemon running on the target host can perform anomaly recovery processing based on the leak handling policy.

31. A vehicle, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the file handle leakage monitoring method according to any one of claims 1 to 13.

32. A non-transitory computer-readable storage medium, wherein, when instructions in the storage medium are executed by a processor of a vehicle, the vehicle is enabled to perform a file handle leakage monitoring method according to any one of claims 1 to 13.

Images