Server network monitoring method and device
By automatically filtering and matching position numbers using the BTF type function database, non-intrusive kernel network monitoring is achieved, solving the problems of narrow monitoring scope and difficulty in cross-version adaptation in existing technologies, and improving monitoring efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA ELECTRONICS CLOUD DIGITAL INTELLIGENCE TECH CO LTD
- Filing Date
- 2025-12-15
- Publication Date
- 2026-04-21
AI Technical Summary
Existing Linux kernel network monitoring technologies suffer from problems such as system crash risk, high cost of cross-version adaptation, limited monitoring scope, and the need for manual specification of function parameters.
Kernel network functions are automatically filtered through the BTF type function database, the target parameter position number is determined based on the function index information, and a preset kernel probe program is non-intrusively mounted to achieve automated collection of kernel network event data.
It solves the problem of monitoring configuration failure caused by kernel version iteration, reduces the cost of cross-version adaptation, and realizes automated discovery and efficient monitoring of kernel network functions.
Smart Images
Figure CN121907720A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of server monitoring technology, and in particular to a server network monitoring method and apparatus. Background Technology
[0002] With the rapid adoption of cloud computing, containerization, and microservice architectures, Linux servers have become the carriers of core enterprise businesses. The stability, performance, and security of their kernel network layer directly determine the quality of business operations. Therefore, the need for monitoring Linux kernel networks is becoming increasingly prominent.
[0003] Existing Linux kernel network monitoring technologies are mainly divided into two categories: one is the traditional kernel-mode monitoring scheme, such as SystemTap and ftrace. This type of scheme relies on dynamically compiled kernel modules to achieve monitoring, but loading kernel modules is prone to causing system crashes and cannot meet the stability requirements of production environments. At the same time, this method requires manual maintenance of the monitoring function list and relies on hard-coded memory offsets to extract parameters. When kernel version iterations cause changes in function signatures or data structures, the monitoring configuration will directly fail, and the cost of cross-version adaptation is extremely high.
[0004] Another type of monitoring solution is based on eBPF (Extended Berkeley Packet Filter), such as BCC and bpftrace. These solutions achieve "zero intrusion" by leveraging eBPF's sandbox mechanism, but their monitoring scope is limited to a small number of commonly used kernel network functions. They cannot cover the complete kernel network protocol stack call chain and are difficult to locate deep performance bottlenecks. At the same time, they lack in-depth utilization of kernel BTF (BPF type format) information, requiring manual specification of monitoring functions and parameter locations, and cannot achieve automated function discovery and cross-version adaptation.
[0005] Therefore, improving the efficiency of monitoring Linux kernel networks has become an urgent problem to be solved. Summary of the Invention
[0006] This application provides a server network monitoring method and apparatus to at least solve the problem of instability in the reporting of asset information in related technologies.
[0007] This application provides a server network monitoring method, including: Obtain function index information of multiple target kernel network functions from a BTF type function database; the BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters; For each target kernel network function, the position number of the target parameter in the parameter list of the target kernel network function is determined according to the function index information; Based on the position number, the corresponding kernel probe program is matched from multiple preset kernel probe programs, and the kernel probe program is mounted onto the corresponding target kernel network function; When the target kernel network function is called, kernel network event data is collected through the kernel probe program.
[0008] This application also provides a server network monitoring device, including: The acquisition unit is used to acquire function index information of multiple target kernel network functions in a BTF type function database; the BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters. The determining unit is used to determine, for each target kernel network function, the position number of the target parameter in the parameter list according to the function index information; The matching unit is used to match the corresponding kernel probe program from multiple preset kernel probe programs according to the position number, and to attach the kernel probe program to the corresponding target kernel network function. The acquisition unit is used to acquire kernel network event data through the kernel probe program when the target kernel network function is called.
[0009] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described server network monitoring methods.
[0010] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described server network monitoring methods.
[0011] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described server network monitoring methods.
[0012] The method provided in this application automatically filters kernel network functions containing target parameters based on a BTF type function database, eliminating the need for manual maintenance of the monitoring function list. Simultaneously, it determines the position number of the target parameter based on function index information, achieving precise matching between probes and functions. This solves the problem of monitoring configuration failure caused by kernel version iterations, significantly reducing cross-version adaptation costs. Addressing the shortcomings of existing eBPF solutions, such as narrow monitoring scope and the need for manual specification of functions and parameters, this method automates the discovery of kernel network functions through a BTF type function database, facilitating the identification of underlying performance issues. Furthermore, it matches and mounts pre-set eBPF probes based on position numbers, completing probe deployment without manual intervention and improving the efficiency of server kernel monitoring. Attached Figure Description
[0013] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0014] Figure 1 This is one of the flowcharts illustrating a server network monitoring method provided in an embodiment of this application; Figure 2 This is a second flowchart illustrating a server network monitoring method provided in an embodiment of this application. Figure 3 This is a schematic diagram of the structure of a server network monitoring device provided in an embodiment of this application. Detailed Implementation
[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0016] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0018] Reference Figure 1 The diagram shown is a flowchart of a server network monitoring method provided in this application. The specific steps include the following: S11. Obtain the function index information of multiple target kernel network functions in the BTF type function database.
[0019] The BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters.
[0020] Specifically, the BTF type function database can be understood as a pre-built collection of kernel function metadata. It can read the Linux kernel's BTF (BPF Type Format) type specification information (usually stored at / sys / kernel / btf / vmlinux), and then parse the metadata of all kernel functions, such as function name, function address, and function signature (including parameter type, number of parameters, and return type). It also combines the kernel symbol table ( / proc / kallsyms) to supplement the validity verification of function addresses, and finally generates a database that includes the mapping relationship between function name, function address, and function signature.
[0021] Furthermore, the BTF type function database can provide "type-safe function metadata," laying the foundation for subsequent function selection and parameter analysis.
[0022] Among them, the function index information is the key information used to uniquely identify kernel network functions and describe their core attributes. It includes at least the function name, function address, and function signature (especially the parameter type list), ensuring that the function can be located and the parameter position can be analyzed later through this information.
[0023] The target parameter specifically refers to the parameter type directly related to kernel network communication. Specifically, it can be a socket-related type parameter, including sock* pointer type, struct sock structure type, and struct socket structure type. This type of parameter is used to determine whether a function is a "kernel network function". For example, if the first parameter of the tcp_sendmsg function is of type sock*, then it belongs to the kernel network function.
[0024] The target kernel network function refers to the kernel function in the BTF type function database whose function signature parameter list contains the above-mentioned "target parameters", that is, the kernel function with core network functions such as network data transmission and connection management (such as tcp_v4_connect, udp_recvmsg, inet_csk_accept, etc.).
[0025] This step ensures that after the system starts up, the pre-built BTF type function database is loaded first (if the database is not built or the kernel version is updated, the database reconstruction process will be triggered). Iterate through the function signatures of all kernel functions in the BTF type function database and filter functions whose parameter list contains sock*, struct sock, or struct socket type parameters; The selected functions undergo preliminary validity checks (excluding functions marked as unmonitorable, such as static functions and inline functions), ultimately yielding multiple target kernel network functions. Extract the function index information (function name, function address, function signature) corresponding to each target kernel network function to provide data support for subsequent steps.
[0026] S12. For each target kernel network function, determine the position number of the target parameter in the parameter list in the target kernel network function according to the function index information.
[0027] In some embodiments, since the positions of the socket parameters differ for different kernel network functions (e.g., the socket parameter of tcp_sendmsg is in the first position, and the socket parameter of inet_csk_accept is in the second position), this step extracts the list of parameter types from the function signature of each target kernel network function selected above from its function index information (e.g., the list of parameter types for the function int tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size) is [struct sock*, struct msghdr*, size_t]).
[0028] Then, by traversing the list of parameter types, the position number of the target parameter in the parameter list is identified and recorded (the position number starts from 1, such as the struct sock* parameter of tcp_sendmsg being in the 1st position with position number 1; the struct sock* parameter of inet_csk_accept being in the 2nd position with position number 2).
[0029] It should be noted that if the same function has multiple target parameters (in very special cases), the position number is determined based on the parameter most relevant to the core logic of network communication (such as the sock* parameter that directly carries the connection), and the positions of other parameters are recorded as auxiliary information.
[0030] S13. Based on the position number, match the corresponding kernel probe program from multiple preset kernel probe programs, and attach the kernel probe program to the corresponding target kernel network function.
[0031] Specifically, the preset kernel probe program can be understood as a program assembly pre-compiled based on eBPF technology. Each preset kernel probe program is associated with its corresponding position number and includes parameter security access logic, multi-dimensional data acquisition logic, and kernel-mode adaptation logic. That is, the probe program is pre-adapted to the access rules of different parameter positions and can be mounted to the corresponding position parameter function without modification.
[0032] Mounting refers to using kprobe / kretprobe technology to "hook" the eBPF probe program to the entry point (triggered when the function is called) and exit point (triggered when the function returns) of the target kernel network function. This process does not require modification of the kernel source code or loading of kernel modules. It is only implemented through the eBPF sandbox interface provided by the kernel, ensuring zero intrusion and no risk of system crash.
[0033] Then, by querying the mapping table using the position number of the target parameter, the kernel probe program that matches the position number is determined; the mapping table includes the correspondence between the position number and the preset kernel probe program.
[0034] Specifically, this step pre-establishes a mapping table between position numbers and probe programs (e.g., position number 1 corresponds to probe program P1, position number 2 corresponds to probe program P2, etc.). At the same time, the mapping table can be dynamically updated according to the kernel version and function type.
[0035] For each target kernel network function, based on the position number determined in step S12, the mapping table is queried to match the corresponding preset kernel probe program (e.g., probe P1 matches the function with position number 1); the compatibility between the matched probe program and the target kernel network function is verified (e.g., whether the parameter types supported by the probe and the function calling convention are consistent with the target function) to ensure that the probe can be triggered normally; the probe program is mounted to the entry address (collecting parameter data during function call) and exit address (collecting function return value and execution time data) of the target kernel network function through the kprobe interface; for a batch of functions with the same position number, kprobe-multi technology is used to achieve batch mounting to improve deployment efficiency.
[0036] S14. When the target kernel network function is called, kernel network event data is collected through the kernel probe program.
[0037] In this embodiment, kernel network event data refers to comprehensive data related to the execution of kernel network functions, which may include information in five dimensions: process, network, container, time, and function. Specifically, it includes: Process information can include PID (Process ID), TGID (Thread Group ID), process name, user ID, and process start time.
[0038] Network information may include source IP address, destination IP address, source port, destination port, protocol type (TCP / UDP / RAW, etc.), and connection status.
[0039] Container information can include container ID, container name, and Pod name.
[0040] Time information can include nanosecond-level timestamps, CPU clock cycles, and function call numbers.
[0041] Function information can include the function address, function call stack, and return value.
[0042] Furthermore, when a business process triggers a kernel network operation (such as sending data or establishing a connection), the corresponding target kernel network function is called, and the eBPF probe program mounted at the function's entry / exit point is triggered immediately (with a response latency in the nanosecond range). The probe program extracts the core data corresponding to the target parameter (such as the IP and port information in the sock structure) through type-safe parameter access logic (determining the parameter memory address based on BTF type information, rather than hard-coded offsets). It synchronously collects related data such as process, container, time, and function call stack to ensure data correlation (such as binding "a container's TCP connection" with "the corresponding kernel function call"). The collected data is temporarily stored in a kernel-mode buffer (such as a Ring Buffer / Perf Buffer) in a compact binary format to avoid frequent data copying between user mode and kernel mode and reduce system overhead.
[0043] The method provided in this application automatically filters kernel network functions containing target parameters based on a BTF type function database, eliminating the need for manual maintenance of the monitoring function list. Simultaneously, it determines the position number of the target parameter based on function index information, achieving precise matching between probes and functions. This solves the problem of monitoring configuration failure caused by kernel version iterations, significantly reducing cross-version adaptation costs. Addressing the shortcomings of existing eBPF solutions, such as narrow monitoring scope and the need for manual specification of functions and parameters, this method automates the discovery of kernel network functions through a BTF type function database, facilitating the identification of underlying performance issues. Furthermore, it matches and mounts pre-set eBPF probes based on position numbers, completing probe deployment without manual intervention and improving the efficiency of server kernel monitoring.
[0044] As an extension and refinement of the above embodiments, refer to Figure 2 As shown, this application provides another method for monitoring server networks, which specifically includes the following steps: S21. Read the BTF type function specification information of the server kernel.
[0045] Specifically, BTF type function specification information refers to the collection of kernel function and data structure metadata stored by the Linux kernel through BTF (BPF Type Format) technology. It is a standardized format natively supported by the kernel and contains specification information such as the definition of all kernel functions (function name, parameter type, return value type, function signature) and data structures (such as field definitions and memory offsets of sock and sk_buff structures), which is equivalent to the instruction manual of the kernel functions.
[0046] It should be noted that the standard storage path for BTF type function specification information in Linux systems is / sys / kernel / btf / vmlinux (automatically generated and written to this path during kernel compilation). This step can directly read the contents of this file through the standard file reading interface provided by the kernel (such as the open and read system calls), without modifying the kernel or loading additional modules, ensuring zero intrusion in the reading process.
[0047] Furthermore, the BTF parsing module in the single-point deployment module can first detect whether the server kernel supports BTF technology (by checking if the file / sys / kernel / btf / vmlinux exists and is readable). If the kernel does not support it, a compatibility warning is output. If BTF is supported, the / sys / kernel / btf / vmlinux file is opened through the file operation interface, and the binary metadata in the file is read according to the BTF standard format (BTF format uses compact encoding to ensure reading efficiency). During the reading process, data integrity is verified (such as verifying the magic number, version number, and data length of the BTF file) to avoid parsing errors caused by file corruption. Finally, the read binary metadata is temporarily stored in the kernel-mode buffer to reduce the data copying overhead between user mode and kernel mode, providing efficient data input for subsequent parsing steps.
[0048] S22. Identify the BTF type function specification information, obtain each kernel network function and the function index information of the kernel network function, so as to create the BTF type function database.
[0049] The function index information includes: function name, function address, and function signature.
[0050] It should be noted that this step involves accurately filtering out kernel functions with network capabilities (kernel network functions) from massive, unstructured BTF type function specification information, excluding non-network kernel functions such as file operations and memory management, and reducing database redundancy.
[0051] Meanwhile, the core metadata (function name, function address, function signature) of kernel network functions is extracted and stored in a structured manner to form a BTF type function database that can be efficiently queried and adapted across versions, providing standardized function metadata support for subsequent target parameter location identification and probe adaptive mounting.
[0052] Specifically, this step first requires reading the server kernel's BTF type function specification information, which is typically stored in a compact binary format of type blocks and string blocks. Then, the type blocks are parsed to obtain the kernel function's parameter type ID and return value type ID, and the specific parameter types are determined by associating them with the kernel's predefined type dictionary. The string blocks are parsed to extract text information such as function names, parameter names, and type names, and this information is correlated with the type block data to reconstruct a complete function signature. Simultaneously, integrity checks are performed to remove invalid function data that fails to parse, ensuring the usability of the parsing results.
[0053] Furthermore, all parsed kernel functions are traversed, kernel network functions are filtered according to preset rules, and the list of function parameter types is checked. Kernel network functions are retained, and the function name and function signature of each kernel network function are extracted. Combined with the kernel symbol table ( / proc / kallsyms), the corresponding kernel virtual address is queried by matching the function name to generate function index information containing function name, function address, and function signature.
[0054] It should be noted that after obtaining multiple kernel network functions and their corresponding function index information, a BTF type function database can be created. During creation, a hash table can be used as the core index structure, with the function name and function address as the primary keys, to establish a mapping relationship with the function index information, and finally generate the BTF type function database.
[0055] In some embodiments, the BTF type function database is also configured with a dynamic update mechanism. When a kernel version upgrade or kernel module change is detected, the BTF information is automatically re-parsed and the database is rebuilt to ensure data timeliness. At the same time, the database is temporarily stored in memory to ensure query efficiency and is periodically written to the local disk to prevent data loss.
[0056] S23. For each target kernel network function, determine the position number of the target parameter in the parameter list in the target kernel network function according to the function index information.
[0057] S24. Based on the position number, match the corresponding kernel probe program from multiple preset kernel probe programs, and attach the kernel probe program to the corresponding target kernel network function.
[0058] Specifically, before the execution of S24 (matching the corresponding kernel probe program from multiple preset kernel probe programs according to the position number, and attaching the kernel probe program to the corresponding target kernel network function), the method further includes: Step 1: Determine whether the target kernel network function meets the monitoring conditions.
[0059] The monitorable conditions include: the function address of the target kernel network function belongs to the kernel function address mapping table, and it is neither an inline function nor a static function.
[0060] It should be noted that the monitorable condition refers to the core prerequisite that the kernel function can be effectively hooked and data collected by the kprobe / eBPF probe, which must be satisfied simultaneously: the function address of the target kernel network function belongs to the kernel function address mapping table, and it is neither an inline function nor a static function.
[0061] Specifically, the function address of the target kernel network function must exist in the kernel function address mapping table. This is because the table is a set of legal kernel function addresses generated based on the kernel symbol table ( / proc / kallsyms), containing all global function addresses that can be recognized by the kernel symbol table, excluding invalid / illegal memory addresses.
[0062] The target kernel network function must be neither an inline function nor a static function because inline functions are embedded into the caller's code during compilation, have no independent entry address, and cannot be hooked by kprobe; static functions are only visible inside the kernel module and have no exposed symbol address, so probes cannot locate them.
[0063] Furthermore, in this step, the / proc / kallsyms file (kernel runtime symbol table) is read first, and the function addresses and function attribute identifiers of all kernel functions are extracted. That is, the first hexadecimal address of each line in the symbol table is extracted (such as ffffffff81a0b120), and the type mark in the symbol table is used to determine (such as T represents global function, t represents static function, I represents inline function), and the attribute identifier is associated with the address.
[0064] Then, based on the above data, a kernel function address mapping table is constructed. It can be stored using a hash table structure, which supports quick attribute lookup via function address.
[0065] In some embodiments, if the address exists in the table, the address is determined to be valid; if the address does not exist (e.g., the address is empty, exceeds the kernel address space, or is not recognized by the symbol table), the address is determined to be invalid, and the function is directly marked as unmonitorable.
[0066] Furthermore, for target kernel network functions with valid addresses, the function attributes in the kernel function address mapping table are queried. If the attribute is non-inline and non-static, it is determined to be compliant; if the attribute is an inline function or a static function, it is determined to be non-compliant, and the function is marked as unmonitorable.
[0067] That is, if both the address is valid and the attributes are compliant, the target kernel network function is determined to meet the monitoring conditions; if either condition is not met, it is marked as an unmonitorable function and removed, and will not enter the subsequent probe mounting process.
[0068] Step 2: If yes, then according to the position number, match the corresponding kernel probe program from multiple preset kernel probe programs, and attach the kernel probe program to the corresponding target kernel network function.
[0069] Specifically, the pre-compiled kernel probe program refers to a standardized program set pre-compiled based on eBPF technology. Each program corresponds to a unique target parameter position number (such as position 1 probe, position 2 probe, ..., position n probe). The program has built-in security access logic for the corresponding position parameters (such as reading the first sock* parameter, the second sock* parameter), and can be adapted to functions with the same position parameters without modification.
[0070] The process of attaching the kernel probe program to the corresponding target kernel network function refers to the process of hooking the eBPF probe program to the entry point (triggered when the function is called) and exit point (triggered when the function returns) of the target kernel network function through the kprobe / kretprobe kernel interface. This process does not require modification of the kernel source code or loading of additional kernel modules. It is completed only through the eBPF sandbox interface, with zero intrusion and no risk of system crash.
[0071] Furthermore, for the target kernel network functions determined to meet the monitoring conditions in step 1, based on the position number of each target kernel network function, a preset kernel probe program corresponding to the position number is matched (e.g., if position number = 1, probe program P1 is matched; if position number = 2, probe program P2 is matched). The probe program is then hooked to the function address of the target function and configured to be triggered when the function is called, in order to collect data such as function input parameters and call time.
[0072] S25. When the target kernel network function is called, kernel network event data is collected through the kernel probe program.
[0073] S26. Obtain multi-dimensional filtering conditions, and filter the kernel network event data based on the multi-dimensional filtering conditions to obtain target kernel network event data.
[0074] Specifically, the multi-dimensional filtering conditions can be filtering conditions set by the centralized monitoring platform according to actual needs. The multi-dimensional filtering conditions include at least one of process dimension conditions, network dimension conditions, and container dimension conditions. The process dimension conditions include the target PID range and the target process name. The network dimension conditions include the target IP address range, the target port range, and the target protocol type. The container dimension conditions include the target container ID.
[0075] Among them, the process dimension condition focuses on the precise filtering of business processes, mainly including the target PID range and the target process name. The target PID range is used to limit specific processes or process groups (such as only monitoring network events generated by processes with PIDs of 1000 to 2000), and the target process name is used to match specific business processes (such as only monitoring the network behavior of the "nginx" and "mysql" processes). By filtering by the process dimension, kernel network events can be directly associated with specific business processes, realizing the precise binding of processes and network behaviors.
[0076] Network dimension conditions are used to filter network transmission characteristics, including target IP address ranges, target port ranges, and target protocol types. Specifically, the target IP address range is used to limit the source / destination IP range of communication (e.g., only monitoring data exchanged with the 192.168.1.0 / 24 network segment), the target port range is used to focus on specific service ports (e.g., only monitoring network events on ports 80 and 443), and the target protocol type is used to filter network behavior of different protocols such as TCP, UDP, and Unix Domain Socket. By filtering network dimensions, irrelevant network communication data can be eliminated, focusing on network interactions for core business purposes.
[0077] Container-level conditions refer to adapting to cloud-native containerized deployment scenarios, mainly based on the target container ID. By matching the container ID, kernel network events generated by processes within a specified container can be filtered out, enabling precise monitoring at the container level. This addresses the pain point of traditional monitoring solutions where it is difficult to isolate network behavior of processes within containers, and adapts to the monitoring needs of mainstream container environments such as Kubernetes and Docker.
[0078] The embodiments of this application, through the above-mentioned multi-dimensional filtering conditions, can be flexibly configured according to business monitoring needs, ensuring that the filtered target kernel network event data is highly matched with the actual monitoring scenario, reducing redundant data from the source, and improving monitoring efficiency and accuracy.
[0079] Furthermore, after the eBPF probe collects raw kernel network event data, the kernel-mode filtering module reads the multi-dimensional filtering conditions in the eBPFmap to filter and screen the raw data. This involves first quickly eliminating irrelevant data based on high-frequency dimensions such as protocol type and container ID, and then matching candidate data one by one against specific conditions such as process, address, and function. Data that fully matches the filtering conditions is marked as target kernel network event data and retained, while data that does not meet the conditions is directly discarded in kernel mode to prevent invalid data from entering subsequent transmission processes. Simultaneously, the filtering conditions support hot updates, allowing for real-time synchronization to kernel mode when monitoring requirements change, without interrupting the monitoring process.
[0080] S27. The target kernel network event data is sent to the monitoring platform so that the monitoring platform receives and parses the target kernel network event data, performs standardization processing, and outputs the data.
[0081] In this embodiment of the application, this step is mainly to achieve secure transmission and unified processing of target data, eliminate data format differences between multiple nodes and multiple kernel versions, and provide users with intuitive and usable monitoring and analysis results.
[0082] After receiving the reported target kernel network event data, the monitoring platform parses the data to extract core fields such as process, network, container, time, and function. The data is then standardized, which may include the following: The target kernel network event data is parsed to extract process information, network information, function call stack information, and timestamp information. The extracted information is then verified for completeness, outliers are removed, and missing fields are filled in.
[0083] Specifically, the target kernel network event data is stored in kernel mode in a compact binary format (balancing transmission efficiency and storage space). After receiving the target kernel network event data, the monitoring platform first needs to parse the binary data according to the preset field and offset mapping rules to extract the following: process information, network information, function call stack information, and timestamp information. Furthermore, the system performs integrity checks on the extracted core information and identifies and removes outliers (such as invalid IP addresses, port numbers outside the legal range, and null function call stacks) using preset rules. For missing fields (such as connection states not collected in some scenarios), it completes default values or marks missing fields based on the characteristics of the same batch of data. At the same time, it performs data type conversion between kernel mode and user mode, that is, it converts the kernel-specific 32 / 64-bit address format and kernel time format into a unified user-mode standardized data format (such as 64-bit unified address format and UTC standard timestamp), eliminating data format differences between different kernel versions and different nodes, and ensuring the aggregateable analysis of multi-node data.
[0084] Preferably, the standardized data can also be enriched to supplement information strongly associated with business entities. This includes reading the server's / proc file system, obtaining the complete command-line information and the username of the process through the PID association, and calling container runtime interfaces (such as Docker API and K8s API) to query the Pod name, namespace, and host information of the container through the container ID. In this way, the enriched data can be used to directly locate "a certain network behavior of a certain process under a certain Pod", solving the problem of the disconnect between traditional monitoring data and business.
[0085] Finally, the processed enriched data is output in a format that aligns with user habits. For example, it can be displayed through a monitoring dashboard, which shows the values and status of core metrics (such as TCP connection count, UDP packet transmission rate, and number of abnormal events) in real time, and supports quick filtering by process, container, protocol, and other dimensions.
[0086] It can also be displayed as a trend chart, that is, generate historical trend curves at the hour / day / week / month level (such as the network latency change of a Pod, the function call frequency fluctuation of a process), to assist in performance analysis and fault tracing.
[0087] It can also be displayed as an anomaly alarm notification. When data indicators exceed preset thresholds (such as function call latency exceeding limits or abnormal connection error rate), alarms are pushed via SMS, email, platform pop-ups, etc., with details such as the node IP, container ID, and function name of the abnormal event to help quickly locate the problem.
[0088] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0089] Embodiments of this application also provide a server network monitoring device, which corresponds one-to-one with the method claims. Figure 3 This is a schematic diagram of the structure of a server network monitoring device 300 provided in this disclosure, as shown below. Figure 3 As shown, the device 300 of this embodiment includes: The acquisition unit 31 is used to acquire function index information of multiple target kernel network functions in the BTF type function database; the BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters; The determining unit 32 is used to determine the position number of the target parameter in the parameter list of each target kernel network function according to the function index information; Matching unit 33 is used to match the corresponding kernel probe program from multiple preset kernel probe programs according to the position number, and to attach the kernel probe program to the corresponding target kernel network function; The acquisition unit 34 is used to acquire kernel network event data through the kernel probe program when the target kernel network function is called.
[0090] As an optional implementation of this application, the acquisition unit 31 is specifically used to read the BTF type function specification information of the server kernel; identify the BTF type function specification information, and obtain each kernel network function and the function index information of the kernel network function to create the BTF type function database; the function index information includes: function name, function address and function signature.
[0091] As an optional implementation of this application, the acquisition unit 34 is further configured to acquire multi-dimensional filtering conditions, and filter the kernel network event data based on the multi-dimensional filtering conditions to obtain target kernel network event data; and send the target kernel network event data to the monitoring platform so that the monitoring platform receives and parses the target kernel network event data, and outputs it after standardization processing.
[0092] As an optional implementation of this application, the matching unit 33 is further configured to determine whether the target kernel network function meets the monitorable conditions; the monitorable conditions include: the function address of the target kernel network function belongs to the kernel function address mapping table and is not an inline function or a static function; if so, then according to the position number, the corresponding kernel probe program is matched from multiple preset kernel probe programs, and the kernel probe program is mounted onto the corresponding target kernel network function.
[0093] As an optional implementation of this application, the preset kernel probe program is a program assembly pre-compiled based on eBPF technology, and each preset kernel probe program is associated with its corresponding position number; the matching unit 33 is specifically used to query the mapping relationship table through the position number of the target parameter to determine the kernel probe program that matches the position number; the mapping relationship table includes the correspondence between the position number and the preset kernel probe program.
[0094] As an optional implementation of this application, the multidimensional filtering conditions include at least one of process-dimensional conditions, network-dimensional conditions, and container-dimensional conditions; the process-dimensional conditions include the target PID range and the target process name; the network-dimensional conditions include the target IP address range, the target port range, and the target protocol type; and the container-dimensional conditions include the target container ID.
[0095] As an optional implementation of this application, the acquisition unit 34 is specifically used to parse the target kernel network event data, extract process information, network information, function call stack information and timestamp information, and perform integrity verification on the extracted information, remove outliers and fill in missing fields.
[0096] For a description of the features in the embodiment of the server network monitoring device, please refer to the relevant description of the embodiment of the server network monitoring method, which will not be repeated here.
[0097] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described server network monitoring method embodiments.
[0098] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described server network monitoring method embodiments when it runs.
[0099] 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.
[0100] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described server network monitoring method embodiments.
[0101] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described server network monitoring method embodiments.
[0102] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0103] The above provides a detailed description of a server network monitoring method and apparatus provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A server network monitoring method, characterized in that, include: Obtain function index information of multiple target kernel network functions from a BTF type function database; the BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters; For each target kernel network function, the position number of the target parameter in the parameter list of the target kernel network function is determined according to the function index information; Based on the position number, the corresponding kernel probe program is matched from multiple preset kernel probe programs, and the kernel probe program is mounted onto the corresponding target kernel network function; When the target kernel network function is called, kernel network event data is collected through the kernel probe program.
2. The method according to claim 1, characterized in that, The step of obtaining the function index information of multiple target kernel network functions in the BTF type function database includes: Read the BTF type function specification information from the server kernel; The BTF type function specification information is identified to obtain each kernel network function and its function index information in order to create the BTF type function database; the function index information includes: function name, function address and function signature.
3. The method according to claim 1, characterized in that, After the kernel network event data is collected by the kernel probe program when the target kernel network function is called, the method further includes: Obtain multi-dimensional filtering conditions, and filter the kernel network event data based on the multi-dimensional filtering conditions to obtain target kernel network event data; The target kernel network event data is sent to the monitoring platform so that the monitoring platform can receive and parse the target kernel network event data, and output it after standardization processing.
4. The method according to claim 1, characterized in that, Before matching the probe program according to the location number, the method further includes: Determine whether the target kernel network function meets the monitorability conditions; the monitorability conditions include: the function address of the target kernel network function belongs to the kernel function address mapping table, and it is neither an inline function nor a static function; If so, then according to the position number, the corresponding kernel probe program is matched from multiple preset kernel probe programs, and the kernel probe program is mounted to the corresponding target kernel network function.
5. The method according to claim 1, characterized in that, The preset kernel probe program is a program assembly pre-compiled based on eBPF technology, and each preset kernel probe program is associated with its corresponding position number. The step of matching the corresponding kernel probe program based on the position number includes: The kernel probe program that matches the location number is determined by querying the mapping table using the location number of the target parameter. The mapping table includes the correspondence between the position number and the preset kernel probe program.
6. The method according to claim 3, characterized in that, The multidimensional filtering conditions include at least one of process-dimensional conditions, network-dimensional conditions, and container-dimensional conditions; the process-dimensional conditions include the target PID range and the target process name; the network-dimensional conditions include the target IP address range, the target port range, and the target protocol type; and the container-dimensional conditions include the target container ID.
7. The method according to claim 3, characterized in that, The standardized processing of the target kernel network event data by the monitoring platform includes: The target kernel network event data is parsed to extract process information, network information, function call stack information, and timestamp information. The extracted information is then verified for completeness, outliers are removed, and missing fields are filled in.
8. A server network monitoring device, characterized in that, include: The acquisition unit is used to acquire function index information of multiple target kernel network functions in a BTF type function database; the BTF type function database includes multiple kernel network functions and the function index information of each kernel network function; the target kernel network function is a kernel network function in the BTF type function database that includes target parameters; The determining unit is used to determine, for each target kernel network function, the position number of the target parameter in the parameter list according to the function index information; The matching unit is used to match the corresponding kernel probe program from multiple preset kernel probe programs according to the position number, and to attach the kernel probe program to the corresponding target kernel network function. The acquisition unit is used to acquire kernel network event data through the kernel probe program when the target kernel network function is called.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a computing device, causes the computing device to perform the steps of the server network monitoring method according to any one of claims 1-7.
10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the server network monitoring method as described in any one of claims 1 to 9 when executing the computer program.