A dynamic flow packet collection method and device, electronic equipment and storage medium

Abstract

A dynamic packet capture method, apparatus, electronic device, and storage medium, relating to the field of network security technology, are disclosed. The method includes: establishing a memory policy runtime table in the main control process, serving as the sole authoritative source for all packet capture tasks; upon receiving a temporary packet capture task request triggered by anomaly detection rules, creating and maintaining corresponding temporary capture task information in the memory policy runtime table and the kernel's eBPF flow hash map table, without persistently writing it to a configuration file; serially updating the memory policy runtime table through a unique execution coroutine within the main control process, and issuing task control instructions to the packet capture plugin via narrow instruction set; and receiving and parsing the task control instructions through an independent execution coroutine within the packet capture plugin, updating the eBPF flow hash map table in an idempotent manner to trigger or stop packet capture. Implementing this technical solution improves the reliability and efficiency of packet capture.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to a method, apparatus, electronic device, and storage medium for collecting dynamic traffic packets. Background Technology

[0002] Dynamic packet capture technology based on Extended Berkeley Packet Filter (eBPF) has been widely applied in network monitoring, security analysis, and fault diagnosis. Existing dynamic packet capture systems typically manage temporary capture tasks using persistent configuration files or shared memory synchronization, and rely on shared queues or full policy synchronization for communication in multi-plugin collaborative scenarios. However, these methods suffer from the following problems: high-frequency triggered temporary tasks easily lead to configuration file input / output storms and configuration inconsistencies; concurrent updates to the policy table by multiple threads or coroutines can cause state inconsistencies; and the use of global mapping table synchronization or shared queue communication between multiple plug-ins results in high communication overhead, potential state inconsistencies, and a lack of a unified task serialization control mechanism, leading to uncontrolled task growth and uncontrollable system resource consumption, making it difficult to meet the stable and efficient traffic capture requirements under high load scenarios. Therefore, the packet capture methods in these technologies suffer from low reliability and struggle to meet the stable and efficient traffic capture requirements under high load scenarios. Summary of the Invention

[0003] To address the aforementioned technical problems, this application provides a dynamic traffic packet acquisition method, apparatus, electronic device, and storage medium.

[0004] Firstly, this application provides a dynamic packet acquisition method, comprising: establishing a memory policy runtime table in the main control process, wherein the memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all packet acquisition tasks; when a temporary packet acquisition task request triggered by an anomaly detection rule is received, creating and maintaining corresponding temporary acquisition task information in the memory policy runtime table and the kernel's eBPF flow hash mapping table, wherein the temporary acquisition task information is not persistently written to a configuration file; serially updating the memory policy runtime table through a unique execution coroutine within the main control process, and issuing task control instructions to independently running packet acquisition plugins through narrow instructions based on the update results, wherein the narrow instructions contain the minimum task information required to drive the packet acquisition plugins to perform operations; receiving and parsing the task control instructions through an independent execution coroutine within the packet acquisition plugins, and updating the eBPF flow hash mapping table in an idempotent manner according to the task control instructions to trigger or stop packet acquisition.

[0005] By adopting the above technical solutions, a memory policy runtime table is established as the sole authoritative source for all traffic packet collection tasks, avoiding configuration file input / output storms and configuration inconsistencies. Temporary collection task information is not persistently written to configuration files, further reducing the burden on configuration files. A single execution coroutine within the main control process serially updates the memory policy runtime table, avoiding state inconsistencies caused by concurrent updates of the policy table by multiple threads or coroutines. Narrow instructions contain minimal task information, reducing communication overhead. The traffic packet collection plugin updates the eBPF flow hash mapping table in an idempotent manner, avoiding redundant collection tasks and system resource consumption. Overall, this improves the reliability and efficiency of traffic packet collection, meeting the stable and efficient traffic collection requirements under high-load scenarios.

[0006] Optionally, the above method also includes: after the traffic packet collection plugin re-establishes a connection with the main control process, synchronizing the set of active tasks in the memory policy runtime table to the traffic packet collection plugin by receiving a synchronization instruction sent by the main control process.

[0007] By adopting the above technical solution, after the traffic packet acquisition plugin and the main control process re-establish a connection, the active task set in the memory policy runtime table can be synchronized to the traffic packet acquisition plugin, realizing the synchronization of task information between the traffic packet acquisition plugin and the main control process, ensuring system state consistency, avoiding the loss or inconsistency of task information due to connection interruption, and improving recovery capability and system reliability.

[0008] Optionally, the memory policy runtime table includes: a task mapping table storing all active traffic packet collection tasks with task identifier as the key; an active task set mapping table storing reference counts of multiple task sources corresponding to the same network flow with flow hash value as the key; a deduplication cooldown timer mapping table with task source, traffic anomaly rule identifier, and flow hash value as the key; a bounded inter-process communication instruction queue for controlling the rate at which the main control process issues instructions to the traffic packet collection plugin; a token bucket rate limiter for limiting the number of newly created traffic packet tasks per second; and a resource hard limit configuration snapshot containing the maximum number of concurrent tasks, the maximum duration of a single task, and the maximum number of packets per single task.

[0009] By adopting the above technical solutions, the task mapping table can clearly store all active traffic packet collection tasks, facilitating management; the active task set mapping table uses a reference counting mechanism to accurately record multiple task sources corresponding to the same network flow, making it easy to manage task termination and entry deletion; the deduplication cooldown timer mapping table can deduplicate repeated collection requests for the same network flow triggered by the same source, avoiding duplicate collection; the bounded inter-process communication instruction queue can control the rate at which the main control process issues instructions to the traffic packet collection plugin, preventing instruction backlog; the token bucket rate limiter can limit the number of newly created traffic packet tasks per second, preventing disorderly task growth; and the resource hard limit configuration snapshot can impose hard constraints on system resources, ensuring stable system operation.

[0010] Optionally, the temporary collection of task information should include at least the task identifier, stream hash value, task source, creation time, expiration time, and task status. The task source may be issued by the platform, triggered by network traffic anomaly detection rules, or configured manually locally.

[0011] By adopting the above technical solution, the temporary collection of task information includes task identifier, stream hash value, task source, creation time, expiration time and task status, which can clearly define the specific information of the task and facilitate task management and tracking. The task source includes platform-side distribution, network traffic anomaly detection rule linkage triggering or local manual configuration, which enriches the task source and can meet the traffic packet collection needs in different scenarios.

[0012] Optionally, the traffic packet collection task corresponding to the temporary collection task information follows a lifecycle state machine including pending, active, stopping, and stopped states. Among them, the pending state indicates that the task has been accepted but the activation time has not yet arrived, and the unified time wheel in the only execution coroutine in the main control process is responsible for the timed activation; the active state indicates that a start command has been issued to the traffic packet collection plugin through narrow instructions, and the traffic packet collection plugin has updated the eBPF flow hash mapping table and started packet capture; the stopping state is entered when the task termination condition is met, triggering the issuance of a stop command to the traffic packet collection plugin through narrow instructions; the stopped state indicates that the eBPF flow hash mapping table has been cleaned up and the snapshot has been updated, and the task has been removed from the memory policy runtime table.

[0013] By adopting the above technical solution, the traffic packet collection tasks corresponding to temporary collection tasks can follow a clear lifecycle state machine. The pending state tasks are activated on a timed basis with the help of a unified time wheel to ensure timely start-up. The active state accurately issues start-up commands and updates the eBPF flow hash mapping table to trigger the packet capture service. The stopping state can stop the task in a timely manner according to the task end conditions. The stopped state can clean up the eBPF flow hash mapping table, update the snapshot, and remove the task. This improves the orderliness and controllability of traffic packet collection tasks, better manages system resources, and meets the stable and efficient traffic collection requirements under high load scenarios.

[0014] Optionally, the task termination conditions include at least one of the following: the task duration reaches the preset expiration time; the number of packets captured reaches the maximum number of packets in a single task; the task is canceled by the platform; the reference count of the same stream hash value reaches zero.

[0015] By adopting the above technical solution, various situations in which traffic packet collection tasks corresponding to temporary collection tasks end are clarified, including the task duration reaching the preset expiration time, the number of packets captured reaching the maximum number of packets in a single task, the task being canceled by the platform, and the reference count of the same stream hash value returning to zero. This enables precise control over the termination of traffic packet collection tasks, avoids disorderly growth of tasks, ensures reasonable use of system resources, and improves the reliability and stability of the traffic collection system.

[0016] Optionally, the narrow instructions include the pcap_capture_task_start, pcap_capture_task_stop, and pcap_capture_task_sync instructions. The pcap_capture_task_start instruction is used to issue a start or refresh command to the packet capture plugin, including the task identifier, flow hash value, task duration, maximum number of packets per task, and expiration time. The pcap_capture_task_stop instruction is used to stop the capture task based on the task identifier and flow hash value, and supports decrementing the reference count, where the reference count represents the count of multiple task sources corresponding to the same network flow. The pcap_capture_task_sync instruction is used to batch synchronize active tasks in the memory policy runtime table after the packet capture plugin re-establishes a connection with the main control process, achieving idempotent recovery.

[0017] By adopting the above technical solutions, the `pcap_capture_task_start` command can issue start or refresh collection tasks to the traffic packet collection plugin, containing necessary task information, and can accurately drive the plugin to start or refresh tasks; the `pcap_capture_task_stop` command can stop the collection task according to the task identifier and stream hash value, and supports the reference count decrement operation, which is convenient for managing multiple task sources corresponding to the same network stream; the `pcap_capture_task_sync` command can batch synchronize active tasks in the memory policy runtime table after the traffic packet collection plugin re-establishes a connection with the main control process, realize idempotent recovery, and ensure system state consistency.

[0018] Optionally, the above method also includes: imposing hard constraints on system resources through the resource protection mechanism built into the memory policy runtime table, wherein the resource protection mechanism includes at least one of the following: hard limit verification of the number of global concurrent tasks; verification of single task duration, maximum number of packets per single task, and number of bytes per packet; linkage storm protection based on the deduplication cooldown timer mapping table; rate limit of new tasks based on the token bucket rate limiter; backpressure drop count of the bounded inter-process communication instruction queue; and reconciliation and recovery through synchronization instructions after the traffic packet collection plugin reconnects.

[0019] By adopting the above technical solutions, the resource protection mechanism built into the memory strategy runtime table is used to impose hard constraints on system resources. The hard limit check of the number of global concurrent tasks can prevent too many concurrent tasks from exhausting system resources. The checks of single task duration, maximum number of packets per task, and number of bytes per packet can prevent a single task from excessively occupying resources. The linkage storm protection based on the deduplication cooldown timer mapping table and the new task rate limit based on the token bucket rate limiter can prevent the system from overloaded due to excessively fast task requests. The backpressure drop count of the bounded inter-process communication instruction queue can prevent instruction backlog from causing unbounded memory growth. After the traffic packet collection plugin reconnects, it performs accurate reconciliation and recovery through synchronous instructions to ensure the consistency and accuracy of task status, improve the stability and reliability of the system, and meet the stable and efficient traffic collection requirements under high load scenarios.

[0020] Optionally, the active task set mapping table adopts a reference counting mechanism. When the same stream hash value corresponds to multiple task sources, the reference count is incremented; when the collection task of one of the task sources ends, the reference count is decremented by one; when the reference count reaches zero, the corresponding stream hash value entry is deleted from the eBPF stream hash mapping table.

[0021] By adopting the above technical solution and utilizing the reference counting mechanism of the active task set mapping table, the situation where the same stream hash value corresponds to multiple task sources can be accurately counted. When the collection task of a task source ends, the reference count can be updated in a timely manner. When the reference count reaches zero, the corresponding entry is deleted from the eBPF stream hash mapping table, thereby achieving effective cleanup of the eBPF stream hash mapping table, avoiding unnecessary resource occupation, and improving system resource utilization efficiency.

[0022] Optionally, the deduplication cooldown timer mapping table uses a combination key of task source, traffic anomaly rule identifier, and flow hash value to deduplicate repeated collection requests triggered by the same source and the same network flow within a preset cooldown period. Deduplication processing is used to indicate that only the first request is accepted and a collection task is created, and subsequent repeated requests are discarded within the cooldown period.

[0023] By adopting the above technical solution, the deduplication cooling timer mapping table uses a specific combination key to deduplicate repeated collection requests of the same network flow triggered by the same source within a preset cooling time, avoiding the repeated creation of collection tasks, reducing redundant occupation of system resources, improving system resource utilization efficiency, and enhancing the system's ability to collect traffic stably and efficiently under high load scenarios.

[0024] Optionally, the above method also includes: when the main control process issues task control instructions to the traffic packet collection plugin, rate control and back pressure management are performed through a bounded inter-process communication instruction queue. When the depth of the instruction queue reaches the preset upper limit, the newly arrived instruction requests are dropped under back pressure and the drop count is recorded to avoid unbounded memory growth caused by instruction backlog.

[0025] By adopting the above technical solution, the system uses a bounded inter-process communication instruction queue to control the rate and back pressure of the task control instructions issued by the main control process to the traffic packet acquisition plugin. When the instruction queue depth reaches the preset upper limit, the newly arrived instruction requests are discarded under back pressure and the discard count is recorded. This avoids the unbounded growth of memory caused by instruction backlog and improves system stability and the controllability of resource usage.

[0026] Optionally, updating the eBPF flow hash map table in an idempotent manner includes: when the traffic packet collection plugin receives the same task control instruction repeatedly, it does not create a new traffic collection task repeatedly, but only verifies and synchronizes the running status and lifecycle parameters of the existing tasks in the eBPF flow hash map table, so as to avoid generating duplicate collection tasks and redundant occupation of system resources.

[0027] By adopting the above technical solution, when the traffic packet collection plugin repeatedly receives the same task control instruction, it does not create new traffic collection tasks repeatedly. Instead, it only verifies and synchronizes the running status and lifecycle parameters of existing tasks in the eBPF flow hash mapping table, thus avoiding duplicate collection tasks and redundant occupation of system resources.

[0028] In a second aspect of this application, a dynamic packet acquisition device is also provided for executing the dynamic packet acquisition method described above, comprising: a setup module for establishing a memory policy runtime table in the main control process, wherein the memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all packet acquisition tasks; a creation module for creating and maintaining corresponding temporary acquisition task information in the memory policy runtime table and the kernel's eBPF flow hash map table when a temporary packet acquisition task request triggered by an anomaly detection rule is received, wherein the temporary acquisition task information is not persistently written to a configuration file; a processing module for serially updating the memory policy runtime table through a unique execution coroutine within the main control process, and issuing task control instructions to independently running packet acquisition plugins through narrow instructions based on the update results, wherein the narrow instructions contain minimal task information required to drive the packet acquisition plugins to perform operations; and an acquisition module for receiving and parsing the task control instructions through an independent execution coroutine within the packet acquisition plugins, and updating the eBPF flow hash map table in an idempotent manner according to the task control instructions to trigger or stop packet acquisition.

[0029] In a third aspect of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor executes the program to implement the method steps of any of the above claims.

[0030] In a fourth aspect of this application, a computer-readable storage medium is also provided, which stores instructions that, when executed, perform the method steps of any of the above claims.

[0031] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. Establish a runtime table for the memory policy as the sole authoritative source for all traffic packet collection tasks. Temporary collection task information is not persistently written to the configuration file to avoid input / output storms and configuration inconsistencies caused by frequently triggered temporary tasks. 2. The memory policy runtime table is updated serially by a single execution coroutine within the main control process, avoiding inconsistency issues caused by concurrent updates of the policy table by multiple threads or coroutines. 3. Narrow instruction sets are used to send task control commands to the traffic packet acquisition plugin, reducing communication overhead. The traffic packet acquisition plugin updates the eBPF stream hash mapping table in an idempotent manner, avoiding duplicate acquisition tasks and redundant system resource occupation. At the same time, the built-in resource protection mechanism in the memory strategy runtime table imposes hard constraints on system resources, solving the problems of disordered task growth and uncontrollable system resource occupation, and meeting the stable and efficient traffic acquisition requirements under high load scenarios. Attached Figure Description

[0032] Figure 1 This is a flowchart of a dynamic traffic packet collection method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the lifecycle state machine process provided in an embodiment of this application; Figure 3 This is a timing diagram showing the interaction between the main control program and the traffic acquisition plugin provided in the embodiments of this application; Figure 4 This is a structural block diagram of a dynamic traffic packet acquisition device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0033] Explanation of reference numerals in the attached figures: 500 - Electronic device; 501 - Processor; 502 - Communication bus; 503 - User interface; 504 - Network interface; 505 - Memory. Detailed Implementation

[0034] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0035] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0036] In the description of the embodiments of this application, the term "multiple" means two or more. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0037] This application provides a method for dynamic traffic packet collection, referring to... Figure 1 , Figure 1 This is a flowchart of a dynamic traffic packet collection method provided in an embodiment of this application, including the following steps: Step S101: Establish a memory policy runtime table in the main control process. The memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all traffic packet collection tasks. Step S102: When a temporary traffic packet collection task request triggered by the anomaly detection rule is received, the corresponding temporary collection task information is created and maintained in the memory policy runtime table and the kernel's eBPF flow hash mapping table. The temporary collection task information is not persistently written to the configuration file. Step S103: The memory policy runtime table is serially updated by the unique execution coroutine within the main control process, and task control instructions are sent to the independently running traffic packet acquisition plugin through narrow instructions based on the update results. The narrow instructions contain the minimum task information required to drive the traffic packet acquisition plugin to perform operations. Step S104: Receive and parse task control instructions through an independent execution coroutine within the traffic packet collection plugin, and update the eBPF flow hash mapping table in an idempotent manner according to the task control instructions to trigger or stop traffic packet collection.

[0038] Through the above steps, a memory policy runtime table is established as the sole authoritative source for all traffic packet collection tasks, avoiding configuration file input / output storms and configuration inconsistencies. Temporary collection task information is not persistently written to configuration files, further reducing the burden on configuration files. A single execution coroutine within the main control process serially updates the memory policy runtime table, avoiding state inconsistencies caused by concurrent updates of the policy table by multiple threads or coroutines. Narrow instructions contain minimal task information, reducing communication overhead. The traffic packet collection plugin updates the eBPF flow hash mapping table in an idempotent manner, avoiding redundant collection tasks and system resource consumption. Overall, this improves the reliability and efficiency of traffic packet collection, meeting the stable and efficient traffic collection requirements under high-load scenarios.

[0039] This embodiment provides a dynamic traffic packet acquisition implementation logic based on eBPF architecture. It relies on the main control process to build an independent memory-level policy runtime table and establish a globally unique authoritative data source, abandoning the traditional approach of relying on configuration files to manage temporary acquisition tasks. For temporary packet capture requests triggered by anomaly detection rules, task data is maintained only in the user-space memory policy runtime table and the kernel eBPF flow hash mapping table, without writing temporary task information to disk configuration files. The main control process uses a dedicated single execution coroutine to serially manage policy table updates, avoiding data corruption caused by concurrent read / write operations by multiple coroutines. Control commands are then sent to independently deployed traffic packet acquisition plugins using a narrow-instruction lightweight communication mode. The traffic packet acquisition plugins, relying on their own independent execution coroutines to parse commands, update the kernel eBPF flow hash mapping table using idempotent logic, precisely controlling the start and stop of traffic packet acquisition. This solution addresses issues such as configuration file I / O storms, inconsistent configurations, multi-coroutine state disorder, high plugin communication overhead, and redundant execution of repetitive tasks in related technologies. It achieves orderly task management under high load, lightweight communication, and non-redundant acquisition behavior, improving the overall reliability and operational stability of traffic acquisition. In this embodiment, the master control process is the core management process in the multi-plugin agent architecture, responsible for task reception, policy management, instruction issuance, and global state coordination. The memory policy runtime table is a structured dataset deployed in the master control process's memory, not persisted to disk. It serves as the sole benchmark data source for the status, parameters, and management rules of all packet capture tasks across the entire system, and all plugins and the kernel rely on this table's information. Anomaly detection rules are pre-defined traffic identification rules in the network security field, used to identify illegal traffic such as attacks and abnormal access. The eBPF flow hash mapping table is a hash data table built on eBPF at the kernel level, indexed by traffic feature hash values, controlling kernel traffic packet capture permissions. When a security rule identifies abnormal traffic and initiates a temporary packet capture request, it simultaneously registers and maintains task data in both the user-space memory table and the kernel eBPF mapping table, without writing temporary tasks to disk configuration files, thus avoiding the risks associated with frequent configuration file rewriting. Serial updates refer to processing only one task's add, modify, or cancel operation at a time, executing them sequentially in a queue. Narrow instructions refer to lightweight communication instructions that eliminate redundant business data and only carry core task control parameters. Minimizing task information represents the necessary core parameters required for plugin management, with no redundant fields. The master control process uses a unique dedicated coroutine to queue and process policy table updates, avoiding concurrency conflicts. Based on the update results, lightweight narrow instructions are used to send control commands to independently deployed acquisition plugins. These commands only carry essential management parameters, reducing communication overhead. The traffic packet acquisition plugin is a functional plugin deployed in an independent process, responsible for receiving master control instructions, operating the kernel eBPF table, and performing traffic packet capture. Idempotent mode means that when the same instruction is received repeatedly, tasks will not be generated repeatedly, and multiple executions will not be triggered; only the execution logic of the status parameters will be synchronized.The traffic packet capture plugin receives and parses control commands through its own dedicated coroutine, updating the kernel eBPF mapping table with idempotent logic to accurately control the start and stop of abnormal traffic packet capture. This embodiment avoids high-frequency disk read / write pressure and configuration drift issues; ensures policy table data consistency through single-coroutine serial updates; significantly reduces inter-process communication overhead with narrow instructions; avoids redundant packet capture and resource waste with idempotent execution logic; and achieves global task state consistency through a unified memory authority source, adapting to stable operation in high-load network scenarios. In this implementation, "narrow instructions" refers to inter-process communication commands that contain only the minimum necessary fields such as task identifier, stream hash value, and task lifecycle constraint parameters, compared to full policy synchronization; their data length is much smaller than traditional policy synchronization messages.

[0040] In an optional embodiment, the method further includes: after the traffic packet acquisition plugin re-establishes a connection with the main control process, synchronizing the set of active tasks in the memory policy runtime table to the traffic packet acquisition plugin by receiving a synchronization instruction sent by the main control process.

[0041] In this embodiment, after the traffic packet acquisition plugin re-establishes a connection with the main control process, the active task set in the memory policy runtime table can be synchronized to the traffic packet acquisition plugin, thereby synchronizing task information between the traffic packet acquisition plugin and the main control process, ensuring system state consistency, avoiding the loss or inconsistency of task information due to connection interruption, and improving recovery capability and system reliability.

[0042] This embodiment provides a state synchronization and fault recovery mechanism. When the traffic packet acquisition plugin loses connection with the main control process due to a fault (such as program crash, node restart, rolling upgrade, etc.), the plugin actively initiates or responds to the synchronization process initiated by the main control process when re-establishing the connection. The main control process queries its memory policy runtime table for all currently active (active or pending) acquisition tasks and sends the complete information of these tasks to the traffic packet acquisition plugin in batches via synchronization commands. After receiving the data, the traffic packet acquisition plugin performs idempotent processing on each synchronized task. If a corresponding entry already exists in the eBPF flow hash mapping table, its parameters are verified and remain unchanged; otherwise, the entry is created. Simultaneously, the traffic packet acquisition plugin checks the differences between its local state and the synchronized tasks, and cleans up the mapping table entries corresponding to tasks that are no longer active. In related technologies, after a plugin crashes or restarts, it cannot detect the globally executing data acquisition tasks, which can easily lead to problems such as interruptions of already executing packet capture tasks, duplicate task creation, and leakage of residual state in the kernel eBPF mapping table. The lack of a precise recovery mechanism results in either excessively long data acquisition interruption windows, resource waste due to repeated packet capture, or continuous resource leakage due to residual garbage entries in the eBPF mapping table. This embodiment achieves precise recovery within seconds after a plugin crash, ensuring that data acquisition tasks are not interrupted or duplicated, and that the eBPF mapping table and the master control policy table remain consistent. Automatic recovery is achieved without manual intervention, significantly improving the system's production-grade availability and operational efficiency; it also greatly enhances the fault tolerance and stability of the entire data acquisition system.

[0043] In an optional embodiment, the memory policy runtime table includes: a task mapping table storing all active traffic packet collection tasks with task identifier as the key; an active task set mapping table storing reference counts of multiple task sources corresponding to the same network flow with flow hash value as the key; a deduplication cooldown timer mapping table with task source, traffic anomaly rule identifier, and flow hash value as the key; a bounded inter-process communication instruction queue for controlling the rate at which the main control process issues instructions to the traffic packet collection plugin; a token bucket rate limiter for limiting the number of newly created traffic packet tasks per second; and a resource hard limit configuration snapshot containing the maximum number of concurrent tasks, the maximum duration of a single task, and the maximum number of packets per single task.

[0044] In this embodiment, the task mapping table clearly stores all active traffic packet collection tasks, facilitating management; the active task set mapping table uses a reference counting mechanism to accurately record multiple task sources corresponding to the same network flow, making it easy to manage task termination and entry deletion; the deduplication cooldown timer mapping table can deduplicate repeated collection requests for the same network flow triggered by the same source, avoiding duplicate collection; the bounded inter-process communication instruction queue can control the rate at which the main control process issues instructions to the traffic packet collection plugin, preventing instruction backlog; the token bucket rate limiter can limit the number of newly created traffic packet tasks per second, preventing disorderly task growth; and the resource hard limit configuration snapshot can impose hard constraints on system resources, ensuring stable system operation.

[0045] The specific internal data structures of the memory policy runtime table constitute the core of policy management in this embodiment. This memory policy runtime table comprises six main components: a task mapping table with task identifiers as keys, an active task set mapping table with stream hash values ​​as keys, a deduplication cooldown timer mapping table with composite keys as keys, a bounded IPC instruction queue for controlling the instruction issuance rate, a token bucket rate limiter for limiting the rate of new task creation, and snapshots containing resource hard cap configurations. The task mapping table uses a unique task ID as the index field to centrally store complete information on all running traffic collection tasks, enabling quick querying, modification, and cancellation of single tasks. The active task set mapping table uses a unique traffic hash value as the index to record request counts from multiple sources such as security rules and platform operations corresponding to the same network traffic, providing data support for multi-task merging and on-demand packet stopping. The deduplication cooldown timer mapping table uses a composite index combining task source, traffic anomaly rule number, and traffic hash value to record the cooldown time for duplicate requests, enabling automatic interception and deduplication of duplicate packet capture requests within a short period. A fixed-capacity instruction queuing queue is set to control the speed at which the main controller issues control instructions to the plugins, preventing instructions from piling up indefinitely. A token bucket mechanism is used to constrain the number of new packet capture tasks that can be created per second, preventing a sudden surge of abnormal requests from causing task explosion. The system retains preset global maximum concurrent tasks, maximum single-task running time, and maximum single-task packet capture count, providing a basis for judgment on resource over-limit interception. These structures work together: the task mapping table stores complete information about all tasks; the active task set mapping table supports reference counting management when the same stream hash value corresponds to multiple task sources; the deduplication cooldown timer mapping table prevents high-frequency linkage events from causing task storms; the bounded IPC queue controls the rate at which the master controller issues instructions to plugins and provides a backpressure mechanism; the token bucket rate limiter controls the total rate of new tasks created across the entire machine; and the resource hard limit configuration snapshot specifies hard constraints such as the maximum number of concurrent tasks, the maximum duration of a single task, and the maximum number of packets. These six main components each perform the functions of task storage, reference counting statistics, request deduplication cooldown, instruction queue management, new task rate limiting, and resource limit baseline configuration, forming a complete task lifecycle management system.

[0046] In an optional embodiment, the active task set mapping table adopts a reference counting mechanism. When the same stream hash value corresponds to multiple task sources, the reference count is incremented; when the collection task of one of the task sources ends, the reference count is decremented by one; when the reference count reaches zero, the corresponding stream hash value entry is deleted from the eBPF stream hash mapping table.

[0047] In this embodiment, the reference counting mechanism of the active task set mapping table can be used to accurately count the number of task sources corresponding to the same stream hash value. When the collection task of a task source ends, the reference count is updated in a timely manner. When the reference count reaches zero, the corresponding entry is deleted from the eBPF stream hash mapping table, thus effectively cleaning up the eBPF stream hash mapping table, avoiding unnecessary resource consumption, and improving system resource utilization efficiency. This embodiment configures a reference counting mechanism for traffic collection tasks corresponding to the same stream hash value. When multiple anomaly detection rules repeatedly initiate temporary traffic packet collection requests for the same stream hash value, only a single collection task record is maintained in the memory policy runtime table and the eBPF stream hash mapping table, and the reference count corresponding to the stream hash value is accumulated. When a single collection task request ends, only the corresponding reference count is decremented until the reference count reaches zero, and then the corresponding task information in the memory policy runtime table and the eBPF stream hash mapping table is cleaned up.

[0048] In an optional embodiment, the deduplication cooldown timer mapping table uses a combination key of task source, traffic anomaly rule identifier, and flow hash value to deduplicate repeated collection requests for the same network flow triggered by the same source within a preset cooldown period. Deduplication processing is used to indicate that only the first request is accepted and a collection task is created, and subsequent repeated requests are discarded within the cooldown period.

[0049] In this embodiment, the deduplication cooldown timer mapping table uses a specific combination key to deduplicate repeated collection requests of the same network flow triggered by the same source within a preset cooldown time. This avoids the repeated creation of collection tasks, reduces redundant system resource usage, improves system resource utilization efficiency, and enhances the system's ability to stably and efficiently collect traffic under high load scenarios.

[0050] This embodiment details the working mechanism of the deduplication cooldown timer mapping table: using a combination key of task source, traffic anomaly rule identifier, and flow hash value, it deduplicates repeated collection requests for the same network flow triggered by the same source within a preset cooldown period. Only the first request is accepted and a collection task is created; subsequent repeated requests are discarded within the cooldown period. In related technologies, in high-frequency linkage scenarios, the same anomaly detection rule may hit the same network flow multiple times in a short period of time (e.g., within a few seconds). If a collection task is created each time, it will lead to task storms and unnecessary resource waste. This embodiment, through the deduplication cooldown mechanism, merges repeated alarms for the same network flow under the same rule into a single collection task, significantly reducing the creation of invalid tasks while ensuring that the first alarm is responded to in a timely manner. The cooldown window period suppresses short-term repeated requests, preventing task storms; it also reduces frequent updates to the policy table and eBPF mapping table, lowering system load and communication overhead. The cooldown time setting (e.g., 60 seconds) is usually longer than the duration of a single collection task, ensuring that the same flow is not repeatedly triggered before a collection task is completed.

[0051] In an optional embodiment, the temporary collection of task information includes at least the task identifier, stream hash value, task source, creation time, expiration time, and task status. The task source may be issued by the platform, triggered by network traffic anomaly detection rules, or configured manually locally.

[0052] In this embodiment, the temporary collection task information includes task identifier, stream hash value, task source, creation time, expiration time, and task status, which can clearly define the specific information of the task and facilitate task management and tracking. The task source includes platform-side distribution, network traffic anomaly detection rule linkage triggering, or local manual configuration, which enriches the task sources and can meet the traffic packet collection needs in different scenarios.

[0053] Temporary task information collection includes at least the task identifier, stream hash value, task source, creation time, expiration time, and task status. This data structure design reflects the lifecycle management requirements of tasks: the task identifier uniquely identifies a task globally; the stream hash value is used to associate it with entries in the kernel eBPF mapping table; the task source distinguishes different trigger sources and affects persistence strategies and permission management; creation time and expiration time together define the task's lifecycle window; and the task status records the current stage of the task. It may also include a backtracking source identifier (traffic anomaly rule identifier), reference count, and the maximum number of packets captured per task. The reference count represents the count of multiple task sources corresponding to the same network flow, used for merging multiple tasks within the same traffic. This standardized task data structure provides a unified data foundation for subsequent state machine management, reference counting, deduplication cooling, and resource control functions, ensuring the consistency and traceability of task information across all processing stages. Furthermore, task sources are categorized into three types: platform-side distribution, anomaly detection rule linkage, and local manual configuration, covering all business scenarios from operational intervention and automatic security identification to on-site manual configuration. In related technologies, the definitions of temporary task fields are often disorganized, key fields are missing, and task sources are not clearly defined, leading to difficulties in task traceability, lack of basis for lifecycle management, and mixed management of tasks from different sources. This can easily result in problems such as accidental task termination, incorrect status, and lack of operational control. This solution standardizes task field specifications and source classification, providing standardized data support for subsequent state machine transitions, expiration determination, reference counting statistics, and task traceability, thereby improving the standardization, traceability, and adaptability of task management across all scenarios.

[0054] In an optional embodiment, the traffic packet collection task corresponding to the temporary collection task information follows a lifecycle state machine including pending, active, stopping, and stopped states. The pending state indicates that the task has been accepted but the activation time has not yet arrived, and it is activated periodically by a unified time wheel in the unique execution coroutine within the main control process. The active state indicates that a start command has been issued to the traffic packet collection plugin via narrow instructions, and the traffic packet collection plugin has updated the eBPF flow hash map and started packet capture. The stopping state is entered when the task termination condition is met, triggering a stop command to be issued to the traffic packet collection plugin via narrow instructions. The stopped state indicates that the task has been removed from the memory policy runtime table after completing the eBPF flow hash map cleanup and snapshot update.

[0055] In this embodiment, the traffic packet collection task corresponding to the temporary collection task information can follow a clear life cycle state machine. The pending state task is activated in a timely manner by a unified time wheel to ensure timely start. The active state accurately issues start instructions and updates the eBPF flow hash mapping table to trigger the packet capture service. The stopping state can stop the task in a timely manner according to the task end condition. The stopped state can clean up the eBPF flow hash mapping table, update the snapshot and remove the task. This improves the orderliness and controllability of the traffic packet collection task, better manages system resources, and meets the stable and efficient traffic collection requirements under high load scenarios.

[0056] This embodiment provides a complete lifecycle state machine for traffic packet capture tasks, including four states: pending, active, stopping, and stopped. The semantics of each state and the triggering conditions for state transitions are explained in detail. The state machine works as follows: After task creation, it first enters the pending state, indicating that the task has been accepted but has not yet started execution. This typically occurs when the task has a delayed start setting (start_at parameter) or needs to wait for a certain condition to be met. A unified time wheel within the main control process periodically checks pending tasks. When the activation time is reached, the task is transitioned to the active state. In the active state, the main control process sends a start command to the traffic packet capture plugin via narrow instruction set. The plugin updates the eBPF mapping table and begins packet capture. When the task meets the termination conditions (such as duration expiration, packet count reaching the target, cancellation, or reference count reaching zero), the task enters the stopping state. At this time, the main control process sends a stop command, and the plugin cleans up the eBPF mapping table entries. After cleanup, the task enters the stopped state and is finally removed from the memory policy runtime table. This design decomposes the entire process from task creation to destruction into a series of clear, ordered, and manageable stages. In particular, a pending state and a unified time wheel mechanism are introduced to handle delayed activation tasks, along with explicit stopping and stopped states for task cleanup. This method aims to address issues in related technologies such as ambiguous task state management, non-atomic start / stop operations, and untimely resource cleanup, which can lead to chaotic task states and resource leaks. By introducing a state machine, this method achieves precise, reliable, and automated control over the task lifecycle, ensuring predictable behavior at every step of the task's lifecycle and accurate and timely allocation and release of resources. This embodiment, through the refined management of a four-state machine, achieves full-process traceability and controllability of tasks from creation to destruction, ensuring correct execution of start-up and cleanup operations under any circumstances (including abnormal exits and reconnections), avoiding resource leaks and state inconsistencies.

[0057] In an optional embodiment, the task termination condition includes at least one of the following: the task duration reaches a preset expiration time; the number of packets captured reaches the maximum number of packets in a single task; the task is canceled by the platform; the reference count of the same stream hash value reaches zero.

[0058] In this embodiment, several scenarios are defined for the termination of traffic packet collection tasks corresponding to temporary collection tasks, including the task duration reaching a preset expiration time, the number of packets captured reaching the maximum number of packets per task, the task being canceled by the platform, and the reference count of the same stream hash value returning to zero. This allows for precise control over the termination of traffic packet collection tasks, preventing disorderly task growth, ensuring reasonable use of system resources, and improving the reliability and stability of the traffic collection system.

[0059] This embodiment lists four termination conditions that trigger a task to transition from the active state to the stopping state: the task duration reaches the preset expiration time, the number of packets captured reaches the maximum number of packets per task, the task is canceled by the platform, and the reference count of the same stream hash value reaches zero. These conditions correspond to natural expiration, resource limit protection, user intervention, and multi-source merging scenarios, respectively.

[0060] For example: Suppose an anomaly detection engine on a certain node simultaneously hits three rules, all pointing to the same network flow: source IP 10.0.0.1, destination IP 8.8.8.8, port 53, protocol UDP. Rule A is "abnormal DNS query detection" (sudden increase in query volume), rule B is "DNS tunnel detection" (long domain name characteristics), and rule C is "DGA domain name detection" (random domain name pattern). Each of the three rules triggers the creation of a temporary collection task, and their flow hash values ​​are the same (let's say 0x12345678). When the master process processes these three tasks, it creates an entry for the flow hash value 0x12345678 in the active task set mapping table, with an initial reference count of 0. When processing the first task, the reference count becomes 1, and the 0x12345678 entry is written to the eBPF mapping table, starting packet capture; when processing the second task, the reference count becomes 2, but the eBPF mapping table is no longer written repeatedly; when processing the third task, the reference count becomes 3, at which point all three tasks are in an active state, sharing the same eBPF mapping table entry. After 60 seconds, the task corresponding to rule A reaches its preset duration (60 seconds), triggering the first stop. The main control process converts the rule A task to stopping and issues a stop command. Upon receiving the command, the plugin decrements the reference count of the task from 3 to 2 in the active task set mapping table. Since the count is not 0, the 0x12345678 entry is not deleted from the eBPF mapping table, and packet capture continues. The rule A task is removed from the memory table after being converted to stopped. After another 30 seconds, the task corresponding to rule C triggers a stop because the number of captured packets reaches the upper limit (assuming the maximum number of packets is set to 1000). Similarly, the reference count is decremented from 2 to 1, the eBPF mapping table entry is retained, and packet capture continues. After another 20 seconds, the task corresponding to rule B is manually canceled by the platform (analysts believe this is a false alarm); the reference count is decremented from 1 to 0. At this time, the plugin deletes the 0x12345678 entry from the eBPF mapping table, stopping the capture of all packets for that stream. The rule B task is removed after being converted to stopped. To recap the entire process: from the start of the first task to the end of the last task, it lasted a total of 110 seconds. During this time, entries in the eBPF mapping table were created when the first task started and cleaned up when the last task ended, without interruption. This ensured that all three tasks obtained complete packet capture data while avoiding duplicate packet captures and wasted resources. This is precisely the technical value of using zero reference count as a stopping condition.

[0061] This embodiment provides diverse termination conditions, enabling the system to intelligently and precisely control the lifecycle of tasks based on multiple dimensions such as time, data volume, and external instructions. Through mechanisms such as "upper limit on the number of packets captured" and "manual cancellation," it ensures that resources are only occupied when needed, avoiding unnecessary waste and reducing system operating costs.

[0062] In an optional embodiment, the narrow instructions include the pcap_capture_task_start instruction, the pcap_capture_task_stop instruction, and the pcap_capture_task_sync instruction; wherein, the pcap_capture_task_start instruction is used to issue a start or refresh acquisition task to the traffic packet acquisition plugin, including the task identifier, flow hash value, task duration, maximum number of packets per task, and expiration time; the pcap_capture_task_stop instruction is used to stop the acquisition task according to the task identifier and flow hash value, and supports the reference count decrement operation, wherein the reference count is used to represent the count of multiple task sources corresponding to the same network flow; the pcap_capture_task_sync instruction is used to batch synchronize the active tasks in the memory policy runtime table after the traffic packet acquisition plugin re-establishes a connection with the main control process, so as to achieve idempotent recovery.

[0063] In this embodiment, the `pcap_capture_task_start` instruction can issue a start or refresh task to the traffic packet acquisition plugin, containing necessary task information, and can accurately drive the plugin to start or refresh the task; the `pcap_capture_task_stop` instruction can stop the acquisition task according to the task identifier and the stream hash value, and supports the reference count decrement operation, which is convenient for managing multiple task sources corresponding to the same network stream; the `pcap_capture_task_sync` instruction can batch synchronize active tasks in the memory policy runtime table after the traffic packet acquisition plugin re-establishes a connection with the main control process, realize idempotent recovery, and ensure system state consistency.

[0064] The "pcap_capture_task_start" command is used to start a new capture task or refresh the status of an existing task. This command is sent from the main control process to the packet capture plugin and includes the following core fields: Task Identifier: A globally unique ID used to reference a specific task in subsequent operations; Stream Hash Value: Identifies the network stream to be captured; Task Duration: How many seconds the task should run from the current moment; Maximum Packets per Task: Limits the maximum number of packets a task can capture; Expiration Time: The absolute timestamp at which the task stops. When the packet capture plugin receives the start command, it performs an idempotency check. If the stream hash value already exists in the eBPF mapping table, it only updates the task's metadata (such as refreshing the expiration time) without creating it again; if it does not exist, it creates a new entry and starts capturing packets. The start command supports "refreshing." For existing tasks, their lifecycle parameters, such as extending the capture duration, can be updated by sending a new start command. The "pcap_capture_task_stop" command is used to stop the capture task and clean up resources. This command contains two core fields: task identifier and stream hash value. After receiving the stop command, the traffic packet capture plugin performs the following operations: find the corresponding stream hash value in the active task set mapping table and decrement the reference count by one; if the reference count is zero, delete the corresponding stream hash value entry from the eBPF mapping table; stop the capture of subsequent packets for that stream; and return an acknowledgment to the master process. The stop command is designed to take into account scenarios where multiple source tasks share the same network stream, and the reference counting mechanism ensures that capture only truly stops when the last task ends. The "pcap_capture_task_sync" command is a synchronization command specifically designed for crash recovery scenarios. This command is typically sent proactively by the main control process to the traffic packet acquisition plugin after reconnection. The command body contains a complete list of all active tasks (pending and active states) in the memory policy runtime table. Upon receiving the sync command, the plugin performs a "reconciliation" operation: for each task in the synchronization list, it ensures that a corresponding flow hash value entry exists in the eBPF mapping table; for entries that exist in the eBPF mapping table but not in the synchronization list, they are deleted (garbage cleanup); the running status and lifecycle parameters of each task are updated. The sync command supports both incremental and full synchronization modes. Full synchronization is typically used during the initial reconnection to thoroughly align the states; subsequently, incremental synchronization can be used periodically to synchronize only changed tasks. This embodiment achieves efficient and reliable communication between the main control and plugins through a streamlined yet fully functional three-command system; the start and stop commands cover task lifecycle management for normal operation scenarios, while the synchronization command is specifically designed for crash recovery scenarios. The three commands work together to ensure both low overhead and state consistency.

[0065] Optionally, after receiving the narrow instruction, the traffic packet acquisition plugin performs the following operations sequentially within its own independent execution coroutine: parses the narrow instruction, updates the eBPF flow hash mapping table idempotently based on the parsing result, and returns an explicit confirmation receipt to the main control process.

[0066] Specifically, the traffic packet acquisition plugin parses narrow instructions and idempotently updates the eBPF stream hash mapping table within an independently executing coroutine. This avoids duplicate acquisition tasks and redundant system resource consumption. Returning explicit confirmation receipts to the main control process allows it to promptly understand the task execution status, ensuring the reliability and accuracy of task execution. These three steps constitute a closed loop for instruction processing, ensuring the executability and traceability of instructions. The main control can accurately perceive the effective status of instructions, providing it with real-time insight into the plugin's execution status.

[0067] Optionally, the above method also includes: when there is a flow hash value matching the current network flow in the eBPF flow hash mapping table, the TC program will trigger the flag to be set, bypass the sampling rate limit to capture all data packets of the current network flow, and the captured data will be output to the user space traffic packet acquisition plugin through the ring buffer, and the traffic packet acquisition plugin will encapsulate, compress and upload it.

[0068] By adopting the above technical solution, when a flow hash value matching the current network flow exists in the eBPF flow hash mapping table, the sampling rate limit can be bypassed to capture all data packets of the current network flow, ensuring the acquisition of complete traffic data. The captured data is output to the user-space traffic packet acquisition plugin through a ring buffer, enabling efficient data transmission. The traffic packet acquisition plugin encapsulates, compresses, and uploads the data, which helps reduce the amount of data transmitted and improves transmission efficiency.

[0069] This embodiment describes the specific execution logic of the eBPF program in the kernel: When a flow hash value matching the current network flow exists in the eBPF flow hash map table, the TC (Flow Control) program sets a trigger flag, bypassing the sampling rate limit to capture all packets of the network flow. The captured data is output to the user-space traffic packet acquisition plugin through a circular buffer, where it is encapsulated, compressed, and uploaded. Specifically, an abnormal flow map table is configured in the kernel; when traffic passes through the kernel TC program, if it is determined that the current flow hash value exists in the abnormal flow map table, an abnormal trigger flag is marked for the traffic, bypassing the system's default traffic sampling rate limit, and full packet capture is performed on the abnormal traffic.

[0070] In an optional embodiment, the above method further includes: imposing hard constraints on system resources through a resource protection mechanism built into the memory policy runtime table, wherein the resource protection mechanism includes at least one of the following: hard limit verification of the number of global concurrent tasks; verification of single task duration, maximum number of packets per single task, and number of bytes per packet; linkage storm protection based on the deduplication cooldown timer mapping table; new task rate limit based on the token bucket rate limiter; backpressure drop count of the bounded inter-process communication instruction queue; and reconciliation and recovery through synchronization instructions after the traffic packet collection plugin reconnects.

[0071] In this embodiment, the resource protection mechanism built into the memory policy runtime table is used to impose hard constraints on system resources. The hard limit check of the number of global concurrent tasks can prevent too many concurrent tasks from exhausting system resources. The checks of single task duration, maximum number of packets per task, and number of bytes per packet can prevent a single task from excessively occupying resources. The linkage storm protection based on the deduplication cooldown timer mapping table and the new task rate limit based on the token bucket rate limiter can prevent the system from overloaded due to excessively fast task requests. The backpressure drop count of the bounded inter-process communication instruction queue can prevent instruction backlog from causing unbounded memory growth. After the traffic packet collection plugin reconnects, it performs accurate reconciliation and recovery through synchronous instructions to ensure the consistency and accuracy of task status, improve the stability and reliability of the system, and meet the stable and efficient traffic collection requirements under high load scenarios.

[0072] The lack of a global resource protection mechanism in related technologies leads to an unlimited number of tasks, unrestricted single-task duration and packet count under high-concurrency abnormal traffic surges. This results in a sudden explosion of newly created tasks, causing a storm; the instruction queue accumulates infinitely, and memory grows uncontrollably; there is no accurate reconciliation after plugin reconnection, leading to disordered resource status and ultimately exhaustion of CPU, memory, and kernel eBPF resources, causing system lag or even crashes. Setting a global hard limit on the number of concurrent collection tasks means that before adding a temporary traffic packet collection task to the memory policy runtime table, the total number of currently active collection tasks is checked. If the number of currently active tasks reaches the preset hard limit, new collection task requests are rejected, limiting the disorderly expansion of tasks and preventing the exhaustion of kernel eBPF mapping resources and host computing power. The deduplication cooling mechanism uses (task source, rule identifier, stream hash value) as a composite key. Within a preset cooldown time (default 60 seconds), only the first request is accepted, and subsequent duplicate requests are directly discarded. This effectively prevents task explosions caused by rule false alarms or attack alarm storms. Global control of task creation rate smooths out the instantaneous peak of task creation, preventing the system from being overwhelmed by sudden traffic surges. The bounded IPC queue has a fixed capacity (e.g., 1000 instructions). When the queue is full, newly arriving instructions are discarded, and a discard count is accumulated. This prevents instructions from piling up indefinitely in the main control process's memory due to slow plugin processing. The discard count is an observable indicator, allowing operations personnel to determine whether expansion or parameter adjustments are needed. This embodiment forms a comprehensive resource constraint system, ensuring stable system operation under any load, with resource consumption always within a controllable range, preventing OOM, Map exhaustion, or CPU overload caused by task explosion. Through multi-dimensional resource constraints—pre-emptive rate limiting, in-process control, and post-event reconciliation and recovery—the system comprehensively blocks the vulnerability of disorderly resource expansion, locking task scale, instruction traffic, and single-task overhead within safe thresholds, ensuring controllable system resources and stable operation under high load scenarios.

[0073] Optionally, the above methods also include: for collection tasks explicitly marked as persistent by the platform or manual maintenance, performing a snapshot write operation when the task is created or changed, and writing the task information to the persistent configuration file; for temporary collection tasks triggered by anomaly detection rules, prohibiting the persistent writing of information to the configuration file.

[0074] By adopting the above technical solutions, snapshotting persistent collection tasks can ensure that task information is permanently saved, making it convenient for subsequent review and recovery. Prohibiting the persistent writing of temporary collection task information to the configuration file can avoid input / output storms and configuration inconsistencies caused by frequently triggered temporary tasks, thereby improving system reliability and stability and meeting the stable and efficient traffic collection requirements under high load scenarios.

[0075] This embodiment describes different processing strategies for persistent and temporary tasks: For collection tasks explicitly marked as persistent by the platform or manual maintenance, a snapshot is taken and written to disk when the task is created or modified, writing the task information to the persistent configuration file; for temporary collection tasks triggered by anomaly detection rules, writing their information to the configuration file is always prohibited. Related technologies persist all tasks (including temporary tasks), leading to frequent rewriting of configuration files in high-frequency linkage scenarios, causing IO storms and configuration drift. By separating the processing paths of persistent and temporary tasks, the IO impact of high-frequency temporary tasks on the configuration file is eliminated, while ensuring the reliable recovery of persistent tasks. The configuration file is only written by snapshot operations triggered by the creation, modification, and deletion events of persistent tasks, a very low frequency (only when administrators operate), completely solving the IO storm problem.

[0076] In an optional embodiment, the above method further includes: when the main control process issues task control instructions to the traffic packet collection plugin, rate control and back pressure management are performed through a bounded inter-process communication instruction queue. When the depth of the instruction queue reaches a preset upper limit, back pressure is dropped on newly arrived instruction requests and the drop count is recorded to avoid unbounded memory growth caused by instruction backlog.

[0077] In this embodiment, a bounded inter-process communication instruction queue is used to control the rate and manage the back pressure of the task control instructions issued by the main control process to the traffic packet acquisition plugin. When the depth of the instruction queue reaches the preset upper limit, the newly arrived instruction requests are discarded under back pressure and the discard count is recorded. This can avoid the unbounded growth of memory caused by instruction backlog and improve the stability of the system and the controllability of resource usage.

[0078] This embodiment describes the rate control and backpressure management mechanism when the master control process issues task control commands to the traffic packet acquisition plugin: A bounded IPC command queue is used for buffering. When the command queue depth reaches a preset upper limit, newly arriving command requests are dropped under backpressure, and the drop count is recorded to avoid unbounded memory growth caused by command backlog. Related technologies lack flow control when the master control sends commands to the plugin. When the plugin's processing capacity is insufficient, commands will accumulate infinitely on the master control side, consuming the master control process's memory and ultimately leading to OOM (Out of Memory) crashes. This embodiment limits command backlog to a controllable range through a bounded queue and backpressure drop mechanism, ensuring that the master control process's memory usage has an upper limit. Drop events are recorded and observable, allowing maintenance personnel to determine whether capacity expansion or parameter adjustments are needed based on the drop count. The system will not crash even if overloaded.

[0079] In an optional embodiment, updating the eBPF flow hash map in an idempotent manner specifically includes: when the traffic packet collection plugin repeatedly receives the same task control instruction, it does not create a new traffic collection task repeatedly, but only verifies and synchronizes the running status and lifecycle parameters of the existing tasks in the eBPF flow hash map, so as to avoid generating duplicate collection tasks and redundant occupation of system resources.

[0080] In this embodiment, when the traffic packet acquisition plugin repeatedly receives the same task control instruction, it does not create a new traffic acquisition task repeatedly. Instead, it verifies and synchronizes the running status and lifecycle parameters of existing tasks in the eBPF flow hash mapping table, thus avoiding duplicate acquisition tasks and redundant occupation of system resources.

[0081] In related technologies, under scenarios such as network jitter, message retransmission, and plugin restarts, the main control process may repeatedly send the same instructions to plugins (such as retrying to send the start instruction). If the plugin recreates the task each time, it will lead to problems such as duplicate entries in the eBPF mapping table, chaotic reference counts, and duplicate resource consumption. In this embodiment, when the traffic packet collection plugin repeatedly receives the same task control instruction, it does not create a new traffic collection task. It only verifies and synchronizes the running status and lifecycle parameters of existing tasks in the eBPF flow hash mapping table, avoiding duplicate collection tasks and redundant system resource consumption. This embodiment uses idempotent updates to ensure that duplicate instructions do not produce side effects. No matter how many times the instruction is sent, the final system state is consistent—each network flow has only one record in the eBPF mapping table, the reference count correctly reflects the actual number of tasks, and there is no waste of resources caused by duplicate creation.

[0082] The following description, in conjunction with specific embodiments, illustrates a method and system for collecting dynamic traffic packets using a multi-plugin agent based on eBPF. By organically combining a memory policy table (corresponding to the aforementioned memory policy runtime table) as the single authoritative source, the default non-persistence of temporary tasks to configuration files, single-coroutine full lifecycle management of the main control program, narrow IPC command issuance, and an idempotent reconnection and synchronization mechanism, this method fundamentally solves problems such as configuration drift, IPC backpressure, eBPF map residue leakage, and uncontrollable resources under high-load scenarios. This enables the entire agent program to run securely, reliably, and efficiently in a production environment, meeting the needs of threat hunting, fault diagnosis, and compliance forensics in large-scale deployments. The aim is to achieve zero configuration drift for temporary tasks, unified serial orchestration of the main control program, cross-plugin collaboration of narrow commands, and predictable control of end-to-end resources, thereby providing a highly robust and controllable technical solution for eBPF multi-engine dynamic traffic capture systems.

[0083] The core technical solution is as follows: using the memory policy runtime table in the main control process as the single authoritative source to manage the entire lifecycle of dynamic traffic packet collection tasks; temporary tasks reside only in the memory table and BPFmap by default and are not persisted in the configuration file; the main control uses a single coroutine for unified orchestration and uses narrow IPC instructions to issue minimal control commands to independently running traffic packet collection plugins, thereby achieving zero configuration drift, low resource consumption and reliable state consistency under high load scenarios.

[0084] The technical solution of this application embodiment specifically includes the following main components: 1. Main control program memory policy runtime table (pcapPolicyRuntime) – Single authoritative source In this embodiment of the application, a policy runtime table pcapPolicyRuntime, which uses memory as the sole authority, is maintained in the main control process. Its core data structure is as follows: (1) tasks: A task mapping table with task_id (UUID) as the key, storing all active traffic packet collection tasks; (2) byFlowHash: A mapping table of active task sets with flowHash as the key, which supports reference counting (refCount) management when the same flowHash is triggered by multiple sources (platform side, anomaly detection plugin) at the same time; (flowHash: obtained by hashing the five-tuple (or more fields) of a network connection, with the purpose of using a fixed-length integer to quickly and uniquely represent a flow); (3) dedupLastStart: A deduplication cooldown timer mapping table with (source, sourceRef, flowHash) as the key, used to prevent high-frequency linkage events from causing task storms; (4) ipcQueue: Bounded IPC command queue, used to control the rate at which the main controller sends commands to the traffic acquisition plugin and the back pressure; (5) rateLimiter: Token bucket rate limiter, used to limit the number of new traffic packet tasks created by the Agent program per second; (6) config: The current effective hard limit configuration snapshot of resources (including the maximum number of concurrent tasks, the maximum duration of a single task, the maximum number of packets per single task, etc.).

[0085] All read and write operations on the policy table are executed serially by a single coroutine (policyLoop) within the main control process, thereby completely eliminating the risk of race conditions caused by multiple coroutines / threads.

[0086] 2. CaptureTask Task Model and Lifecycle Management Each dynamic traffic packet collection task is fully described by the CaptureTask structure, whose key fields include: (1) id: i.e., task_id, globally unique task ID (UUID); (2) source: task source (platform, flow_rule, manual configuration). (3) sourceRef: The identifier of the source of the backtracking (such as the rule name in flow_rule); (4) flowHash: A 64-bit flowHash value that is completely identical to that of the network traffic detection plugin (flow_log); (5) createdAt / expiresAt: Creation time and absolute expiration time; (6) state: The current state of the task (pending, active, stopping, stopped); (7) refCount: Reference count, used for merging multiple tasks within the same flow_hash; (8) maxPackets: Maximum number of packets captured per task (subject to global hard upper limit).

[0087] It should be noted that the first field, tasks, in pcapPolicyRuntime is a structure, and each structure stores CaptureTask information.

[0088] The task lifecycle strictly follows the following state machine: Pending: The task has been accepted but has not yet reached the activation time specified by start_at or delay_sec. It is activated at a set time by the unified time wheel in the policyLoop. Active: The pcap_capture_task_start command is issued via narrow IPC, and the traffic packet capture plugin updates the abnormal_flowsmap and begins actual packet capture; Stopping: Enters when any of the termination conditions are met (duration expires, packet count reaches the limit, platform cancels, refCount reaches zero), triggering the pcap_capture_task_stop instruction; Stopped: Removed from the memory table after map cleanup and snapshot update (if it is a persistent task).

[0089] For temporary tasks linked by `flow_rule`, they are marked as non-persistent by default, residing only in the memory table and `BPFabnormal_flowsmap`, and are not written to the data collection task's persistence configuration file. Only tasks explicitly marked as persistent by the platform or manual maintenance personnel will have their snapshots written to disk during changes. The lifecycle state machine flowchart is as follows. Figure 2 As shown.

[0090] The lifecycle management of traffic packet collection tasks is as follows: After task creation, it enters the Pending state. When the start_at or delay_sec parameter expires, or the task is immediately activated, the state changes to Active. In the Active state, the main control program issues traffic packet collection tasks to the traffic packet collection plugin via narrow instructions. The plugin updates the abnormal_flows mapping table in the kernel and starts a local timer. When the task duration expires, the maximum number of packets is reached, it is canceled by the platform, or a refresh instruction with the same task_id is received, the state changes to Stopping. In the Stopping state, the main control program sends the pcap_capture_task_stop instruction; if it is a persistent task, the snapshot is updated. When the reference count corresponding to the flow hash value reaches zero, the corresponding entry in the BPF mapping table is deleted, the state changes to Stopped, and the task ends after cleanup. If the task in the Pending state expires or is rejected, it directly enters the Stopped state and ends.

[0091] 3. Narrow IPC protocol and cross-plugin collaboration This application embodiment adopts a single-coroutine policy loop in the main control program + lightweight narrow-instruction IPC mechanism. The main control program and the traffic packet collection plugin interact through the following three core instructions: (1) pcap_capture_task_start: Issues a start / refresh task, containing only the minimum necessary fields such as task_id, flow_hash, duration_sec, maxPackets, and expiresAt; (2) pcap_capture_task_stop: Stops tasks by task_id and flowHash, and supports the logic of decrementing refCount by one; (3) pcap_capture_task_sync: After the plugin reconnects or the master restarts, it is used to batch synchronize the active tasks in the current memory table to achieve idempotent recovery.

[0092] After receiving the command, the traffic packet capture plugin processes it within its independent single coroutine: parse the command → idempotently update abnormal_flowsmap → return an explicit pcap_capture_task_ack. This narrow command structure greatly reduces IPC overhead and version compatibility complexity. The timing diagram of the interaction between the main control program and the traffic capture plugin is as follows: Figure 3 As shown.

[0093] 4. Integration with the eBPF execution layer The main control program is only responsible for policy management and command issuance; the final execution is completed by the eBPF program of the traffic packet collection plugin. (1) When the corresponding flowHash exists in abnormal_flowsmap, the TC program sets the triggered flag, thereby bypassing the sampling rate limit and achieving accurate packet capture; (2) The captured packet data is output to the user space through ringbuf, and the traffic packet acquisition plugin is responsible for pcapng encapsulation, compression and uploading; (3) When the task ends, the main control program drives the plugin to delete the map item through the stop command to avoid map leakage.

[0094] 5. Hard constraints on resources and guarantees of robustness This application embodiment incorporates multiple resource protection mechanisms within pcapPolicyRuntime: (1) Hard limit on the number of concurrent tasks globally; (2) Single task duration, number of packets, and number of bytes per packet; (3) Linked storm protection (dedup cooling + new task rate limit); (4) IPC bounded queue + backpressure drop count; (5) Accurate reconciliation recovery after plug-in reconnection.

[0095] This application forms a complete closed-loop solution through the above-mentioned technology combination, ensuring that the system can still operate predictably under high load scenarios without problems such as agent-side memory exhaustion, disk fullness, or CPU preemption.

[0096] The technical solution of this application revolves around the core idea of ​​"memory policy table as a single authoritative source + temporary tasks being non-persistent by default + main control program managing the entire lifecycle of a single coroutine," forming a unique technical solution that differs from existing technologies. It includes: (1) The memory policy table serves as the single authoritative source, and temporary tasks are not persisted by default. The main control process maintains the pcapPolicyRuntime memory table as the only authoritative source of policies for the entire system. All dynamic traffic packet collection tasks (especially the temporary tasks联动generated by the traffic anomaly detection engine - flow_log) are defaultly only resident in this memory table and the corresponding BPF abnormal_flows map, without being written to any persistent configuration files. Only when the platform or manual operation and maintenance explicitly mark it as a persistent task, will the throttling snapshot be written to disk. This feature fundamentally eliminates the configuration IO storm and configuration drift problems in high-frequency联动scenarios.

[0097] (2)Single-coroutine unified orchestration and serial update mechanism of the main control program [[ID=X]] All read / writes of policy tables, task state transitions, duplicate removal judgments, rate limits, and IPC instruction generations are serially executed by the only coroutine policyLoop within the main control process. This design completely avoids the race conditions caused by multi-coroutine / multi-thread access, ensuring the consistency and predictability of the policy table at any time.

[0098] (3)Narrow IPC instruction and idempotent cross-plugin collaboration mechanism The main control program communicates with the independently running traffic packet collection plugin using lightweight narrow instructions, only transmitting the minimum necessary fields (task_id, flowHash, duration_sec, maxPackets, etc.). At the same time, the pcap_capture_task_sync instruction is introduced to support batch idempotent status synchronization after plugin reconnection or main control restart. This feature enables low-overhead and reliable collaboration in a multi-plugin architecture, avoiding the complexity and resource overhead brought by shared memory or full-scale synchronization.

[0099] (4)Fine-grained lifecycle management based on reference counting and deduplication cooling The reference counting (refCount) management of the same flow_hash is implemented through the byFlowHash mapping table, and the cooling deduplication based on (source, source_ref, flow_hash) is achieved through dedupLastStart, combined with the unified time wheel / priority queue to manage the timed activation of status tasks. This feature effectively controls the explosive growth of temporary tasks and realizes the fully closed-loop controllable management of tasks from creation to cleanup.

[0100] This application also provides a dynamic traffic packet collection device for executing the dynamic traffic packet collection method in any of the foregoing embodiments, as Figure 4 shown, the device includes: A module is established to create a memory policy runtime table in the main control process. The memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all traffic packet collection tasks. A creation module is used to create and maintain corresponding temporary collection task information in the memory policy runtime table and the kernel's eBPF flow hash mapping table when a temporary traffic packet collection task request triggered by an anomaly detection rule is received. The temporary collection task information is not persistently written to the configuration file. The processing module is used to serially update the memory policy runtime table through a unique execution coroutine within the main control process, and issue task control instructions to the independently running traffic packet collection plugin through narrow instructions based on the update results. The narrow instructions contain the minimum task information required to drive the traffic packet collection plugin to perform operations. The acquisition module is used to receive and parse the task control instructions through an independent execution coroutine within the traffic packet acquisition plugin, and update the eBPF flow hash mapping table in an idempotent manner according to the task control instructions to trigger or stop traffic packet acquisition.

[0101] It should be noted that the devices or systems provided in the above embodiments are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept. Other device or system embodiments correspond to the aforementioned method embodiments. Other technical features are described in the previous embodiments and will not be repeated here.

[0102] This application also provides a computer-readable storage medium storing instructions that, when executed, perform the steps of any of the methods described above.

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

[0104] This application also discloses an electronic device. For example... Figure 5 As shown, Figure 5This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. The electronic device 500 may include: at least one processor 501, at least one network interface 504, a user interface 503, a memory 505, and at least one communication bus 502.

[0105] The communication bus 502 is used to enable communication between these components.

[0106] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0107] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0108] The processor 501 may include one or more processing cores. The processor 501 connects to various parts of the electronic device (such as a server) using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 505, and by calling data stored in memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0109] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501. (Refer to...) Figure 5 The memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a dynamic traffic packet collection method.

[0110] exist Figure 5 In the illustrated electronic device 500, the user interface 503 is mainly used to provide an input interface for the user and acquire user input data; while the processor 501 can be used to call the application program of the dynamic traffic packet acquisition method stored in the memory 505. When executed by one or more processors 501, the electronic device 500 performs one or more of the methods described in the above embodiments. It should be noted that, for the foregoing method embodiments, for the sake of simplicity, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0111] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0112] In the various embodiments provided in this application, it should be understood that the disclosed apparatus or system can be implemented in other ways. For example, the apparatus or system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0113] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure herein.

[0114] 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 that are not described in this disclosure.

Claims

1. A method for collecting dynamic traffic packets, characterized in that, include: A memory policy runtime table is established in the main control process. The memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all traffic packet collection tasks. When a temporary traffic packet collection task request triggered by the anomaly detection rule is received, the corresponding temporary collection task information is created and maintained in the memory policy runtime table and the kernel's eBPF flow hash mapping table. The temporary collection task information is not persistently written to the configuration file. The memory policy runtime table is serially updated by a unique execution coroutine within the main control process, and task control instructions are issued to the independently running traffic packet collection plugin via narrow instructions based on the update results. The narrow instructions contain the minimum task information required to drive the traffic packet collection plugin to perform operations. The task control instructions are received and parsed by an independent execution coroutine within the traffic packet collection plugin. The eBPF flow hash mapping table is updated in an idempotent manner according to the task control instructions to trigger or stop traffic packet collection.

2. The method of claim 1, wherein, The method further includes: After the traffic packet acquisition plugin re-establishes a connection with the main control process, it receives a synchronization instruction sent by the main control process and synchronizes the set of active tasks in the memory policy runtime table to the traffic packet acquisition plugin.

3. The method of claim 1, wherein, The memory policy runtime table includes: A task mapping table storing all active traffic packet collection tasks, using the task identifier as the key; An active task set mapping table that stores reference counts for multiple task sources corresponding to the same network stream, using the stream hash value as the key; A deduplicated cooldown timer mapping table with task source, traffic anomaly rule identifier, and stream hash value as keys; A bounded inter-process communication instruction queue used to control the rate at which the main control process sends instructions to the traffic packet acquisition plugin; A token bucket rate limiter used to limit the number of new traffic packet tasks per second; And a snapshot of the resource hard limit configuration, including the maximum number of concurrent tasks, the maximum duration of a single task, and the maximum number of packets per single task.

4. The method of claim 1, wherein, The traffic packet collection task corresponding to the temporary collection task information follows a lifecycle state machine including pending, active, stopping, and stopped states. The pending state indicates that the task has been accepted but the activation time has not yet arrived, and the unified time wheel in the unique execution coroutine within the main control process is responsible for timed activation; the active state indicates that a start command has been issued to the traffic packet collection plugin via the narrow instruction, and the traffic packet collection plugin has updated the eBPF flow hash mapping table and started packet capture; the stopping state indicates that it is entered when the task termination condition is met, triggering the issuance of a stop command to the traffic packet collection plugin via the narrow instruction; the stopped state indicates that it is removed from the memory policy runtime table after the eBPF flow hash mapping table has been cleaned up and the snapshot updated.

5. The method of claim 4, wherein, The task termination condition includes at least one of the following: The task duration has reached the preset expiration time; The number of packets captured has reached the maximum limit for a single task. The task was canceled by the platform. The reference count of the same stream hash value is reduced to zero.

6. The method of claim 1, wherein, The narrow instructions include the pcap_capture_task_start instruction, the pcap_capture_task_stop instruction, and the pcap_capture_task_sync instruction; wherein... The pcap_capture_task_start instruction is used to send a start or refresh collection task to the traffic packet collection plugin, which includes a task identifier, stream hash value, task duration, maximum number of packets per task, and expiration time. The pcap_capture_task_stop instruction is used to stop the acquisition task according to the task identifier and the stream hash value, and supports the reference count decrement operation, wherein the reference count is used to represent the count of multiple task sources corresponding to the same network stream; The pcap_capture_task_sync instruction is used to batch synchronize the active tasks in the memory policy runtime table after the traffic packet acquisition plugin re-establishes a connection with the main control process, thereby achieving idempotent recovery.

7. The method of claim 3, wherein, The active task set mapping table adopts a reference counting mechanism. When the same stream hash value corresponds to multiple task sources, the reference count is incremented; when the collection task of one of the task sources ends, the reference count is decremented by one; when the reference count reaches zero, the corresponding stream hash value entry is deleted from the eBPF stream hash mapping table.

8. A dynamic flow packet acquisition apparatus, characterized by, The method for performing the dynamic traffic packet collection method according to any one of claims 1 to 7 includes: A module is established to create a memory policy runtime table in the main control process. The memory policy runtime table is a data structure stored in the memory of the main control process and serves as the sole authoritative source for all traffic packet collection tasks. A creation module is used to create and maintain corresponding temporary collection task information in the memory policy runtime table and the kernel's eBPF flow hash mapping table when a temporary traffic packet collection task request triggered by an anomaly detection rule is received. The temporary collection task information is not persistently written to the configuration file. The processing module is used to serially update the memory policy runtime table through a unique execution coroutine within the main control process, and issue task control instructions to the independently running traffic packet collection plugin through narrow instructions based on the update results. The narrow instructions contain the minimum task information required to drive the traffic packet collection plugin to perform operations. The acquisition module is used to receive and parse the task control instructions through an independent execution coroutine within the traffic packet acquisition plugin, and update the eBPF flow hash mapping table in an idempotent manner according to the task control instructions to trigger or stop traffic packet acquisition.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1 to 7.

Images