Semantic monitoring and causal delimiting method for affairs of electricity consumption information acquisition terminal

Abstract

The invention discloses an electricity consumption information acquisition terminal transaction semantic monitoring and causal delimiting method, which comprises the following steps: acquiring an application protocol data unit by utilizing an eBPF probe, generating a cross-layer unique transaction fingerprint based on extracted sessions, objects, businesses and calling identifiers, and generating a transaction event record by utilizing a pairing state machine; constructing a transaction observation window containing front and back extensions by taking a transaction observation timestamp as a reference, and screening and aggregating kernel events associated with the transaction fingerprint to obtain a transaction evidence set; and constructing a directed evidence graph based on the set, and calculating the confidence coefficient of each root cause category by using a scoring rule and an index normalization algorithm. According to the invention, non-intrusive deep observation of power acquisition business affairs is realized, and the automation level and fault diagnosis precision of power terminal operation and maintenance are improved.

Description

Technical Field

[0001] This application belongs to the field of power system monitoring and fault diagnosis, and in particular to a semantic monitoring and causal delimitation method for electricity information collection terminals. Background Technology

[0002] With the deepening of smart grid construction, electricity information collection terminals, as key hubs connecting smart meters and the main station system, directly affect the integrity of electricity data collection and the timeliness of fee control command execution due to their operational stability. Deep, real-time operational status monitoring and fault localization of edge-side devices such as concentrators are of significant research and engineering value for ensuring the high reliability and performance optimization of the power Internet of Things (IoT) system.

[0003] Currently, traditional methods for monitoring and maintaining concentrators primarily rely on deploying agent programs in user space to periodically retrieve system resource metrics such as CPU and memory usage or analyze application logs to infer the device's operational status. These methods mainly utilize standard interfaces provided by the operating system to obtain macro-level statistical information from an application layer perspective, thereby inferring the health of communication links and the activity level of business processes. However, in resource-constrained embedded environments, blind spots often exist in the observation process.

[0004] Existing monitoring solutions have significant shortcomings in terms of in-depth observation transparency and cross-layer causal correlation. Specifically, traditional methods suffer from a disconnect between business transaction semantics and kernel operational characteristics, making accurate delimitation difficult in the event of complex faults. Due to a lack of awareness of power protocol semantics, traditional solutions cannot establish a stable one-to-one correspondence between discrete network retransmissions or scheduling delays and specific business transactions (such as meter reading and fee control), resulting in monitoring conclusions often remaining at the level of macroscopic phenomenon descriptions, failing to address the underlying causes of business failures. In long-connection multiplexing or multi-threaded concurrent environments, simple port-level traffic mapping mechanisms cannot provide reliable business identification, leading to severe misalignment in cross-layer evidence aggregation. The disconnect between business boundaries and kernel boundaries prevents the system from causally fusing evidence such as network, system calls, and scheduling within a unified time window, making fault diagnosis highly dependent on manual experience and inefficient. Summary of the Invention

[0005] The purpose of this invention is to provide a method for semantic monitoring and causal delimitation of transactions in an electricity information collection terminal, so as to solve the above-mentioned problems existing in the prior art.

[0006] According to one aspect of this application, a method for semantic monitoring and causal delimitation of transactions in an electricity information collection terminal includes: Use the Extended Berkeley Packet Filter (eBPF) to obtain the application protocol data unit of the target process; Extract the session identifier, object identifier, business identifier, and call identifier from the application protocol data unit, and generate a transaction fingerprint based on them; Based on transaction fingerprinting, a request and response pairing state machine is used to pair business requests and business responses to obtain transaction event records. A transaction observation window is constructed based on the observation timestamps in the transaction event record, and kernel events that are associated with the transaction fingerprint and fall into the transaction observation window are filtered to obtain the transaction evidence set. A directed evidence graph is constructed based on the transaction evidence set, and the confidence level of each root cause category is calculated according to preset rules to obtain the root cause delineation conclusion.

[0007] According to another aspect of this application, an electricity consumption information collection terminal monitoring system includes: The transaction semantics module is used to obtain the application protocol data unit of the target process using the extended Berkeley packet filter eBPF, generate transaction fingerprints, and obtain transaction event records based on the transaction fingerprints. The causal delimitation module is used to construct a transaction observation window based on the observation timestamps in the transaction event record, and to filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain a transaction evidence set. The causal delimitation module is also used to construct a directed evidence graph based on the transaction evidence set, calculate the confidence level of each root cause category, and obtain the root cause delimitation conclusion.

[0008] Beneficial effects: Through the above technical solutions, this invention achieves non-intrusive in-depth observation of power acquisition business transactions, improving the automation level of power terminal operation and maintenance and the accuracy of fault diagnosis. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the overall process of semantic monitoring and causal delimitation method for electricity information collection terminal transactions.

[0010] Figure 2 This is a schematic diagram of the process of performing session reassembly on a fragment stream to obtain application protocol data units.

[0011] Figure 3 This is a schematic diagram of the process for generating a transaction fingerprint.

[0012] Figure 4 This is a schematic diagram of the process for obtaining a set of transaction evidence. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] Example 1: A general scheme for semantic monitoring and causal delimitation of transactions in electricity information collection terminals is provided, such as... Figure 1 As shown, this paper elaborates on the complete closed-loop logic for in-depth observation and fault delimitation of power data acquisition services using kernel programmable technology. By dynamically injecting lightweight probes into the kernel, this solution can accurately identify transaction boundaries in the business logic and establish causal relationships with network, scheduling, and other events at the kernel level, thus solving the problems of difficult delimitation and strong intrusion of traditional monitoring methods on resource-constrained power terminals.

[0015] Step 101: Use the Extended Berkeley Packet Filter (eBPF) to obtain the Application Protocol Data Unit of the target process.

[0016] Specifically, the Extended Berkeley Packet Filter (eBPF) is a programmable execution mechanism running in kernel mode, enabling deep observability without modifying the kernel source code or interfering with service operations. In this embodiment, the eBPF achieves non-intrusive interception of data paths by dynamically loading a predetermined set of probe instructions in kernel mode. The target process can be a critical service process running in the electricity information collection terminal, such as a communication management process for protocol processing, a protocol library parsing process, or a master station interaction process. The Application Protocol Data Unit (APDU) in this embodiment refers to an application layer data packet conforming to the power industry standard communication protocol, such as a data frame in the DL / T645 protocol or an application module in the DL / T698.45 protocol. By setting probe points in the kernel network protocol stack or user-mode function boundaries, the eBPF can directly read the raw byte stream in the memory buffer.

[0017] Step 102: Extract the session identifier, object identifier, business identifier, and call identifier from the application protocol data unit, and generate a transaction fingerprint based on the session identifier, object identifier, business identifier, and call identifier.

[0018] Specifically, the session identifier is a stable identifier used to distinguish different communication connections or session contexts; for example, in network communication, it can be a kernel-unique identifier corresponding to a socket. The object identifier is a unique identification code for the energy meter or data acquisition terminal, such as meter address information. The service identifier is an encoding used to describe the transaction type, such as data reading, control, parameter setting, and other service operation types. The call identifier is a sequence number or derived sequence number inherent in the protocol, used to distinguish multiple consecutive interactions within the same session. In this embodiment, the above metadata is extracted by parsing the header and data fields of the APDU. The transaction fingerprint, or TxFp, is a fixed-length digest generated using the above identifier information through a preset hash algorithm, used as a unique primary key for cross-layer data association.

[0019] Step 103: Based on transaction fingerprints, use the request and response pairing state machine to pair business requests and business responses to obtain transaction event records.

[0020] In this embodiment, the request and response pairing state machine maintains the lifecycle state of each transaction fingerprint. Specifically, the state machine includes at least an initial state, a request-monitored state, and a completed state. When a request message is detected, the system creates or updates a state record based on the transaction fingerprint. A service request refers to a read or set instruction initiated by the terminal, while a service response refers to the result or exception response returned by the peer. When the state machine successfully captures a request and response sequence with the same transaction fingerprint within a preset time window, it determines that the pairing is successful and generates a transaction event record containing the transaction start and end times, service type, and success flag.

[0021] Step 104: Construct a transaction observation window based on the observation timestamp in the transaction event record, and filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain the transaction evidence set.

[0022] Specifically, a transaction observation window is a time slice constructed from the request timestamp of a single transaction to the response timestamp. To cover associated kernel behaviors before the request is sent and after the response is received, the transaction observation window typically includes a certain amount of extension at both ends of the timeline. Kernel events are system-level behaviors captured by eBPF probes during transaction execution, such as TCP retransmission events, system call blocking events, process context switching, and CPU scheduling delays. The system compares the timestamps of kernel events with the transaction observation window and performs secondary verification using process identifiers or connection identifiers to extract underlying evidence with potential causal relationships to the current business transaction, thus forming a transaction evidence set.

[0023] Step 105: Construct a directed evidence graph based on the transaction evidence set, and calculate the confidence level of each root cause category according to preset rules to obtain the root cause delimitation conclusion.

[0024] In this embodiment, the directed evidence graph is a data structure that expresses the inferential relationship between kernel-level metrics and upper-layer business faults. The vertex set corresponds to each evidence item in the transaction evidence set, while the edge set corresponds to preset causal dependency rules. Through graph analysis algorithms, the system can accumulate weights along causal paths. Root cause categories specifically include network link failures, peer master station anomalies, local protocol library logic conflicts, and system scheduling resource contention. By normalizing the confidence scores of different paths, the root cause category with the highest confidence probability is finally output as the root cause delimitation conclusion, guiding operations personnel to conduct targeted troubleshooting.

[0025] Through the above steps, the present invention realizes the following causal chain: the generation of transaction fingerprints (step 102) establishes a unique mapping between discrete network packets and specific business transactions, solving the problem of misalignment of traditional port-level mapping in long connection reuse scenarios; the construction of transaction observation windows (step 104) accurately slices kernel events within the transaction lifecycle, avoiding interference from background noise; the directed evidence graph and confidence calculation (step 105) realize quantifiable reasoning from underlying indicators to business faults, and elevates the delimitation conclusion from subjective experience judgment to probabilistic automatic diagnosis.

[0026] Example 2 details the terminal hardware constraints, software kernel version requirements, and probe security management process necessary for implementing this method. Since the electricity information acquisition terminal (often referred to as a concentrator) is a resource-constrained edge device, it has high requirements for overhead control and security of the monitoring components.

[0027] In this embodiment, the electricity information acquisition terminal is equipped with a microprocessor based on the ARM architecture and runs an embedded Linux kernel. To support eBPF technology features, in a typical embodiment, the kernel version can be Linux kernel 4.19.232 or higher. In other embodiments, the system can also run on Linux kernel 4.14 or higher, but some advanced features (such as BTF support) may be limited. Considering that multiple service instances may run simultaneously in the concentrator, this embodiment introduces a control group identifier (CgroupId) as an additional dimension during the data acquisition phase. The control group identifier is specifically a non-negative integer assigned to a predetermined set of processes by the Linux kernel cgroup subsystem. By combining the control group identifier with the process identifier, the eBPF probe can accurately distinguish service traffic in different containers or isolated environments.

[0028] Furthermore, in this embodiment, the eBPF program must pass the kernel verifier's check before loading. The kernel verifier performs static analysis to ensure that the probe program does not contain infinite loops and that all memory accesses are within authorized limits, preventing the monitoring program from causing system crashes. After loading, the probe interacts with the user-space program through the kernel mapping table eBPF Map. Specifically, the kernel mapping table can use a hash-type Map to store connection states and a RingBuffer for asynchronously reporting high-frequency events, ensuring low CPU utilization while meeting sub-millisecond real-time requirements.

[0029] Furthermore, in this embodiment, the system implements the following fault tolerance mechanism: if the eBPF program fails to load, the system automatically degrades to user-space log parsing mode, obtains transaction information by parsing the standard logs output by the business process, but cannot obtain kernel-level evidence at this time; if the usage of the kernel mapping table eBPF Map exceeds a preset threshold (e.g., 80%), the system triggers an aging strategy to clean up recently inactive state entries to ensure the continuous availability of the system.

[0030] In this embodiment, the typical configuration parameters of the eBPF probe are as follows: the event sampling rate is 100% by default, that is, full collection, which can be dynamically adjusted to between 10% and 100% according to the system load; the event bandwidth budget is 5000 records per second by default, and the excess is randomly discarded; the capacity of the kernel map is configured to support a maximum of 10000 concurrent session states, and LRU eviction is triggered when the limit is exceeded.

[0031] Example 3 describes the dual-mode transaction extraction and session-level reassembly mechanism, and elaborates on the extraction scheme for the complexity of power protocol communication.

[0032] Step 301: Determine the communication channel type and protocol type of the target process based on the target process's configuration information or runtime attributes.

[0033] Specifically, the communication channel type specifies the physical carrier of the service traffic, such as an Ethernet TCP channel, a UDP channel, or an RS-485 serial port channel. The protocol type specifies the protocol followed by the message, such as the DL / T645-2007 protocol or the DL / T698.45 protocol. In this embodiment, the user-space configuration module determines the target process by scanning the process list and determines the corresponding channel and protocol attributes of the process based on the pre-maintained service file.

[0034] Step 302: If the target process has a preset application layer protocol decoding function, then attach the eBPF probe to the entry point of the application layer protocol decoding function and directly read the memory buffer to obtain the application protocol data unit.

[0035] In this embodiment, the application layer protocol decoding function refers to a pre-existing function interface in the business process used to parse complete application frames. For example, when the business program calls the parsing function in the dynamic link library, the eBPF probe is attached to the function's entry point as a user-space function probe (uprobe). At this time, since the application layer has already completed the underlying segmentation and assembly logic, the eBPF probe can directly read the memory buffer pointed to by the function's input parameter pointer. The above mode is defined as the first extraction mode, which has high data integrity and can directly obtain the application protocol data units after framing.

[0036] Step 303: If no application layer protocol decoding function exists, the eBPF probe is attached to the read / write entry point of the system call function to extract the fragment stream, and session reassembly is performed on the fragment stream to obtain the application protocol data unit, such as... Figure 2 As shown.

[0037] When the target process is statically linked or its internal decoding function cannot be accurately located, the system automatically switches to the second extraction mode. Specifically, the probe is attached to the entry point of the kernel system call in the form of a kernel probe (kprobe) or a tracepoint. System call functions include kernel interfaces for data transmission and reception such as send, recv, read, and write. Because the data captured by the system call layer is often limited by the TCP sliding window or Maximum Transmission Unit (MTU), it presents as discrete data fragments, i.e., fragmented streams. To reconstruct the business semantics from these fragments, session reassembly must be performed in subsequent stages.

[0038] Step 304: Maintain a reorganization buffer for the connection corresponding to the session identifier.

[0039] In this embodiment, the connection maintenance and reassembly buffer is specifically a circular byte queue allocated in kernel-mode Map or user-mode shared memory. For each independent session identifier, corresponding to each active TCP connection, the system allocates an independent buffer space. The capacity of the connection maintenance and reassembly buffer can be set according to specific protocol requirements, for example, set to 16384 bytes to handle longer application-layer messages.

[0040] Step 305: Write the data fragments in the fragment stream into the connection maintenance reassembly buffer in the order of arrival.

[0041] Specifically, when the eBPF probe captures a data segment returned by a system call, it synchronizes the segment and its sequence offset information in the stream to the connection maintenance and reassembly buffer. Based on this, the system maintains a read / write pointer to reassemble the discrete segment stream into a continuous byte sequence, ensuring that the timing logic of the data is consistent with the network transmission logic.

[0042] Step 306: Search the connection maintenance and reorganization buffer according to the preset frame structure features to determine the frame boundary, and obtain the application protocol data unit after extracting the complete frame data.

[0043] In this embodiment, the preset frame structure features specifically include the protocol's start byte, end byte, and length field definition. For example, for the DL / T645 protocol, the system searches for the start character 68H in the connection maintenance and reassembly buffer, reads the subsequent length field, and calculates the expected total length of the frame. If the length of continuous data in the buffer has reached the expected total length and the last byte is the expected end character 16H, it is determined to be a complete frame boundary. The system extracts this complete data segment from the buffer, obtains the application protocol data unit that conforms to the business semantics, and outputs it to the subsequent pairing process.

[0044] For example, suppose a DL / T645 message arrives split into two fragments. The first fragment contains the start symbol 68H and the first 10 bytes of data, and the second fragment contains the remaining 20 bytes and the end symbol 16H. In step 305, the system sequentially concatenates these two fragments into the connection maintenance reassembly buffer. In step 306, the parsing engine identifies the start symbol and detects that the total length of data (32 bytes) is ready, extracting the complete 32-byte APDU, thus ensuring the robustness of the monitoring system in complex network environments.

[0045] Example 4 details how to construct a cross-layer unique identifier using business semantic fields. In the power Internet of Things (IoT) environment, traditional five-tuple-based association methods are insufficient for handling long-connection reuse and multi-threaded concurrency scenarios. This solution constructs a transactional primary key and generates a fingerprint to achieve accurate binding between business layer transactions and kernel layer events, such as... Figure 3 As shown.

[0046] Step 401: Encapsulate the session identifier, object identifier, business identifier, and call identifier into a transaction primary key.

[0047] Specifically, the session identifier is a numerical value reflecting the uniqueness of the communication link. In this embodiment, when the communication channel is Ethernet, the system obtains the fixed identifier of the socket in the kernel as the session identifier. The object identifier is specifically the identity certificate of the physical device collected by the power terminal. For scenarios following the DL / T645 protocol, the system extracts the 6-byte BCD encoded address in the message address field as the object identifier; for scenarios following the DL / T698.45 protocol, the system extracts the logical address or physical address in the application layer address field as the object identifier. The service identifier is used to distinguish the specific operation type. For example, the system determines whether the current transaction is a meter reading service, a prepaid service, or a parameter setting service based on the control code or object attribute descriptor in the message, and converts it into the corresponding enumeration value as the service identifier. The call identifier is extracted using the sequence number provided by the protocol. If the protocol does not have an explicit sequence number, the system derives an incrementing integer as the call identifier by combining the current time slice sequence number with the characteristics of the request field. The transaction primary key is defined as a five-tuple structure containing the above four dimensions, represented as (ConnId, MeterId, ServiceId, InvokeId, Dir); where ConnId represents the session identifier, MeterId represents the object identifier, ServiceId represents the business identifier, InvokeId represents the call identifier, and Dir represents the transaction direction identifier.

[0048] Step 402: Concatenate the byte strings of each field in the transaction primary key according to a preset order to obtain the target sequence.

[0049] In this embodiment, the system converts the encapsulated fields into byte strings according to a fixed byte order. For example, the session identifier is converted into an 8-byte big-endian integer, the object identifier remains the original BCD-encoded byte string, the business identifier is converted into a 2-byte integer, and the call identifier is converted into a 4-byte integer. The system then concatenates these byte segments end-to-end in a preset order: session identifier first, object identifier in the middle, and business identifier and call identifier last, forming a target sequence that can completely represent the unique attribute of the business interaction. This concatenation method ensures the differences in data representation between different transactions, providing a highly discriminative input source for subsequent hash operations.

[0050] Step 403: Perform cyclic redundancy check calculation on the target sequence to obtain the transaction fingerprint.

[0051] Specifically, the system uses a cyclic redundancy check (CRC) algorithm to reduce the dimensionality of the target sequence, generating a fixed-length transaction fingerprint. In this embodiment, a 64-bit CRC64 algorithm is preferably used. The formula for calculating the transaction fingerprint is: TxFp=CRC64(TargetSequence); Where TxFp represents the generated transaction fingerprint, and TargetSequence represents the target sequence.

[0052] Alternatively, the formula for calculating the transaction fingerprint can also be: TxFp = CRC64(ConnId||MeterId||ServiceId||InvokeId); where CRC64 represents a 64-bit cyclic redundancy check function; ConnId represents the session identifier; || represents the concatenation operator, meaning byte string concatenation; MeterId represents the object identifier; ServiceId represents the service identifier; and InvokeId represents the call identifier.

[0053] Using the CRC64 algorithm, the system can map target sequences of varying lengths to a 64-bit unsigned integer. Compared to directly storing the original string, the 64-bit transaction fingerprint reduces the storage overhead of the kernel mapping table eBPF Map and improves the efficiency of data retrieval and matching in kernel space.

[0054] In some alternative implementations, the system can also employ other hash algorithms instead of cyclic redundancy check. For example, the MurmurHash3 or CityHash algorithms can be used to generate transaction fingerprints. These algorithms have lower collision probabilities and faster computation speeds when processing shorter power protocol fields, further optimizing performance in resource-constrained environments.

[0055] In some optional implementations, the system employs the following strategy to address hash collisions in transaction fingerprints: When two different transaction primary keys are detected to generate the same transaction fingerprint, the system uses a linked storage structure in the kernel Map to chain the conflicting entries together. During subsequent queries, the system sequentially compares the original transaction primary key fields of each entry in the linked list to ensure accurate matching.

[0056] Example 5 details the process of using state machines to handle complex interaction metrics and quantify business health. In a field environment, message retries, out-of-order delivery, and timeouts are the main causes of inaccurate monitoring data. This solution eliminates these interferences through fixed state machine rules.

[0057] Step 501: Maintain state variables for the transaction fingerprint. The values ​​of the state variables include at least the initial state, the request monitoring state, and the completion state.

[0058] Specifically, the state variable, or State, records the current stage of a transaction fingerprint within its pairing lifecycle. The initial state (INIT) indicates that the system has not yet captured any messages related to this transaction fingerprint. The request monitoring state (REQ_SEEN) indicates that the system has successfully identified the request message and is waiting for the corresponding response. The completion state (DONE) indicates that the request and response have been matched, and the transaction cycle has ended. In this embodiment, the system allocates an entry in the kernel hash table for each active transaction fingerprint, which is used to update and store the state variable in real time.

[0059] Step 502: Determine the direction identifier based on the control code or service type field in the application protocol data unit; if the direction identifier is a requested transaction event and the state variable is in the initial state, record the request observation timestamp and migrate the state variable to the request monitoring state.

[0060] In this embodiment, when the eBPF probe parses an application layer message and determines that its direction identifier is REQ (request direction), the system calculates its transaction fingerprint. If the fingerprint is found to be in the initial state in the table, the system obtains the current high-precision time by reading a monotonic clock and records it as the request observation timestamp, i.e., t. _req The system updates the status of the entry to "request monitoring" and begins the pairing timing logic.

[0061] Step 503: If a transaction event with a direction identifier of "response" is observed in the preset pairing window and the state variable is in the "request monitoring" state, then record the response observation timestamp, migrate the state variable to the "complete" state, and determine that the pairing is successful.

[0062] Specifically, the preset pairing window, W, is the maximum tolerable time for the system to wait for a response. In this embodiment, the preset pairing window can be set to 2000 milliseconds. If, within window W, the system captures a message with the direction identifier RESP (response direction) and its transaction fingerprint matches an entry in the table that is in the request monitoring state, then the system records the response observation timestamp, t. _resp At this point, the system determines that the transaction has completed a successful closed-loop interaction, transitions the state to the completed state, and outputs a pairing success signal.

[0063] For example, suppose that at time T=100ms, the system captures a transaction event with the direction identifier REQ and its transaction fingerprint TxFp=0xA1B2C3D4. At this time, the state variable State transitions from the initial state INIT to the request monitoring state REQ_SEEN, and records the request observation timestamp t. _req =100ms. Preset pairing window W=2000ms. If a transaction event with a direction identifier of RESP and a matching transaction fingerprint is captured at time T=150ms, then record t. _resp=150ms, the state transitions to DONE, pairing successful. If no response is received by T=2100ms, a timeout is determined, and the state is reset to INIT.

[0064] Step 504: If the same transaction fingerprint corresponding to the request direction transaction event is observed multiple times within the pairing window, the number of retries is accumulated, and the request observation timestamp is updated according to the observation timestamp of the last request.

[0065] In this embodiment, the system handles the automatic retry mechanism initiated by the terminal through state detection. If the state is already in the request monitoring state, but a request message with the same fingerprint is received again within window W, the system increments the retry count associated with that entry, i.e., RetryCnt. To accurately reflect the final successful response time of the service layer, the system uses the time of the last request to overwrite the original request observation timestamp. This processing method can eliminate invalid retry waiting time and more realistically reflect the actual processing capabilities of the network and the peer site.

[0066] Step 505: If a response-direction transaction event is observed first and no matching request monitoring state is found, then the response-direction transaction event is temporarily stored as a pending response.

[0067] To address potential out-of-order issues during network transmission or kernel acquisition—specifically, situations where response messages are captured by the probe before request messages—the system uses a buffer. Specifically, the system stores the fingerprint and timestamp of the response message in a temporary pending list, PendingResp.

[0068] Step 506: If a corresponding request-direction transaction event is detected within the pairing window, the pairing is completed using the pending response and the process is transitioned to the completed state.

[0069] In this embodiment, if a delayed request message is captured within a subsequent window W, a matching pending response is immediately extracted from the pending list. At this point, the system uses the delayed request timestamp to logically pair it with the existing response timestamp, thus mitigating the packet loss statistics bias caused by out-of-order data collection.

[0070] Step 507, using formula L _tx =t _resp -t _req Calculate transaction latency, where t _resp In response to the observation timestamp, t _req This is to request the observation timestamp.

[0071] In this embodiment, the system performs latency calculation immediately after pairing is completed. Transaction latency is L. _tx The unit is microseconds. For example, if t _resp500500 microseconds, t _req If the value is 500100 microseconds, then L is calculated. _tx =500500-500100=400 microseconds.

[0072] Step 508: When it is determined that the pairing is successful and the result code in the application protocol data unit belongs to the pre-configured success code set, the single transaction success flag is set to 1; otherwise, it is set to 0.

[0073] Specifically, the system parses the business result codes in the response message. The success code set, or OK_SET, pre-stores all normal response codes defined in the protocol. If a match is successful and the result code belongs to the OK_SET set, then the single transaction success flag, i.e., Success, is set. _i The value is set to 1; if a timeout, verification failure, or response message indicates a service abnormality, then Success is set to 1. _i The value is assigned to 0.

[0074] Step 509, using the formula SR=(∑(Success) _i The success rate is calculated as ,i=1..N)) / N, where SR is the success rate, and Success _i Let N be the single-transaction success flag for the i-th transaction, and N be the total number of transactions within the statistical window. Transaction latency and success rate are written to the transaction event record for subsequent root cause analysis.

[0075] In this embodiment, the system aggregates and calculates all transactions within a fixed statistical window (e.g., 60 seconds) at the end of each window. The success rate, or SR, reflects the health of the business layer. For example, if there are N=100 transactions within a statistical window, and the success rate is... _i If the number of transactions with a value of 1 is 98, then SR = 98 / 100 = 0.98, which means the success rate is 98%.

[0076] In some alternative implementations, the calculation of transaction latency can also use the timestamp of the first request as the starting point. Specifically, when a retry occurs, t _req Keep the time as the time of the first request, at which point the calculated transaction latency L is obtained. _tx This reflects the overall latency, including retry overhead. By outputting two different latency metrics side-by-side, operations personnel can more clearly distinguish whether a latency spike is caused by network retransmissions or by slow processing at the main site.

[0077] In a typical electricity consumption information collection scenario, the performance baseline of the method of this invention is as follows: For a single reading transaction according to the DL / T645 protocol, the transaction delay L under normal circumstances is... _txThe typical value is 50 to 200 milliseconds; if the transaction delay exceeds 500 milliseconds, the system marks it as an abnormal transaction and triggers evidence collection. Under stable operation, the expected success rate (SR) is higher than 98%; if the success rate is lower than 95% for three consecutive statistical windows, the system automatically increases the probe sampling rate to enhance diagnostic accuracy.

[0078] Example 6 details how to accurately align discrete kernel metrics to business transactions using both temporal and spatial dimensions. In complex power acquisition environments, the terminal kernel generates massive amounts of low-level events per second. By establishing a unified evidence encapsulation format and utilizing transaction lifecycles for windowed slicing, background noise can be effectively eliminated, providing clean data input for subsequent causal delimitation.

[0079] Step 601: Encapsulate the transaction event record and the acquired kernel observation event into a unified evidence entry; wherein, the evidence entry includes event type, object identifier, event start time, event end time, event value, and tag set; the object identifier is set as the transaction fingerprint; if the kernel observation event cannot be directly bound to the transaction fingerprint, the object identifier is determined through the mapping relationship between the session identifier and the transaction fingerprint.

[0080] Specifically, kernel observation events refer to low-level runtime data collected by the extended Berkeley packet filter probe from the kernel network protocol stack, scheduler, or system call interface. Event types are used to distinguish runtime characteristics from different sources; for example, a value of NET_RETRANS indicates a network retransmission event, SYSCALL_BLOCK indicates a system call blocking event, and SCHED_LAT indicates a CPU scheduling wait delay event. In this embodiment, the object identifier acts as a global association primary key. For transaction event records directly parsed from business packets, the object identifier directly uses the transaction fingerprint. For kernel observation events, since kernel functions typically only perceive process identifiers or connection identifiers, the system retrieves the corresponding transaction fingerprints by maintaining a real-time updated mapping table. For example, when the probe captures a TCP retransmission event, it first extracts the corresponding session identifier, queries the mapping table for the transaction fingerprint currently being executed on that session identifier, and then populates the object identifier of that evidence entry accordingly. The tag set is used to carry additional contextual information, such as the corresponding process name, protocol version number, and role label of the collection point, to facilitate fine-grained filtering in complex evidence chains later.

[0081] Step 602: Construct a transaction observation window and filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain a transaction evidence set, such as... Figure 4As shown, this includes: obtaining the pre-configured window pre-expansion amount Δpre and window post-expansion amount Δpost; subtracting the window pre-expansion amount from the request observation timestamp to obtain the window start time, and adding the window post-expansion amount to the response observation timestamp to obtain the window end time, thus obtaining the transaction observation window, which is represented as: Win(TxFp)=[t _req -Δpre,t _resp +Δpost]; Where Win stands for Window; TxFp represents transaction fingerprint; t _req Indicates the requested observation timestamp; Δpre is the window front expansion amount; t _resp This represents the timestamp of the response observation; Δpost is the window extension amount.

[0082] The generated sequence of evidence entries is selected from those whose time intervals intersect with the transaction observation window and whose object identifiers match the transaction fingerprints, and these are then aggregated into a transaction evidence set.

[0083] In this embodiment, the settings of the window pre-expansion Δpre and window post-expansion Δpost are designed to cover observation delays caused by kernel buffering or asynchronous processing. For example, in a typical read transaction, network protocol stack retransmissions may occur within a tiny timeframe before the request message is officially sent. By setting Δpre to 50 milliseconds, it can be ensured that the preceding triggers are included in the analysis. The transaction observation window is defined as a closed interval consisting of the start and end times. The filtering logic not only requires that the object identifier of the evidence entry strictly match the current transaction fingerprint, but also requires that the lifetime of the evidence entry, i.e., the interval from the event start time to the event end time, has a non-empty intersection with the transaction observation window on the time axis.

[0084] In this embodiment, the typical range for the window pre-expansion Δpre is 10 to 200 milliseconds, and the typical range for the window post-expansion Δpost is 10 to 500 milliseconds. The parameter selection follows these principles: the Δpre setting should cover the typical buffer latency of the kernel protocol stack; for TCP communication scenarios, a value of 50 milliseconds is recommended. The Δpost setting should cover the log refresh latency after response processing; for I / O-intensive systems, a value of 100 to 200 milliseconds is recommended. If Δpre is set too small, network anomalies before the request is sent may be missed; if it is set too large, excessive irrelevant noise may be introduced.

[0085] In some optional implementations, the pre-window extension Δpre and post-window extension Δpost can be dynamically adjusted based on the current system load or protocol type. For example, when high system I / O pressure is detected causing log refresh delays, the value of Δpost is automatically increased from 50 milliseconds to 200 milliseconds to prevent critical evidence from escaping the window due to time drift. Furthermore, the system can set differentiated extension strategies for different kernel event types to achieve more flexible evidence aggregation.

[0086] Example 7 details the process of transforming operational and maintenance troubleshooting experience into an automated, quantifiable delimitation algorithm. By organizing cross-layer evidence into a topological structure and applying a probabilistic inference model, the most confident cause can be identified from multiple suspected fault sources.

[0087] Step 701, constructing a directed evidence graph based on the transaction evidence set, includes: using the evidence entries in the transaction evidence set as a vertex set; establishing causal dependency edges between each evidence entry in the vertex set according to a preset rule set, and assigning weights to the causal dependency edges to obtain the directed evidence graph.

[0088] Specifically, in the directed evidence graph G(TxFp)=(V,EdgeSet), each vertex v corresponds to a selected evidence entry. The predefined rule set RuleSet defines the temporal logical and physical relationships between different events. For example, a typical causal edge rule can be described as follows: if a network retransmission event occurs first on the same connection and then a system call read block occurs, then an edge is established from the retransmission node to the blocking node, with a weight w. _e The historical statistical intensity was set to 0.8. Through this method, the previously scattered kernel metrics were organized into a topological network reflecting the fault propagation path. The directed graph clearly shows the logical chain from underlying resource anomalies to business transaction failures.

[0089] Step 702: Calculate the confidence level of each root cause category according to preset rules to obtain root cause delimitation conclusions, including: determining the key evidence items corresponding to each root cause category based on a pre-configured root cause feature mapping table; determining the key evidence indicator quantity based on whether there is a path satisfying the conditions in the directed evidence graph for the key evidence items; and calculating the score s of root cause category c using a formula. _c : s _c =∑(w _k ·I _k (k=1..K); Among them, w _k Let I be the weight of the k-th key piece of evidence. _k Let K be the indicator of the kth key evidence, where K is the number of key evidence items; Calculate the confidence level P(c) using the formula: P(c) = exp(s _c ) / ∑(exp(s _j ),j=1..M); Where M is the number of root cause categories, s _j The score for the j-th root cause category; The root cause category with the highest confidence level is output as the root cause delimitation conclusion.

[0090] In this embodiment, key evidence items refer to evidence nodes that are strongly correlated with a certain root cause category. For example, key evidence items corresponding to network link root causes include NET_RETRANS (network retransmission event) and TCP_TIMEOUT (TCP timeout). Key evidence indicator I _k Used to mark the existence of certain features in a graph. If, for a certain root cause category, its corresponding key indicator node appears in the directed evidence graph and has a clear in-degree and out-degree path, then I... _k The value is assigned as 1 if the evidence item is not found, and 0 otherwise. The system then assigns a value of 1 to each piece of evidence based on its preset weight w. _k Perform linear weighted summation to obtain the score s for each candidate root cause category. _c To select the most likely root cause in the presence of multiple confounding factors, the system introduces a Softmax transform for confidence normalization. In the calculation formula, exp is the natural exponential function, which amplifies the probability differences between categories with higher scores.

[0091] For example, suppose the preset root cause category set includes network link NET, master station response REMOTE_HOST, and local scheduling SCHED. In a transaction failure delimitation, the system calculates s _NET =4.2, s _REMOTE_HOST =1.1, s _SCHED =0.5. Substituting into the confidence formula, we get: P(NET) = exp(4.2) / (exp(4.2) + exp(1.1) + exp(0.5)). The calculated value of P(NET) is approximately 0.94, meaning the confidence level is 94%. Based on this, the system outputs the top-1 root cause conclusion as network link failure, and simultaneously outputs the evidence path with the highest weight in the directed evidence graph, clearly demonstrating to operations personnel the evidence chain from frequent TCP retransmissions to kernel protocol stack timeouts to business read failures.

[0092] In some optional implementations, the root cause delimitation conclusions may also include a set of secondary root causes. When the highest confidence level P(c) is lower than a preset ConfMin (minimum confidence level) threshold (e.g., 0.6), the system automatically triggers a conflict resolution mechanism, indicating the possible existence of a multi-factor superposition fault, and guides the system to initiate a higher-resolution probe for secondary verification. This multi-level probability output mechanism enhances the flexibility and fault tolerance of the delimitation results.

[0093] In this embodiment, the graph analysis algorithm specifically employs a depth-first search algorithm. Starting from the node where the transaction failed, the system traverses the directed evidence graph in the reverse direction of the causal dependency edges, identifying all reachable evidence nodes. During the traversal, the system accumulates the weights of the traversed edges and records the sum of path weights from the key evidence node corresponding to the root cause category to the node where the transaction failed.

[0094] In this embodiment, the preset rule set includes at least the following typical causal rules: Rule R1 (Network Retransmission -> Read Blocking): If, on the same session identifier, the end time of the NET_RETRANS event (network retransmission event) is earlier than the start time of the SYSCALL_BLOCK event (system call blocking event), and the time difference is less than 500 milliseconds, then a causal edge is established from the NET_RETRANS node to the SYSCALL_BLOCK node, with weight w. _e =0.8; Rule R2 (Scheduling Delay -> System Call Delay): If the duration of the SCHED_LAT event (CPU scheduling wait delay event) exceeds 10 milliseconds and overlaps with the SYSCALL_BLOCK event in time, then establish a causal edge from the SCHED_LAT node to the SYSCALL_BLOCK node, with weight w. _e =0.6; Rule R3 (Abnormal Process Exit -> Transaction Failure): If the PROC_EXIT event (process exit event) occurs within the transaction observation window, a causal edge is established from the PROC_EXIT node to the TX_FAIL (transaction failure) node, with weight w. _e =1.0.

[0095] Example 8 details how to utilize the feedback mechanism of root cause delineation conclusions to achieve a dynamic trade-off between monitoring accuracy and system overhead. Due to limited hardware resources in the electricity consumption information acquisition terminal, activating all eBPF probes at full capacity and high frequency would disrupt the service process. By introducing a dynamic adjustment mechanism based on confidence correlation, a balance between on-demand observation is achieved.

[0096] Step 801: Calculate the uncertainty of the root cause boundary conclusion. The uncertainty is 1 minus the confidence level.

[0097] Specifically, uncertainty characterizes the degree of certainty with which the current automated bounding algorithm arrives at its output conclusion. In this embodiment, the system acquires the highest confidence level P(Top1Cause) in real time, where Top1Cause represents the root cause category with the highest score. The formula for calculating uncertainty is: Uncertainty = 1 - Confidence; Here, Uncertainty represents uncertainty, and Confidence represents the confidence level of the root cause category with the highest probability value among the root cause results.

[0098] When the Confidence value approaches 1, it indicates that the chain of evidence discovered by the system is relatively complete, and the uncertainty approaches 0. Conversely, if there are multiple causal paths with similar weights in the evidence graph, resulting in a low Confidence value, the uncertainty increases accordingly.

[0099] Step 802: If the uncertainty is higher than the preset uncertainty threshold but within the resource budget, then execute the probe enhancement strategy to load auxiliary probes or increase the sampling rate.

[0100] In this embodiment, the preset uncertainty threshold is U _th Its default value can be set to 0.4. When the system detects ambiguity in the delimitation results, it will automatically assess the current resource budget range. The resource budget range specifically includes CPU budget, memory budget, and event bandwidth budget. Specifically, the CPU budget can be set to no more than 5% of the total system computing power; the memory budget can be set to no more than 64 megabytes; and the event bandwidth budget can be set to no more than 5000 observation events per second. If there is still a surplus of resources, the system will execute probe enhancement strategies. Probe enhancement strategies specifically include dynamically loading auxiliary probes with higher spatial resolution, such as switching from regular TCP layer observations to observations of the tcp_retransmit_skb kernel function (which is responsible for retransmitting the specified skb data to the tcp_retransmit_skb kernel function). _buff (i.e., the data packets to be sent) can be retransmitted at the TCP layer for deep tracking, or the sampling ratio of existing system call probes can be increased. By increasing the input density of observation data, the system can supplement missing evidence nodes and improve the certainty of conclusions in subsequent delimitation periods.

[0101] Step 803: If the uncertainty is lower than the preset uncertainty threshold and the stabilization time exceeds the preset period, then execute the probe deloading strategy to unload redundant probes or reduce the sampling rate.

[0102] Specifically, when the system continuously outputs high-confidence delimitation conclusions, and the duration of the deterministic state exceeds a preset period (StabTime), it indicates that the current fault mode has solidified or the business operation is in a healthy steady state. The preset period can be set to, for example, 300 seconds. At this time, the system executes a probe deload strategy. This strategy involves unloading high-overhead probes that contribute little to the current root cause analysis. For example, if the delimitation conclusions consistently point to network link failures, the system can temporarily unload the runqlat probe related to CPU scheduling delays, or reduce the sampling rate of system calls to 10% of its original value. Through these methods, the concentrator can return valuable computing resources to core business processes such as power data acquisition, minimizing the system burden while meeting monitoring requirements.

[0103] In some optional implementations, the system can also orchestrate probe plans based on the distribution of root cause categories. Furthermore, if the delineation results show that REMOTE_HOST (master station response), i.e., the peer master station is abnormal, has the highest confidence level, the system prioritizes unloading the local kernel-scheduled probes and instead maintains or enhances the sampling accuracy of the network protocol stack probes. In addition, the system will also perform real-time statistics on advanced performance metrics such as TimeoutRate and RetryRate. The TimeoutRate is defined as the number of transactions that timed out within the statistical window divided by the total number of transactions N. The RetryRate is defined as the number of transactions that have undergone at least one retry divided by the total number of transactions N. These metrics, as auxiliary judgment criteria, can work with the confidence level to determine the probe orchestration weights, making the entire monitoring scheme more intelligent.

[0104] Example 9: A detailed description of the physical composition of the electricity information collection terminal monitoring system and its deployment logic at the edge of the power Internet of Things.

[0105] This embodiment provides an electricity consumption information collection terminal monitoring system, which is built on the Linux 4.19.232 kernel environment and achieves deep observability through the collaborative interaction between kernel mode and user mode.

[0106] An electricity consumption information collection terminal monitoring system, comprising: The transaction semantics module is used to obtain the application protocol data unit of the target process using the extended Berkeley packet filter eBPF, generate transaction fingerprints, and obtain transaction event records based on the transaction fingerprints. The causal delimitation module is used to construct a transaction observation window based on the observation timestamps in the transaction event record, and to filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain a transaction evidence set. The causal delimitation module is also used to construct a directed evidence graph based on the transaction evidence set, calculate the confidence level of each root cause category, and obtain the root cause delimitation conclusion.

[0107] Specifically, the transaction semantics module is deployed at the kernel boundary of the terminal system. It utilizes the extended Berkeley Packet Filter (eBPF) to attach multi-dimensional probes at the system call layer or protocol library function layer. After obtaining the application protocol data unit of the target process, this module extracts key fields such as connection identifier, table address, and service sequence number. To adapt to complex application scenarios in the concentrator, the system also introduces the control group identifier (CgroupId) as a process differentiation dimension during the extraction process, enabling accurate business location in a multi-instance runtime environment. The transaction semantics module generates transaction fingerprints using a 64-bit cyclic redundancy check algorithm and maintains a paired state machine in the kernel Map accordingly, outputting information including the transaction primary key, retry count, and transaction latency L. _tx Transaction event records.

[0108] Furthermore, the causal delimitation module operates in user space, asynchronously receiving transaction event records and kernel observation events from kernel space via the performance event interface Perf event. This module constructs a transaction observation window using a high-precision monotonic clock. Specifically, by shifting the start and end times of a transaction forward and backward by a preset extension amount, it accurately extracts kernel indicator evidence belonging to that transaction from the continuous data stream. Based on this, the causal delimitation module constructs a directed evidence graph using a preset causal rule base. For example, if a surge in the number of tcp_retransmit_skb function triggers is detected, along with an increase in the latency of the corresponding business packets, a corresponding causal edge is established in the graph. This module calculates the confidence level P(c) of each root cause category using a weighted scoring and exponential normalization algorithm, and generates a delimitation conclusion containing the Top 1 root cause and the evidence path.

[0109] Optionally, as an improvement to the above system solution, the system also includes a visualization and alarm subsystem. This subsystem receives the results output by the causal delimitation module and provides tiered alerts based on preset alarm rules. For example, when the success rate (SR) is below 90% for five consecutive seconds and the confidence level of the delimitation conclusion exceeds 0.8, the subsystem automatically sends a fault delimitation report to the remote master station via the northbound interface. This report includes the distribution of the key latency indicator P95, providing power grid maintenance personnel with intuitive and reliable fault handling suggestions.

[0110] Through the organic cooperation of the above modules, this system realizes integrated operation and maintenance capabilities from semantic extraction of power message to automatic kernel root cause diagnosis, thereby improving the operational stability of smart grid terminals.

[0111] Example 10 details the specific diagnostic path of this monitoring system when facing complex power Internet of Things (IoT) faults (such as periodic data interruptions). By simulating real-world operation and maintenance scenarios, the significant advancements of transaction fingerprinting and causal evidence graphs in quickly identifying the root cause of faults are verified.

[0112] In this embodiment, the fault manifests as a data stream interruption lasting approximately 120 seconds occurring approximately every 300 seconds when a concentrator running the Linux 4.19.232 kernel interacts with the master station.

[0113] Step 1001: Use the Extended Berkeley Packet Filter (eBPF) to obtain the application protocol data unit of the target process.

[0114] During the fault, the transaction semantics module detected the target communication process comm. _agent The frequency of application layer packet extraction has decreased significantly. Based on preset configurations, the system synchronously activates network quality monitoring probes in kernel mode.

[0115] Step 1002: Extract the session identifier, object identifier, business identifier, and call identifier from the application protocol data unit, and generate a transaction fingerprint based on the session identifier, object identifier, business identifier, and call identifier.

[0116] Specifically, the system extracts the session identifier ConnId, the object identifier MeterId corresponding to the table address, and the call identifier InvokeId for the affected service. In this embodiment, the generated transaction fingerprint TxFp can reliably lock the comm... _agent The ongoing transcription task ensures the uniqueness of subsequent evidence collection.

[0117] Step 1003: Based on transaction fingerprints, use the request and response pairing state machine to pair business requests and business responses to obtain transaction event records.

[0118] In this embodiment, the pairing state machine shows that the transaction fingerprint remains in the request monitoring state (REQ_SEEN) for an extended period. Since no response is received within the preset pairing window W of 2000 milliseconds, the system outputs a timeout result (TIMEOUT) and generates an abnormal transaction event record.

[0119] Step 1004: Construct a transaction observation window based on the observation timestamp in the transaction event record, and filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain the transaction evidence set.

[0120] Specifically, the causal bounding module constructs a transaction observation window centered on the timestamp of the timeout transaction, including both preceding and following expansions. Within this window, the system filters out multiple key kernel pieces of evidence: The first piece of evidence is of type NET_RETRANS, which is a network retransmission event, indicating that high-frequency retransmissions occurred during message transmission. The second piece of evidence is of type SYSCALL_BLOCK, i.e., a system call blocking event, indicating the target communication process comm._agent An unexpected blockage of more than 1000 milliseconds occurred while executing the recvfrom system call; The third piece of evidence is of the PROC_EXIT type, which is a process exit event, indicating that the process exited abnormally due to receiving a segmentation fault signal, i.e., signal code 139.

[0121] Step 1005: Construct a directed evidence graph based on the transaction evidence set, and calculate the confidence level of each root cause category according to preset rules to obtain the root cause delineation conclusion.

[0122] In this embodiment, the directed evidence graph constructed by the system clearly shows the evidence chain: the NET_RETRANS node points to the SYSCALL_BLOCK (system call blocking event) node. Due to network quality degradation, the kernel read buffer cannot be filled for a long time, triggering a long-term blocking of the upper-layer application process on the system call; this blocking behavior triggers illegal memory access logic within the business library, resulting in PROC_EXIT. After confidence calculation, the system outputs a confidence score P(NET) of 0.92.

[0123] The root cause analysis revealed that the top root cause was a network link failure, and provided a complete path of evidence. Based on this conclusion, maintenance personnel could resolve the periodic outage issue directly by optimizing the concentrator's 4G signal enhancement measures, without needing to log into the device for blind troubleshooting.

[0124] Furthermore, during the aforementioned diagnostic process, the system monitors the success rate indicator in real time. The formula SR = (∑(Success)) is used. _i The success rate within the current statistical window is calculated as 5%, which is far below the preset alarm threshold. Accordingly, the system utilizes uncertainty-driven orchestration logic to automatically unload auxiliary probes unrelated to CPU scheduling after detecting a high confidence level of P(NET), thereby stabilizing CPU usage below 1%, achieving a harmonious balance between high-precision diagnosis and low resource consumption.

[0125] In some optional implementations, the method of the present invention can be extended to other power communication protocols or industrial IoT scenarios. For example, for substation automation scenarios using the IEC 61850 protocol, the system can adapt to the MMS protocol by replacing the APDU parsing module; for industrial control scenarios using the Modbus RTU / TCP protocol, the system can achieve protocol adaptation by configuring the frame structure feature table. The transaction fingerprint generation algorithm, the directed evidence graph construction logic, and the confidence calculation method can all be reused; only the field extraction rules related to the specific protocol need to be adjusted.

[0126] According to one aspect of this application, in the transaction semantic protocol monitoring method, the determination of the transaction extraction mode and the selection of the mount point are specifically as follows: First, determine the target business process set, ProcessSet, to be monitored. ProcessSet is a collection or list of strings, where each element is a matching rule for a process name or executable file path. ProcessSet must contain at least one process rule, preferably 1 to 32 rules. Matching rules can be exact matches, prefix matches, or regular expression matches. ProcessSet has no physical unit. Optionally, ProcessSet may also include the process's control group identifier, CgroupId, for differentiation in container or multi-instance scenarios. CgroupId is a non-negative integer and has no unit.

[0127] Determine the communication channel type, ChannelType. ChannelType is an enumerated variable, and its value range includes TCP, UDP, serial port, or others; in this embodiment, TCP is preferred; ChannelType has no unit.

[0128] Determine the protocol type (ProtoType). ProtoType is an enumerated variable, with values ​​including DLT645, DLT69845, or other power acquisition protocols; ProtoType has no unit. This embodiment uses DLT645 and DLT69845 as examples; other protocols can be extended using the same data interface and transactional methods.

[0129] Determine the transaction extraction source mode, SourceMode. SourceMode is an enumerated variable, with values ​​including LIB_HOOK and SYSCALL_HOOK; SourceMode has no unit. LIB_HOOK indicates that application layer data is extracted first from the framed or decoded function locations in the user-space protocol library; SYSCALL_HOOK indicates that fragments are extracted from the system call read / write buffer locations and reassembled subsequently.

[0130] Preferably, when the target terminal software has a stable protocol decoding function entry point (e.g., the APDU decoding entry point function or equivalent function in the protocol library), the user-mode function probe is mounted on this decoding entry point function, SourceMode=LIB_HOOK is selected, and the application layer buffer pointer BufPtr and length BufLen in the function's input parameters are directly read. BufPtr is a memory address pointer with no unit; BufLen is the byte length, ranging from 1 to MaxFrameLen, in bytes; MaxFrameLen is the maximum frame length parameter, with a default value of 8192 bytes and an selectable range of 512 bytes to 65535 bytes.

[0131] Optionally, when the entry point of the protocol library function cannot be reliably located, or when the protocol library is statically linked and symbols are unavailable, SourceMode=SYSCALL_HOOK is selected, and tracepoints are set at the system call layer for send, sendto, recv, recvfrom, read, write, or their equivalent entry points to read user-mode buffer fragments. To avoid limiting the implementation to a specific kernel version function name, this embodiment only provides example mount points: they can be mounted at the kernel implementation function __sys_recvfrom or an equivalent architectural entry point (e.g., __x64_sys_recvfrom under the x86-64 architecture), or at __sys_sendto or an equivalent entry point; these function names are only examples, and the actual implementation can select an equivalent entry point based on the kernel symbol table or use tracepoint system call events. The time consumption and blocking information of system call events can be used as subsequent evidence input.

[0132] When SourceMode=SYSCALL_HOOK, the output is a FragmentStream. FragmentStream is a sequence of fragments arranged in arrival order. Each fragment contains fragment data (FragmentData), fragment length (FragmentLen), and fragment observation timestamp (t). _frag FragmentLen is in bytes, and its value ranges from 1 to MaxFragLen; the default value of MaxFragLen is 4096 bytes, and the selectable range is 256 bytes to 65535 bytes; t _frag The unit is microseconds (µs), the value range is non-negative integers, and the time base is a monotonic clock.

[0133] According to one aspect of this application, in the transaction semantics protocol monitoring method, the generation of the transaction primary key TxKey and the transaction fingerprint TxFp is specifically as follows: Define a connection stability identifier, ConnId. ConnId is a connection-level stability identifier used to identify the same connection or session context; ConnId is a 64-bit unsigned integer with no unit. Preferably, ConnId can be generated on the kernel side via socket cookies or an equivalent mechanism; alternatively, in user-space library mount mode, ConnId can be obtained by combining and hashing (Pid, Fd), where Pid is the process identifier and Fd is the file descriptor, both being non-negative integers with no unit.

[0134] Define the data acquisition object identifier, MeterId. MeterId is used to identify the energy meter or data acquisition object; MeterId can be a fixed-length byte string or a string, without units. The value range depends on the protocol: for DLT645, MeterId is preferably taken from the address field (usually a 6-byte address, often represented in BCD encoding); for DLT69845, MeterId can preferably be taken from the application layer address information field or obtained from the device file mapping table. If MeterId cannot be directly parsed, it can optionally be set to the terminal logical address or the concentrator's own identifier to maintain data interface consistency.

[0135] Define a service identifier (ServiceId). ServiceId identifies the type of business transaction; it is an enumeration or integer encoding with no unit. Values ​​range from reading, fee control, parameter setting, event reporting, etc. For DLT645, it can be obtained by mapping the control code C to the data identifier DI; for DLT69845, it can be obtained by mapping the service type (e.g., read, set, execute) to the object attribute descriptor (OAD).

[0136] Define the InvokeId identifier. InvokeId is used to distinguish concurrent or consecutive transactions on the same connection; InvokeId is a non-negative integer with no unit. For DLT69845, InvokeId is preferably taken from the invoice sequence number field in PIID-ACD (Protocol Instance Identifier-Application Control Data); for DLT645, if the protocol or implementation does not provide an explicit invoice sequence number, it can optionally be composed of (time slice number, request sequence counter, DI) and mapped to an integer to ensure distinguishability within window W.

[0137] Define the direction identifier Dir. Dir is an enumerated variable, and its value range includes REQ and RESP; REQ represents the request direction, and RESP represents the response direction; Dir has no unit.

[0138] Construct the transaction primary key TxKey. TxKey is a field tuple defined as: TxKey=(ConnId,MeterId,ServiceId,InvokeId,Dir); TxKey has no unit.

[0139] Construct a transaction fingerprint TxFp. TxFp is a 64-bit unsigned integer with no unit, used to reduce storage overhead and for cross-layer association. The formula for calculating TxFp is: TxFp = CRC64(ConnId||MeterId||ServiceId||InvokeId). Here, CRC64 represents a 64-bit cyclic redundancy check or an equivalent 64-bit hash function; || represents byte concatenation; if MeterId is a string, it is first converted to a byte string according to a predetermined encoding; ConnId, ServiceId, and InvokeId are all encoded into byte strings according to a fixed byte order. The specific polynomial implementation of CRC64 is not restricted; any equivalent 64-bit hash function can be used, as long as the collision probability meets the engineering requirements.

[0140] According to one aspect of this application, in the transaction semantics protocol monitoring method, the minimum field extraction of APDU and the request / response pairing state machine are specifically as follows: Define the Application Layer Data Unit (APDU). An APDU is a sequence of bytes, with a length of APDULen, which is also in bytes and ranges from 1 to MaxFrameLen.

[0141] Define the metadata Meta. Meta is a structure or a collection of key-value pairs, without units; Meta must contain at least the protocol type ProtoType, the result code ResultCode, and the key fields used to generate ServiceId and InvokeId.

[0142] For the minimum field extraction of DLT645, the following exemplary frame structure and checksum are disclosed: The frame may contain an optional preamble FEH of several bytes; the frame start symbol is 68H; the address field is 6 bytes; 68H appears again thereafter; the control code field is denoted as C, and is 1 byte; the length field is denoted as L, and is 1 byte, representing the length of the data field; the data field is denoted as DATA, and is L bytes long; the checksum field is denoted as CS, and is 1 byte; the end symbol is 16H. During parsing on the receiving side, 68H and 16H are first located to determine the frame boundary, then the address field, control code C, and length L are read, and DATA and CS are extracted. The checksum CS can be calculated by byte accumulation and taking the lower 8 bits: CS _calc This is the result of summing all bytes from the first 68H to CS using unsigned byte increments and then taking the modulo 256; if CS _calc If the frame does not match the CS message, it is discarded and a check failure event is output. This check method is disclosed as an example and is not limited to being the only implementation. Optionally, a byte offset inverse transformation can be performed on DATA, such as a byte-level inverse transformation (decoding / restoration) operation on each data byte: DATA _raw =DATA _byte-0x33 to restore the original value, where DATA _raw The restored original byte value, DATA _byte This represents the currently processed encoded (or obfuscated) data bytes; whether it is enabled and the offset value are determined by the protocol version and the field implementation. This embodiment provides this rule as an example of what can be implemented.

[0143] For minimum field extraction of DLT69845, at least the key fields such as PIID-ACD, OAD, and DAR should be extracted. PIID-ACD is a 1-byte field used to carry information such as service priority and call sequence number; OAD is the object attribute descriptor used to locate object attributes; DAR is the data access result code used to indicate the reason for success or failure. ResultCode can preferably be DAR; when DAR is a success code, it is used for success determination. The above field lengths and semantics are disclosed as examples; in actual implementations, equivalent fields can be extracted according to the protocol version.

[0144] Define the request observation timestamp t _req With response observation timestamp t _resp . t _req With t _resp All values ​​are non-negative integers, measured in microseconds (µs), with a time base of a monotonic clock; t _req To observe the timestamp of the request direction REQ, t _resp The timestamp for observing the response direction RESP.

[0145] Define the pairing window W. W is a positive real number or a positive integer, in milliseconds (ms); the default value of W is 2000ms; the optional range of W is 200ms to 20000ms; W is used to perform request / response pairing under the same transaction fingerprint TxFp and to handle retries, out-of-order orders, and timeouts.

[0146] Maintain a state variable `State` for each transaction fingerprint `TxFp`. `State` is an enumerated variable with no unit; the value range of `State` includes at least `INIT`, `REQ_SEEN`, and `DONE`. `INIT` indicates that the request has not yet been observed; `REQ_SEEN` indicates that the request has been observed but the response has not been observed; `DONE` indicates that the transaction has completed pairing and output the result.

[0147] When a transaction event with Dir=REQ is observed, if State=INIT, then record t. _req Set State to REQ_SEEN and set the number of retries, RetryCnt, to 0. RetryCnt is a non-negative integer with no unit, ranging from 0 to RetryMax (maximum number of retries); RetryMax defaults to 3 and can be selected from 0 to 10.

[0148] When the same transaction event TxFp with Dir=REQ is observed again within window W, a retry is considered to have occurred. The retry count RetryCnt is incremented by 1, and t is updated according to the preset criteria. _req The update caliber can be selected from two options: one is to take the last request as the valid request, i.e., t _req The first approach is to use the latest request timestamp; the second approach is to consider the first request as the valid request, i.e., t... _req The two methods remain unchanged; they can be disclosed side-by-side in different embodiments. This embodiment preferably uses the method where the last request was valid, so as to more closely reflect the actual business completion time after a field retry.

[0149] When a transaction event with Dir=RESP is observed, if State=REQ_SEEN and is within W, then record t. _resp Set State=DONE and output the result of successful pairing. If RESP is observed before REQ, then temporarily store RESP in the pending list PendingResp and wait for W; if REQ is not found in W, output the result of out-of-order unpaired pairing.

[0150] Define the pairing result PairResult. PairResult is an enumerated variable with no unit; its value range includes at least MATCH, TIMEOUT, OUT_OF_ORDER, and RETRY. MATCH indicates that the request and response were successfully paired; TIMEOUT indicates that no response was received within window W; OUT_OF_ORDER indicates that out-of-order matching resulted in an incomplete valid pairing; RETRY indicates that a retry occurred and the pairing was eventually completed.

[0151] When State=REQ_SEEN and from t _req If RESP is not observed after passing W, output PairResult=TIMEOUT and set State to DONE or reclaim the state entry to avoid Map bloat.

[0152] Define transaction delay L _tx L _tx is a non-negative real number or a non-negative integer, and the unit is microseconds (µs). L _tx The calculation formula is: L _tx =t _resp -t _req If PairResult is not MATCH, then L _tx It can be set to null or 0, and can be distinguished by PairResult.

[0153] According to one aspect of this application, in the transaction semantics protocol monitoring method, the session-level reorganization cache (enabled only when SourceMode=SYSCALL_HOOK) is specifically as follows: When SourceMode=SYSCALL_HOOK, fragment reassembly is performed to restore the complete APDU from the FragmentStream. A reassembly buffer, ReasmBuf, is maintained for each ConnId. ReasmBuf is a circular buffer or byte queue, with the capacity parameter ReasmCap in bytes; the default value of ReasmCap is 16384 bytes, and the optional range is 2048 bytes to 262144 bytes. ReasmBuf is used to accumulate system call layer read and write fragments to handle TCP segmentation and packet reassembly.

[0154] Define the reassembly timeout parameter ReasmTimeout. ReasmTimeout is a positive real number in milliseconds (ms); the default value is 500ms, and the selectable range is 50ms to 5000ms. If a ConnId does not form a complete frame within ReasmTimeout, the old fragment is discarded and a reassembly timeout event is output.

[0155] The reassembly rules are as follows: Fragments are written to ReasmBuf in arrival order; the protocol frame start feature is searched in the buffer, and the length field is read to determine the complete frame boundary; when a complete frame can be constructed in the buffer, APDU_full (the fully reassembled APDU) is output, and consumed bytes are removed from the buffer. For DLT645, the boundary can be located using the start symbol 68H and the end symbol 16H combined with the length field L; for DLT69845, the boundary can be located according to its application layer header and length field or equivalent boundary rules. If the frame length exceeds MaxFrameLen or the number of check failures exceeds FailMax (the maximum allowed number of failures), the frame is discarded and an exception is recorded; FailMax is a positive integer with a default value of 5, and an optional range of 1 to 50.

[0156] Output the complete APDU_full and proceed to the field extraction and pairing state machine processing.

[0157] According to one aspect of this application, the transaction semantic protocol monitoring method includes the following specific aspects: indicator definition, success determination, and window statistical output: Define the ResultCode. ResultCode can be an integer or an enumeration, with no unit. For DLT645, ResultCode can be obtained by combining the response flag, exception code field, or equivalent field of control code C. For DLT69845, ResultCode is preferably DAR or an equivalent result code. The range of values ​​for ResultCode depends on the protocol, but it must be comparable and able to determine success or failure.

[0158] Define a success code set, OK_SET. OK_SET is a unitless set; its elements are the values ​​of ResultCode; OK_SET contains all result codes indicating successful service operation. For DLT69845, DAR success codes are preferred; for DLT645, combinations of code values ​​for normal responses without exception flags are acceptable. OK_SET can be configured and distributed or embedded in the protocol adapter.

[0159] Define the single transaction success flag. _i Success _i `i` is a binary variable with no unit; its value range is 0 or 1; `i` is a transaction sequence number index variable, a positive integer with no unit. (Success) _i The determination rule is: Success occurs if and only if PairResult = MATCH (request and response are successfully paired) and ResultCode ∈ OK_SET. _i =1; otherwise Success _i =0.

[0160] Define the statistical window length T. T is a positive real number in seconds (s); the default value of T is 60s; the selectable range of T is 1s to 3600s. T is used for windowed aggregation statistics of transaction events.

[0161] Define the total number of transactions N within the statistics window. N is a positive integer with no unit; N represents the number of transactions participating in the statistics within window T; the value of N ranges from 1 to positive infinity, but is actually limited by the workload.

[0162] Define the success rate SR. SR is a real number, dimensionless, and ranges from 0 to 1. The formula for calculating SR is: SR = (∑(Success) / SR) _i ,i=1..N)) / N. Where ∑ represents the summation function, and i=1..N represents the index from 1 to N.

[0163] Optionally, output the timeout rate (TimeoutRate) and retry rate (RetryRate). TimeoutRate is the number of TIMEOUT transactions divided by N; RetryRate is the number of retries (RetryCnt greater than 0) divided by N; both are real numbers between 0 and 1, without units. Optionally, output the transaction latency quantile (P95), where P95 is in microseconds (µs), representing L. _tx The 95th percentile.

[0164] Outputs the transaction event `TransactionEvent` and window metrics `WindowMetrics`. `TransactionEvent` is a structure with no unit, containing at least the key fields (or summaries) of `TxFp` and `TxKey`, `PairResult`, `RetryCnt`, and `t`. _req t _resp L _tx ResultCode, ProtoType, ServiceId. WindowMetrics is a structure with no units, containing at least SR, N, and T, and optional TimeoutRate, RetryRate, and P95.

[0165] To ensure practicality and without limiting the specific Map type, this embodiment provides a preferred method for data structure storage: Preferably, TxFp is mapped to the state variables State and t. _req The mappings of RetryCnt, etc., are stored in the hash class eBPF Map; TransactionEvent and EvidenceItem are preferably output to the user-space aggregation module through a ring buffer or an equivalent event channel; the Map type can be any equivalent implementation such as Hash (hash table), Per-CPU Hash (per CPU hash table), Array (array Map), Ringbuf (ring buffer Map), etc. The specific type is not a restriction, as long as the Key / Value interface is consistent.

[0166] According to one aspect of this application, in the transaction window causal delimitation method, the definition of indicator criteria, success determination, and window statistical output are specifically as follows: In this embodiment, TransactionEvent from the transaction layer and KernelEvent from the kernel observation are uniformly formatted as EvidenceItem.

[0167] Define an Evidence item. EvidenceItem is a structure or tuple with no unit, defined as EvidenceItem=(EventType,ObjId,t... _start ,t _end Value, Tags).

[0168] Define the event type EventType. EventType is an enumerated variable with no unit; its value range includes at least NET_RETRANS (network retransmission event), NET_RTT (network round-trip time delay event), SYSCALL_BLOCK (system call blocking event), SCHED_LAT (CPU scheduling wait delay event), PROC_EXIT (process exit event), MEM_OOM (out-of-memory event), TX_RESULT (transaction result event), etc.

[0169] Define the object identifier ObjId. ObjId is a 64-bit unsigned integer or a composite key digest, without units; TxFp is preferred as ObjId to achieve transaction-centric evidence aggregation; when a certain type of kernel event cannot be directly bound to TxFp, ConnId (session identifier) ​​or Pid (process identifier) ​​can be used as ObjId, and further associated with TxFp in user space through a mapping table.

[0170] Define the event start time t _start With the event end time t _end . t _start With t _end All are non-negative integers, and the unit is microseconds (µs); t _end It should satisfy t _end ≥t _start For instantaneous events, let t _end =t _start .

[0171] Define the event value, Value. Value can be a real number or an integer; its unit is determined by EventType. For example, the value of NET_RTT is in microseconds (µs), the value of the network retransmission event NET_RETRANS is a count with no unit, the value of the system call blocking event SYSCALL_BLOCK is in microseconds (µs), and the value of the CPU scheduling wait delay event SCHED_LAT is in microseconds (µs).

[0172] Define a tag collection called Tags. Tags is a collection of key-value pairs with no unit; it can contain contextual information such as the process name string ProcName, protocol type ProtoType, service type ServiceId, host station HostRole, or terminal role tag.

[0173] Kernel observation events (KernelEvent) can be generated by the following exemplary mount points: NET_RETRANS network retransmission events can be obtained by counting tcp_retransmit_skb-related tracepoints or equivalent function probes; NET_RTT can be estimated by TCP connection information fields or equivalent mechanisms; SYSCALL_BLOCK system call blocking events can be obtained by the time difference between system call entry and exit; SCHED_LAT CPU scheduling wait delay events can be obtained by scheduling queue wait delay observation tools or equivalent probes; PROC_EXIT process exit events can be obtained by process exit tracepoints. The above mount points are merely examples and do not limit the implementation.

[0174] All EvidenceItems are output in chronological order to form an EvidenceStream. An EvidenceStream is a sequence of evidence items and has no unit.

[0175] According to one aspect of this application, in the transaction window causality delimitation method, the evidence graph construction specifically involves: Define an evidence graph G(TxFp). G(TxFp) is a directed graph with no unit, defined as G(TxFp) = (V, EdgeSet). V is a set of nodes with no unit; EdgeSet is a set of directed edges with no unit. A node v ∈ V corresponds to an EvidenceItem or its aggregate node; an edge e ∈ EdgeSet represents a causal or temporal dependency between two nodes.

[0176] Define edge weight w _e w _e w is a non-negative real number with no unit. _e This represents the confidence strength or weight of an edge, with a value ranging from 0 to positive infinity; the default weight value can be between 0 and 10; the specific value is determined by the rule set.

[0177] Define a rule set (RuleSet). A RuleSet is a collection of rules with no unit; each rule includes a trigger condition, edge direction, and edge weight calculation method. The trigger condition must at least include temporal order and object consistency. For example, if the same ConnId experiences a NET_RETRANS event in Win(TxFp) and subsequently a SYSCALL_BLOCK event, an edge can be established from the NET_RETRANS node to the SYSCALL_BLOCK node, indicating that retransmission may cause receive blocking; if a SCHED_LAT event occurs in Win(TxFp) and covers t... _reqNearby, edges can be established from SCHED_LAT to TX_RESULT or user-space processing-related nodes, indicating that scheduling delays may increase transaction latency. This rule is only an example; actual rules are scalable but must maintain consistency between input and output interfaces.

[0178] According to one aspect of this application, in the transaction window causality delimitation method, the root cause scoring, confidence calculation, and conflict resolution output are specifically as follows: Define a root cause category set C. C is a set with no unit; the elements of the set are an enumeration of root cause categories. The value range of root cause categories includes at least NET, REMOTE_HOST, PROTOCOL_LOGIC, PROCESS_CRASH, CPU_SCHED, MEM_OOM, and IO_BLOCK. NET represents a network link root cause; REMOTE_HOST indicates that the master station or peer is unreachable or the service is abnormal; PROTOCOL_LOGIC indicates that the failure is caused by the protocol or business logic; PROCESS_CRASH indicates that the process has crashed; CPU_SCHED indicates that CPU scheduling causes latency; MEM_OOM indicates insufficient memory or OOM; and IO_BLOCK indicates I / O blocking.

[0179] Define category ratings _c . s _c Let be a real number, without unit; 'c' represents a root cause category. Define the number of key evidence items K, where K is a positive integer, without unit; define the key evidence indicator I. _k I _k A binary variable, either 0 or 1, without units, representing whether the k-th key piece of evidence appears in G(TxFp) or whether there exists an evidence path that satisfies the conditions; the key evidence weight w is defined. _k w _k is a non-negative real number with no unit, representing the contribution strength of the k-th key piece of evidence to a certain category.

[0180] The formula for calculating category scores is: s _c =∑(w _k I _k (k=1..K). Where k=1..K represents the index range.

[0181] Define the number of categories M. M is a positive integer with no unit; M equals the number of elements in each category in C.

[0182] Define the confidence level P(c). P(c) is a real number, dimensionless; its value ranges from 0 to 1; the sum of P(c) for all categories is 1. The confidence level calculation formula is: P(c) = exp(s _c ) / ∑(exp(s _j),j=1..M). Where exp represents the exponential function; j is the categorical index variable.

[0183] Define the root cause output as RootCauseResult. RootCauseResult is a structure with no unit, containing at least Top1Cause, Confidence, EvidencePath, and SecondaryCauses. Top1Cause is a category enumeration with no unit, representing the root cause category with the highest score; Confidence is a real number with no unit, defined as: Confidence = P(Top1Cause); EvidencePath is a list of evidence paths, without units, representing the high-weighted or explanatory paths supporting Top1Cause in G(TxFp); SecondaryCauses is a set of alternative root causes, without units, containing several alternative categories and their confidence levels in descending order of score.

[0184] The conflict resolution rule is as follows: when multiple category scores are close and Confidence is lower than the threshold (minimum confidence) ConfMin, output Top1Cause and SecondaryCauses at the same time for manual or automatic strategies to continue observation; ConfMin is a real number with no unit; the default value of ConfMin is 0.6, and the selectable range is 0.3 to 0.9.

[0185] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A method for semantic monitoring and causal delimitation of transactions in an electricity information collection terminal, characterized in that, include: Use the Extended Berkeley Packet Filter (eBPF) to obtain the application protocol data unit of the target process; Extract the session identifier, object identifier, business identifier, and call identifier from the application protocol data unit, and generate a transaction fingerprint based on them; Based on transaction fingerprinting, a request and response pairing state machine is used to pair business requests and business responses to obtain transaction event records. A transaction observation window is constructed based on the observation timestamps in the transaction event record, and kernel events that are associated with the transaction fingerprint and fall into the transaction observation window are filtered to obtain the transaction evidence set. A directed evidence graph is constructed based on the transaction evidence set, and the confidence level of each root cause category is calculated according to preset rules to obtain the root cause delineation conclusion.

2. The method according to claim 1, characterized in that, The extended Berkeley packet filter (eBPF) is used to obtain the application protocol data units of the target process, including: Based on the target process's configuration information or runtime attributes, determine the target process's communication channel type and protocol type; If the target process has a preset application layer protocol decoding function, the eBPF probe is attached to the entry point of the application layer protocol decoding function and the memory buffer is read directly to obtain the application protocol data unit. If no application layer protocol decoding function exists, the eBPF probe is attached to the read / write entry point of the system call function to extract the fragment stream, and session reassembly is performed on the fragment stream to obtain the application protocol data unit.

3. The method according to claim 2, characterized in that, Perform session reassembly on the fragmented stream to obtain application protocol data units, including: Maintain a reassembly buffer for the connection corresponding to the session identifier; Write the data fragments in the fragment stream into the connection maintenance reassembly buffer in the order of arrival; The connection maintenance and reassembly buffer is searched based on the preset frame structure features to determine the frame boundary, and the application protocol data unit is obtained after extracting the complete frame data.

4. The method according to claim 1, characterized in that, Extract the session identifier, object identifier, business identifier, and call identifier from the application protocol data unit, and generate a transaction fingerprint based on this, including: Encapsulate the session identifier, object identifier, business identifier, and call identifier into a transaction primary key; The target sequence is obtained by concatenating the byte strings of each field in the primary key of the transaction in a preset order. Perform cyclic redundancy check calculation on the target sequence to obtain the transaction fingerprint.

5. The method according to claim 1, characterized in that, The request-response pairing state machine is used to pair service requests and service responses, including: Maintain state variables for transaction fingerprints. The values ​​of the state variables must include at least the initial state, the request monitoring state, and the completion state. The direction identifier is determined based on the control code or service type field in the application protocol data unit; If a transaction event with the direction identifier of a request is observed and the state variable is in the initial state, then the request observation timestamp is recorded and the state variable is moved to the request monitoring state; If a transaction event with a direction identifier of "response" is observed within the preset pairing window and the status variable is in the "request monitoring" state, then the response observation timestamp is recorded, the status variable is moved to the "completed" state, and the pairing is determined to be successful.

6. The method according to claim 5, characterized in that, Pairing business requests with business responses also includes: If the same transaction fingerprint corresponding to the request direction transaction event is observed multiple times within the pairing window, the number of retries is incremented, and the request observation timestamp is updated according to the observation timestamp of the last request. If a response-oriented transaction event is observed first but no matching request monitoring state is found, the response-oriented transaction event will be temporarily stored as a pending response. If a corresponding request-direction transaction event is detected within the pairing window, the pairing is completed using the pending response and the process is transitioned to the completed state.

7. The method according to claim 1, characterized in that, Obtain transaction event records, including: Using the formula L _tx = t _resp - t _req to calculate transaction latency, where t _resp is the reply observation timestamp, and t _req is the request observation timestamp; When it is determined that the pairing is successful and the result code in the application protocol data unit belongs to the pre-configured success code set, the single transaction success flag is set to 1; otherwise, it is set to 0. Using the formula SR=(∑(Success _i The success rate is calculated as ,i=1..N)) / N, where SR is the success rate, and Success _i This is the single-transaction success flag for the i-th transaction, and N is the total number of transactions within the statistics window; Transaction latency and success rate are written to the transaction event log for subsequent root cause analysis.

8. The method according to claim 7, characterized in that, Construct a transaction observation window and filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain a set of transaction evidence, including: Get the pre-configured window front expansion Δpre and window back expansion Δpost; The transaction observation window is obtained by subtracting the window pre-expansion from the request observation timestamp and using the window post-expansion to determine the window start time, and by adding the window post-expansion to the response observation timestamp. The transaction observation window is represented as [t]. _req -Δpre,t _resp +Δpost]; The generated sequence of evidence entries is selected from those whose time intervals intersect with the transaction observation window and whose object identifiers match the transaction fingerprints, and these are then aggregated into a transaction evidence set.

9. The method according to claim 1, characterized in that, The confidence level of each root cause category is calculated according to preset rules to obtain root cause delimitation conclusions, including: The key evidence items corresponding to each root cause category are determined based on the pre-configured root cause feature mapping table; Determine the key evidence indicator quantity based on whether there is a path that satisfies the conditions in the directed evidence graph for the key evidence item; Using formula s _c =∑(w _k ·I _k Calculate the score for root cause category c (k=1..K), where w _k Let I be the weight of the k-th key piece of evidence. _k Let K be the indicator of the kth key evidence, where K is the number of key evidence items; Using the formula P(c)=exp(s) _c ) / ∑(exp(s _j ), j=1..M) calculate the confidence level P(c), where M is the number of root cause categories, s _j The score for the j-th root cause category; The root cause category with the highest confidence level is output as the root cause delimitation conclusion.

10. A power consumption information collection terminal monitoring system, characterized in that, include: The transaction semantics module is used to obtain the application protocol data unit of the target process using the extended Berkeley packet filter eBPF, generate transaction fingerprints, and obtain transaction event records based on the transaction fingerprints. The causal delimitation module is used to construct a transaction observation window based on the observation timestamps in the transaction event record, and to filter kernel events that are associated with the transaction fingerprint and fall into the transaction observation window to obtain a transaction evidence set. The causal delimitation module is also used to construct a directed evidence graph based on the transaction evidence set, calculate the confidence level of each root cause category, and obtain the root cause delimitation conclusion.

Images