Distributed data whole-process tracking method and system for energy storage collaborative response

Abstract

The present application relates to the technical field of distributed data tracking, and particularly relates to a distributed data whole-process tracking method and system for energy storage collaborative response. The present application performs real-time value evaluation by acquiring business attribute data and running state data when a current node processes a request, aggregates the cumulative value points passed by the previous node, updates the cumulative value points, and realizes dynamic accumulation of the call chain value. Further, the present application calculates a sampling probability based on the updated cumulative value points, records the tracking data of the current node according to the sampling probability and the sampling state, and passes the updated cumulative value points and the sampling state to the next node. Through the real-time value evaluation and cumulative value aggregation mechanism, the present application realizes adaptive sampling, ensures complete tracking of high-value call chains, solves the problem of data loss caused by fixed sampling strategies, and improves the completeness and accuracy of whole-process data tracking.

Description

Technical Field

[0001] This invention relates to the field of distributed system data tracking technology, specifically to a distributed data end-to-end tracking method and system for energy storage collaborative response. Background Technology

[0002] In distributed collaboration scenarios, a single business request needs to flow and collaborate across multiple nodes to complete, forming a complete call chain. For example, in the scheduling process of a virtual power plant, the grid response command needs to pass through multiple nodes, including the resource aggregation layer, business logic layer, and equipment control layer. Each node is responsible for executing specific business logic (such as command parsing, equipment status query, and control command issuance). To monitor the system's operational status, locate performance bottlenecks, analyze business processes, and troubleshoot faults, it is necessary to track and record the entire process data of the request throughout the call chain, including key information such as the business parameters processed by each node, runtime status, and response time.

[0003] Existing distributed tracing technologies typically employ fixed sampling strategies to control the amount of tracing data. They determine whether to trace the entire call chain at the entry node based on a fixed sampling ratio, or decide whether to retain tracing data after the request is completed based on preset rules (such as error rate or response time thresholds). However, because the sampling rate is statically configured and cannot be dynamically adjusted according to business value and runtime state, high-value call chains (such as those involving core business processes, those experiencing anomalies, or those with excessively long response times) may be lost due to low sampling rates at the entry nodes, resulting in missing critical data. Furthermore, existing sampling decisions are independent and stateless, failing to guarantee that once a high-value node is sampled, the data from subsequent nodes is fully recorded, leading to incomplete tracing data. This makes it impossible to reconstruct the full picture of the call chain, hindering the support for fault location, performance optimization, and business analysis. Summary of the Invention

[0004] To address the technical problem of significant data loss in high-value and abnormal links under fixed sampling strategies caused by traditional end-to-end data tracing methods that fail to consider the inherent value differences and dynamic changes in runtime states of different business links, this invention provides a distributed end-to-end data tracing method for energy storage collaborative response. The method includes: Obtain business attribute data and operation status data when the current node processes a request, evaluate the value of the business attribute data and the operation status data based on preset rules, and summarize them to obtain a local tracking value score; Obtain the cumulative value score and sampling status transmitted by the previous node, and aggregate the cumulative value score transmitted by the previous node and the local tracking value score to obtain the updated cumulative value score; The sampling probability is calculated based on the updated cumulative value score. The tracking data of the current node is recorded according to the sampling probability and the sampling status. The updated cumulative value score and the sampling status are then passed to the next node.

[0005] Furthermore, obtaining the business attribute data and running status data of the current node when processing the request includes: Extract the business operation identifier, business parameter value, and data object identifier from the interface path of the request received by the current node as business attribute data; obtain the exception event type and response time value from the current node during the processing of the request as running status data.

[0006] Furthermore, the step of evaluating and summarizing the business attribute data and the operational status data based on preset rules to obtain a local tracking value score includes: The preset rules include preset business weight rules, preset parameter weight rules, preset sensitive feature library, and preset state weight rules; The business attribute score is obtained by matching the business operation identifier with a preset business weight rule; the business attribute score is adjusted by matching the business parameter value with a preset parameter weight rule; the business attribute score is adjusted by matching the data object identifier with a preset sensitive feature library; and the running status score is obtained by matching the abnormal event type and the response time value with a preset status weight rule. The local tracking value score is obtained by summing the business attribute score and the running status score.

[0007] Further, the aggregation of the cumulative value score transmitted from the previous node and the local tracking value score to obtain the updated cumulative value score includes: The weighting factor is determined based on the cumulative value score transmitted from the previous node and the local tracking value score; The cumulative value score transmitted from the previous node and the local tracking value score are weighted and summed based on the weighting factor to obtain the updated cumulative value score.

[0008] Further, the calculation of the sampling probability based on the updated cumulative value score includes: The sampling probability is calculated based on the difference between the updated cumulative value score and the preset value threshold, as well as the real-time system load of the current node.

[0009] Further, the step of recording the tracking data of the current node based on the sampling probability and the sampling state includes: When the sampling state is "sampled", record the tracking data of the current node; When the sampling state is unsampled, the tracking data of the current node is recorded according to the sampling probability.

[0010] Further, the step of recording the tracking data of the current node according to the sampling probability includes: If the sampling probability is greater than or equal to the random number generated by the system, the tracking data of the current node is recorded; if the sampling probability is less than the random number generated by the system, the tracking data of the current node is not recorded; if the tracking data is recorded, the sampling status is updated to the sampled status.

[0011] Furthermore, the random numbers generated by the system are pseudo-random numbers that follow a uniform distribution in the interval 0 to 1.

[0012] Furthermore, the step of passing the updated cumulative value score and the sampling state to the next node includes: The updated cumulative value score and the sampling status are written into the tracking context of the current node's processing request, and the tracking context is used to pass it to the next node.

[0013] On the other hand, the present invention also provides a distributed data end-to-end tracking system for energy storage collaborative response, the system comprising: The value perception module is used to acquire business attribute data and operation status data when the current node processes a request, evaluate the value of the business attribute data and the operation status data based on preset rules, and summarize them to obtain a local tracking value score. The value aggregation module is used to obtain the cumulative value score and sampling status transmitted by the previous node; if the current node is the initial node, or has not obtained the cumulative value score and sampling status transmitted by the previous node, the cumulative value score is initialized to a preset base value and the sampling status is initialized to an unsampled state; the obtained or initialized cumulative value score and the local tracking value score are aggregated to obtain the updated cumulative value score; An adaptive sampling module is used to calculate the sampling probability based on the updated cumulative value score, record the tracking data of the current node according to the sampling probability and the sampling status, and pass the updated cumulative value score and the sampling status to the next node.

[0014] The present invention has the following beneficial effects: This invention achieves dynamic accumulation and transfer of call chain value by evaluating the local tracking value score at each node in real time and aggregating it with the accumulated value score of the previous node; it ensures the integrity of the entire process tracking data by using a sampling state mechanism to ensure that once sampling is performed, sampling continues throughout the process; and it improves the sampling rate of high-value call chains and reduces the sampling rate of low-value call chains through an adaptive sampling strategy based on accumulated value scores, thereby reducing storage and computing costs while ensuring data integrity. Compared with existing fixed sampling strategies, it can more accurately identify and record valuable tracking data, avoid the loss of critical data, and provide complete data support for fault location, performance optimization, and business analysis. Attached Figure Description

[0015] To more clearly illustrate the technical solutions and advantages in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of a distributed data end-to-end tracking method for energy storage collaborative response provided in one embodiment of the present invention; Figure 2 This is a system architecture diagram of a distributed data end-to-end tracking system for energy storage collaborative response, provided as an embodiment of the present invention. Detailed Implementation

[0017] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a distributed data end-to-end tracking method for energy storage collaborative response proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0019] The following description, in conjunction with the accompanying drawings, details a specific scheme for a distributed data end-to-end tracking method for energy storage collaborative response provided by the present invention.

[0020] Example 1: Please see Figure 1The diagram illustrates a method flowchart for a distributed data end-to-end tracking method for energy storage collaborative response provided in an embodiment of the present invention. The method includes: Step S101: Obtain the business attribute data and running status data of the current node when processing the request, evaluate the value of the business attribute data and the running status data according to preset rules and summarize them to obtain the local tracking value score.

[0021] In distributed collaborative systems, the value of different business operations varies significantly. For example, in a virtual power plant aggregated energy storage system, the importance of grid frequency regulation commands far outweighs ordinary status query operations, and data related to electricity billing is far more sensitive than general equipment status data. Furthermore, the value of the same operation varies drastically depending on its runtime state; for instance, the value difference between an initial execution timeout and a normal execution, or between a normal response and an anomaly. Existing fixed sampling strategies treat all requests equally, ignoring this inherent value difference. This leads to blind and inefficient sampling decisions; high-value links may be discarded due to the fixed sampling rate, while low-value links consume significant storage resources. Therefore, a mechanism is needed to identify and quantify the value differences between different requests, providing a basis for subsequent sampling decisions.

[0022] This invention extracts business attribute data and operational status data in real time from each node as it processes a request. Based on preset rules, it assesses the value of each business attribute and operational status, ultimately summarizing them to obtain a local tracking value score. Specifically, business attribute data includes business operation identifiers, key business parameters, and data object identifiers, reflecting the business importance and data sensitivity of the current operation. Operational status data includes abnormal event types and response times, reflecting the health status and abnormal signals of the current operation. The local tracking value score is a quantified numerical indicator used to characterize the tracking value of the current request processed by the current node. It provides a quantitative basis for dynamic decision-making in subsequent steps, ensuring that sampling decisions can be adaptively adjusted based on business importance, data sensitivity, and operational status, rather than blindly and randomly sampling.

[0023] Step S102: Obtain the cumulative value score and sampling status transmitted by the previous node, and aggregate the cumulative value score transmitted by the previous node and the local tracking value score to obtain the updated cumulative value score.

[0024] The local value assessment of a single node is isolated and localized. The overall value of a request is not determined by a single node, but rather by the combined state of all nodes along its flow path. For example, a normal query operation (low value) might trigger a core power control error (high value) in a subsequent node. Traditional methods cannot correlate such cross-node values, leading to the underestimation or even loss of high-value links. If each node makes sampling decisions based solely on its local value, it cannot reflect the global value of the entire call chain. This could result in high-value links being incorrectly judged as not being sampled at some nodes, thus compromising the integrity of the entire process tracing. Therefore, a mechanism is needed to integrate the cumulative value of the previous node with the local value of the current node to generate a cumulative value score that represents the global value of the entire request chain up to the current node, providing a global perspective for the final sampling decision.

[0025] This invention acquires the cumulative value score and sampling status transmitted by the previous node, aggregates the accumulated value information of the previous node's link with the local tracking value score calculated by the current node, and obtains an updated cumulative value score. This updated cumulative value score and sampling status are then transmitted to the next node. Specifically, the cumulative value score is the aggregated result of the local tracking value scores of all nodes in the call chain from the starting node to the current node, used to characterize the global tracking value of the entire call chain up to the current node. The sampling status is used to identify whether the current call chain has been determined to require sampling, including sampling and non-sampling states. Through this value aggregation mechanism, the dynamic accumulation and transmission of call chain value are achieved. This ensures that once a node generates a high local value score due to business criticality, data sensitivity, or an anomaly, this high score can dominate and be transmitted to all subsequent nodes, thereby achieving a global upgrade of the tracking priority of the entire link for critical events and providing a quantitative basis based on a global perspective for the final adaptive sampling decision.

[0026] Step S103: Calculate the sampling probability based on the updated cumulative value score, record the tracking data of the current node according to the sampling probability and the sampling status, and pass the updated cumulative value score and the sampling status to the next node.

[0027] Having gone through the aforementioned steps, a cumulative value score representing the overall value of the entire call chain has been obtained. However, directly making sampling decisions based on this cumulative value score may present the following problems: Under high load pressure, an excessively high sampling rate may lead to performance risks and affect the normal operation of the system; while under low load, an excessively low sampling rate may waste sampling opportunities, resulting in valuable data that could have been collected not being recorded. Furthermore, existing sampling decisions are usually independent and stateless, failing to guarantee that once a high-value node is sampled, the data of subsequent nodes will also be fully recorded, leading to fragmented tracking data and an inability to reconstruct the complete call chain. Therefore, a mechanism is needed to comprehensively consider both global value and real-time system state to make adaptive sampling decisions, while simultaneously ensuring the integrity of the entire process tracing through a sampling state mechanism. This allows the sampling behavior to capture high-value links while automatically converging under high system pressure, achieving a dynamic balance between the necessity of data acquisition and the stability of system operation.

[0028] This invention calculates the sampling probability based on the updated cumulative value score, records the tracking data of the current node according to the sampling probability and sampling status, and passes the updated cumulative value score and sampling status to the next node. Specifically, the sampling probability is dynamically calculated based on the cumulative value score and a preset threshold, used to characterize the likelihood of the current request chain being sampled; the sampling status includes a sampling state and a non-sampling state, used to identify whether the current call chain has been determined to require sampling. Through the sampling status mechanism, once a node decides to sample based on the cumulative value score, subsequent nodes will continue to record tracking data according to the sampling status, ensuring the integrity of the entire call chain's data throughout the entire process. By using an adaptive sampling strategy based on the cumulative value score, the sampling rate is reduced for low-value call chains and increased for high-value call chains, significantly reducing the storage and processing overhead of tracking data while ensuring the integrity of critical data, achieving a balance between data value and system performance.

[0029] In summary, this invention aims to address the problem of significant data loss in high-value link tracing caused by fixed sampling strategies in distributed environments. It employs a value-aware mechanism to multidimensionally evaluate tracing value, aggregates accumulated value to achieve global value transfer across the call chain, and a sampling state mechanism to ensure the integrity of the entire high-value link process. Based on accumulated value, thresholds, and system load, the sampling probability is adaptively adjusted, significantly improving the determinism of key link tracing data acquisition at the same or lower average sampling rate, thus providing more accurate and complete data support for distributed systems.

[0030] Furthermore, obtaining the business attribute data and running status data of the current node when processing the request includes: Extract the business operation identifier, business parameter value, and data object identifier from the interface path of the request received by the current node as business attribute data; obtain the exception event type and response time value from the current node during the processing of the request as running status data.

[0031] In a specific example, the request received by the current node is a business call request initiated by the previous node in the distributed system to the current node. This request carries a tracing context. The tracing context includes at least the Trace ID, Span ID, the cumulative value score passed by the previous node, and the sampling status. This information is written by the previous node and passed to the current node to maintain the continuity of the call chain and the global value accumulation.

[0032] A Trace ID is a unique identifier used to identify a complete call chain. When a request is generated at the first entry node, the system generates a globally unique Trace ID. This Trace ID circulates among all nodes as the request is passed, ensuring that trace data generated by all nodes can be associated with the same call chain. A Span ID is a unique identifier used to identify a single operation or service call within the call chain. A call chain (Trace) consists of multiple consecutive Spans, each representing a basic unit in the call chain, such as the execution of a method at a node or a remote call. Each Span has a unique Span ID and includes a parent Span ID (except for the root Span), used to construct the hierarchical relationship of the call tree. For example, if node A calls node B, node B's Span will record its parent Span as node A's Span ID. Through this parent-child relationship, the complete call topology and timing can be reconstructed.

[0033] When the current node extracts the tracing context from the received request, it parses the Trace ID and Span ID passed by the previous node, and generates the current node's Span based on this information. At the same time, it also writes the cumulative value score and sampling status into the tracing context and passes it to the next node, thus achieving the integrity and continuity of the entire process data tracing.

[0034] The business call requests received by the current node also contain business attribute data. These are intercepted when the request reaches the current node using Aspect-Oriented Programming (AOP) or filters. Three types of business attribute data are extracted from the parameter object carried in the request: The first type is the business operation identifier, obtained by extracting the interface path or method signature from the parameter object, such as extracting keywords from the URL path of an HTTP request to identify the operation type; the second type is the value of the business parameter, obtained by directly reading field values ​​from the parameter object, such as reading the parameter value of the adjustpower field (e.g., 1000kW), to quantify the business scale; and the third type is the data object identifier, obtained by extracting the names of the relevant data objects from the parameter object, such as extracting field names like settlementprice and useridentity, to determine data sensitivity.

[0035] It should be understood that the aforementioned aspect or filter is a lightweight interception mechanism. Other lightweight interception methods can also be used to intercept the request processing flow in a non-intrusive manner without modifying the business logic code. The required data is automatically extracted at the key nodes of the request flow, which not only ensures the real-time and accuracy of data extraction, but also avoids intrusive modifications to the business code and significant impacts on system performance, thus achieving decoupling of data collection from business logic.

[0036] During the current node's processing of the request, an exception listener is used to capture thrown exception objects during the execution of business logic, extract the exception event type, and identify whether an exception has occurred in this operation and the severity of the exception. A timer is used to calculate the time difference from the start of request processing to the completion of processing to obtain the response time of this operation, which is used to quantify the performance of this operation.

[0037] Furthermore, the step of evaluating and summarizing the business attribute data and the operational status data based on preset rules to obtain a local tracking value score includes: The preset rules include preset business weight rules, preset parameter weight rules, preset sensitive feature library, and preset state weight rules.

[0038] The preset business weight rules, preset parameter weight rules, and preset state weight rules are all configurable rule sets pre-established for specific application scenarios. The preset business weight rules are a set of correspondences between business operation identifiers and basic business attribute scores; the preset parameter weight rules are a set of correspondences between business parameter features and score adjustment amounts; and the preset state weight rules are a set of correspondences between running state features and running state scores.

[0039] The business operation identifier includes one or more of the following: interface path, method name, service name, function code, or instruction type; the business parameter characteristics include one or more of the following: parameter value, parameter change range, whether it exceeds a preset threshold, whether it falls within a preset range, or whether it meets a preset combination of conditions; the running status characteristics include one or more of the following: abnormal event type, abnormal severity level, response time range, whether it times out, number of retries, resource usage level, or call failure rate.

[0040] The construction methods for the preset business weight rules, preset parameter weight rules, and preset state weight rules include: pre-determining value assessment dimensions; determining feature classification methods for each value assessment dimension; setting corresponding weight values ​​or adjusting scores for each classification result; and summarizing the rule items corresponding to each value assessment dimension to form a rule set. The rule set can be stored and maintained using configuration files, database configuration tables, mapping tables, dictionary tables, script rules, or a rule engine.

[0041] The rule items in the rule set are configuration items that can be added, deleted, or adjusted. Those skilled in the art can pre-configure the rule set according to specific business scenarios, system monitoring objectives, and tracking strategy requirements to establish the business weight rules, parameter weight rules, and state weight rules.

[0042] The business attribute score is obtained by matching the business operation identifier with a preset business weight rule; the business attribute score is adjusted by matching the business parameter value with a preset parameter weight rule; the business attribute score is adjusted by matching the data object identifier with a preset sensitive feature library; and the running status score is obtained by matching the abnormal event type and the response time value with a preset status weight rule. The local tracking value score is obtained by summing the business attribute score and the running status score.

[0043] Specifically, a mapping table between business operation types and weight values ​​is pre-configured. This mapping table is used to establish the correspondence between business operation identifiers and basic business weight values. The business operation types are classified according to the importance of their business functions, including at least high-priority, medium-priority, and low-priority business operation types; optionally, ordinary business operation types are also included. High-priority business operation types correspond to one or more of core scheduling control, power regulation execution, alarm handling, and settlement processing; medium-priority business operation types correspond to one or more of device status update, policy calculation, and instruction verification; low-priority business operation types correspond to one or more of status query, log recording, cache reading, and general information acquisition.

[0044] The configuration method of the mapping table includes: extracting the business operation identifiers of each interface, method, service, or instruction in the system; classifying each business operation identifier according to its impact on the business chain, the importance of the controlled object, real-time requirements, or data sensitivity; pre-setting a corresponding basic business weight value for each category, and establishing a mapping relationship between the business operation identifier and the basic business weight value. The basic business weight value is represented by a value between 0 and 1, with different business operation types corresponding to different value ranges. Specifically, the basic business weight value corresponding to a high-priority business operation type is higher than that corresponding to a medium-priority business operation type, and the basic business weight value corresponding to a medium-priority business operation type is higher than that corresponding to a low-priority business operation type.

[0045] In one specific implementation, the mapping table can be configured as follows: the basic business weight value for scheduling control type business operations is 0.4 to 0.6; the basic business weight value for power regulation execution type business operations is 0.4 to 0.6; the basic business weight value for alarm handling type business operations is 0.3 to 0.5; the basic business weight value for settlement processing type business operations is 0.3 to 0.5; the basic business weight value for equipment status update type business operations is 0.2 to 0.4; the basic business weight value for strategy calculation type business operations is 0.2 to 0.4; the basic business weight value for status query type business operations is 0.05 to 0.2; and the basic business weight value for log recording type business operations is 0.05 to 0.15.

[0046] The business operation identifier includes one or more of the following: interface path, method name, service name, function code, or instruction type. When the business operation identifier is an interface path, the corresponding business operation type can be determined through path prefix matching, keyword matching, or path template matching. When the business operation identifier is a method name, service name, function code, or instruction type, the corresponding business operation type can be determined through string matching, enumeration mapping, or dictionary table lookup. Based on the matched business operation type, the corresponding basic business weight value is read from the mapping relationship table as the initial business attribute score.

[0047] The mapping table can be stored and maintained using configuration files, database configuration tables, enumeration mapping tables, dictionary tables, or rule engines. When the same business operation identifier matches multiple business operation types simultaneously, the one with the highest corresponding basic business weight value is taken as the initial business attribute score. When no preset business operation type is matched, the initial business attribute score is set to a preset default value.

[0048] When the value of a business parameter, such as the `adjustpower` field, exceeds a preset threshold, an adjustment score is added to the business attribute score to reflect the increased tracking value resulting from an increase in business scale, control intensity, or the scope of adjustment influence. The adjustment score is preset based on the influence level corresponding to the parameter characteristics. The influence levels include at least low influence, medium influence, and high influence, where low influence corresponds to a smaller score adjustment, medium influence corresponds to a moderate score adjustment, and high influence corresponds to a larger score adjustment.

[0049] A sensitive feature library containing keywords related to sensitive data types is established. By matching extracted data object identifiers with this library, a sensitivity adjustment score is added to the business attribute score upon successful matching. This score reflects the impact of the data object's sensitivity on tracking value. The sensitivity adjustment score is pre-set based on data sensitivity levels, which include at least general sensitivity, relatively high sensitivity, and high sensitivity. The higher the data sensitivity level, the greater the corresponding score adjustment.

[0050] The logic for determining the parameter adjustment score and the sensitivity adjustment score is as follows: The degree of improvement in business tracking value is graded according to the corresponding characteristics, and corresponding scores are configured based on the grading results. When the contribution of a certain characteristic to fault location, audit tracing, risk identification, or key business restoration is higher than that of another characteristic, the corresponding score adjustment amount is higher than the score adjustment amount corresponding to the other characteristic. When a data-sensitive characteristic directly affects the importance of audit tracing and risk identification, its corresponding score adjustment amount can be higher than the score adjustment amount corresponding to a parameter characteristic that only reflects changes in business scale.

[0051] In one specific implementation, parameter characteristics can be divided into three levels: general impact, moderate impact, and high impact, with corresponding parameter adjustment scores set to 0.05–0.10, 0.10–0.20, and 0.20–0.30, respectively. Similarly, data sensitivity characteristics can be divided into three levels: general sensitivity, relatively high sensitivity, and high sensitivity, with corresponding sensitivity adjustment scores set to 0.10–0.20, 0.20–0.30, and 0.30–0.40, respectively. The aforementioned numerical ranges are used to reflect the relative magnitude of the contribution of different characteristics to the tracking value, rather than limiting a single fixed value. Those skilled in the art can preset and adjust the score ranges according to the fault location requirements, audit requirements, risk control requirements, and business criticality in specific business scenarios.

[0052] When an abnormal event type is captured or a response time characteristic is detected, a corresponding operational status score is assigned based on the impact level of the status characteristic. The operational status score is set in a graded manner according to the degree of improvement in tracking value based on the operational status characteristics, which include at least abnormal event characteristics and performance status characteristics.

[0053] The abnormal events are characterized by one or more of the following: anomalies, errors, alarms, failures, rejections, rollbacks, interruptions, or retry events generated by the current node during request processing. The abnormal event types are categorized into low-impact anomalies, medium-impact anomalies, and high-impact anomalies based on their impact on business execution results, system stability, equipment security, or fault location value. Low-impact anomalies include one or more of the following: recoverable alarms, successful single retry, non-critical verification failures, or general informational anomalies. Medium-impact anomalies include one or more of the following: continuous retries, functional degradation, partial processing failures, general equipment-side fault alarms, or business execution anomalies. High-impact anomalies include one or more of the following: control command issuance failure, critical adjustment action failure, equipment protection triggering, core service unavailability, data write failure, transaction settlement failure, or severe anomalies leading to link interruption. For abnormal events of different impact levels, corresponding operational status scores are pre-configured, with high-impact anomalies having higher operational status scores than medium-impact anomalies, and medium-impact anomalies having higher operational status scores than low-impact anomalies.

[0054] The performance status characteristic is the response time consumed by the current node in processing the current request. The response time refers to the time interval from when the current node receives the request to when the current node completes the request processing and returns the processing result, or the time interval from when the current node starts executing the target business logic to when it ends. The response time is divided into normal interval, attention interval, alarm interval, and critical interval according to latency level. The normal interval indicates a response time lower than a first preset threshold; the attention interval indicates a response time greater than or equal to the first preset threshold and less than a second preset threshold; the alarm interval indicates a response time greater than or equal to the second preset threshold and less than a third preset threshold; and the critical interval indicates a response time greater than or equal to the third preset threshold. For different response time intervals, corresponding operating status scores are pre-configured, wherein the operating status score corresponding to the critical interval is higher than the operating status score corresponding to the alarm interval, the operating status score corresponding to the alarm interval is higher than the operating status score corresponding to the attention interval, and the operating status score corresponding to the attention interval is higher than the operating status score corresponding to the normal interval; preferably, the operating status score corresponding to the normal interval is 0 or a preset low value.

[0055] The logic for determining the operating status score is as follows: the contribution of the corresponding status characteristics to the fault location value, performance analysis value, risk identification value, and business restoration value is classified, and the corresponding score is set according to the classification results; when the contribution of a certain status characteristic to identifying key faults, restoring the full picture of the call chain, or locating performance bottlenecks is higher than that of another status characteristic, its corresponding operating status score is higher than that of the other status characteristic.

[0056] In one specific implementation, the operational status scores for low-impact anomalies, medium-impact anomalies, and high-impact anomalies can be set to 0.10–0.20, 0.20–0.35, and 0.35–0.50, respectively; the operational status scores for the attention interval, alarm interval, and critical interval can be set to 0.05–0.15, 0.15–0.30, and 0.30–0.45, respectively. The aforementioned score ranges are used to reflect the relative magnitude of the contribution of different operational status characteristics to the tracking value, rather than limiting a single fixed value. Those skilled in the art can pre-configure and adjust the anomaly event classification, response time interval division, and corresponding scores according to the real-time requirements, equipment safety requirements, fault handling requirements, and system performance goals in specific business scenarios.

[0057] In a specific example, when a BMS_Alert is captured, if the BMS_Alert is pre-classified as a medium-impact anomaly or a high-impact anomaly, an operating status score corresponding to that impact level is assigned; when the response time is between a second preset threshold and a third preset threshold, an operating status score corresponding to the alarm interval is assigned; when the response time is lower than a first preset threshold, an operating status score corresponding to the normal interval is assigned; when the response time is higher than or equal to a third preset threshold, an operating status score corresponding to the severe interval is assigned.

[0058] It should be understood that the business attribute score represents the inherent business value and data sensitivity of this operation. These attributes are determined before the operation begins and belong to the static value dimension. The operational status score, on the other hand, represents the real-time health status and anomalies during the operation's execution. These statuses change dynamically during execution and belong to the dynamic value dimension. By calculating the business attribute score and the operational status score separately, the local tracking value can be comprehensively evaluated. This considers both the business importance of the operation and the real-time execution status, ensuring that the final local tracking value score accurately reflects the degree of tracking value of this operation and provides a more precise quantitative basis for subsequent adaptive sampling decisions.

[0059] The local tracking value score is obtained by summing the business attribute score and the running status score.

[0060] It should be noted that the original value score is obtained by summing the business attribute score and the operating status score. To avoid inconsistencies in the numerical range caused by the superposition of different rule items, and to maintain the stability of the input range for subsequent cumulative value aggregation and sampling probability calculation, the original value score is normalized to obtain the local tracking value score.

[0061] The normalization process is based on a preset scoring range. The preset minimum value is the base value when none of the scores match the gain rule, and the preset maximum value is the sum of the maximum scores achievable by each scoring dimension under the preset rules. The preset maximum value is predetermined based on the maximum allowed score for each dimension in the business weight rule, parameter weight rule, sensitive feature rule, and state weight rule. In one specific implementation, if the maximum base business weight value is 0.6, the maximum parameter adjustment score is 0.3, the maximum sensitivity adjustment score is 0.4, and the maximum operating state score is 0.5, then the preset maximum value for the original value score is 1.8.

[0062] Preferably, the original value score is mapped to a range of 0 to 1 using linear normalization. The preset minimum and maximum values ​​can be predetermined based on the rule base configuration and updated synchronously as rule items are adjusted. Through normalization, the relative value differences between different business requests can be preserved, while avoiding direct truncation that would cause medium-to-high value requests and extremely high value requests to be mapped to the same upper limit value. This improves the ability of the local tracking value score to distinguish between requests of different value levels.

[0063] When no preset rule is matched in this operation, the original value score is assigned a preset default base value, and the same normalization process is performed on the preset default base value to obtain the corresponding local tracking value score. The preset default base value is used to characterize that although the request does not show significant business importance, data sensitivity, or abnormal characteristics, it still belongs to a valid processing unit in the call chain, retaining a minimum tracking value. This is to avoid directly assigning a value of 0 to all requests that do not match the rules, which would cause ordinary link samples to be completely excluded, thereby affecting the continuity of call chain baseline behavior analysis, normal business statistical analysis, and subsequent value aggregation.

[0064] When no preset rule is matched in this operation, the local tracking value score is assigned a preset default base value. The preset default base value is used to indicate that although the request does not show significant business importance, data sensitivity, or abnormal characteristics, it still belongs to a valid processing unit in the call chain, retaining a minimum tracking value. This is to avoid directly assigning a value of 0 to all requests that do not match the rules, which would cause ordinary link samples to be completely excluded, thereby affecting the continuity of call chain baseline behavior analysis, normal business statistical analysis, and subsequent value aggregation.

[0065] The preset default base value is less than any non-default original score used to characterize significant business features, parameter features, sensitive features, or abnormal state features, and the default local tracking value score after normalization is lower than the base threshold for triggering high-probability sampling, so as to ensure that it only serves as the minimum value placeholder and does not dominate subsequent sampling decisions.

[0066] In one specific implementation, the preset default base value can be set to a small value between 0.01 and 0.10, preferably 0.05. The 0.05 represents a low percentage of the base value within the overall value scoring range, reflecting the design logic that "missing a rule does not equate to no tracking value," while ensuring a significant distinction from the score increment generated when an important rule is hit. Those skilled in the art can pre-configure and adjust the preset default base value based on the request distribution, baseline monitoring requirements, and sampling resource constraints in a specific system.

[0067] Further, the aggregation of the cumulative value score transmitted from the previous node and the local tracking value score to obtain the updated cumulative value score includes: The weighting factor is determined based on the cumulative value score transmitted from the previous node and the local tracking value score; The cumulative value score transmitted from the previous node and the local tracking value score are weighted and summed based on the weighting factor to obtain the updated cumulative value score.

[0068] In a specific example, the weighting factor is dynamically determined based on the ratio of the cumulative value score passed from the previous node to the local tracking value score. The updated cumulative value score formula can be expressed as: ; in, This represents the cumulative value score after the current node is updated. This represents the cumulative value points passed from the previous node. This represents the local tracking value score of the current node. Represents historical weighting factors. Indicates the current weighting factor. This represents a very small positive number 1e-6, used to prevent division by zero.

[0069] A dynamic weighted average based on proportions allows the weight of a value in the fusion process to be determined by its intrinsic value. When Much larger At that time, the calculated Approaching 1, A value close to 0 indicates that the upstream link has accumulated a high value (possibly due to previous important operations or anomalies). The system will automatically tend to inherit and maintain this high-value state, and ordinary operations of the current node will not significantly dilute the overall value. Conversely, a value surge event (such as a sudden anomaly) has occurred at the current node. The system will automatically shift the weight towards the current event, enabling it to quickly dominate and increase the accumulated value score, ensuring that key signals are amplified.

[0070] In another specific example, weighted average aggregation may suffer from the problem of critical signal dilution. In a distributed long-chain process, an early high-value event (such as a security check failure) may be captured by the local value score of the node at that time, but its dominance may be gradually weakened in the weighted average calculation of multiple low-value nodes (such as log records and cache queries). Therefore, a more robust aggregation strategy is needed that can permanently lock in critical events, ensuring that once a high-value signal appears on any node, that signal will have a decisive and irreversible impact on the final tracking value of the entire chain, thus gaining absolute priority in sampling decisions.

[0071] The cumulative value score passed from the previous node is directly compared with the local tracking value score. The larger of the two values ​​is selected with a weight of 1, and the other value is selected with a weight of 0. The larger value is then used as the updated cumulative value score.

[0072] Based on the mathematical principle of extreme value propagation, in a distributed link, each node, when performing aggregation, compares the incoming global value with its own locally generated value, and propagates the larger of the two as the new global value. This way, if a node generates a high value due to its business criticality, data sensitivity, or an anomaly, it can prevent such a problem from occurring. This high score will replace a lower historical score. From this node until the end of the link, this high score will be used as... Once transmitted along the path, the lower local value of any subsequent node cannot diminish it. This ensures that the signal strength of critical events does not attenuate or get overwritten during transmission, achieving the most thorough and reliable marking of high-value links and fundamentally eliminating the possibility of missing key traces due to signal dilution.

[0073] It should be noted that if the current node is the initial node, or if the tracking context is lost due to an error, the initial cumulative value is set to a preset base value (e.g., 0), and the sampling state is set to the unsampled state.

[0074] Further, the calculation of the sampling probability based on the updated cumulative value score includes: The sampling probability is calculated based on the difference between the updated cumulative value score and the preset value threshold, as well as the real-time system load of the current node.

[0075] Directly basing sampling decisions on cumulative value scores may present several problems: First, the numerical range and distribution characteristics of cumulative value scores are uncertain, making it difficult to set a reasonable sampling threshold. Second, a fixed sampling threshold cannot adapt to dynamically changing business scenarios and system loads, potentially leading to an excessively high sampling rate under high load, impacting system performance, or an excessively low sampling rate under low load, wasting sampling opportunities. Therefore, a mechanism is needed to map cumulative value scores to a reasonable sampling probability range and dynamically adjust it based on real-time system load.

[0076] This invention calculates sampling probabilities based on updated cumulative value scores, transforming the cumulative value scores into probability values ​​that can be directly used for sampling decisions. Specifically, the calculation of sampling probabilities considers the difference between the cumulative value score and a preset value threshold, as well as the real-time system load of the current node. This ensures that when the cumulative value score is significantly higher than the threshold, the sampling probability approaches 100%, guaranteeing that high-value call chains are sampled first; when the cumulative value score is significantly lower than the threshold, the sampling probability approaches 0, reducing the sampling rate of low-value call chains. Simultaneously, by introducing real-time system load as a negative offset, the sampling probability is reduced under high load to alleviate system pressure, and the sampling probability is increased under low load to accumulate richer observable data.

[0077] Preferably, an S-shaped curve function is used to map the updated cumulative value to the sampling probability interval, and the formula for the sampling probability can be expressed as: ; in, This represents the sampling probability of the current node. This indicates a maximum sampling probability of 100%. This represents the cumulative value score after the current node is updated. This represents the baseline importance level that triggers high-probability sampling. Its value is the 75th percentile of the cumulative value score updated among all requests processed by the current node within a set time window (e.g., one hour). This represents an exponential function with the natural constant e as its base, used to map value onto an S-shaped curve. When the value is much higher than the threshold, the probability approaches... When the value is much lower than the given value, the probability approaches 0.

[0078] k represents a preset positive integer, which serves as a scaling factor for the exponential function. It is used to adjust the sensitivity of the sampling probability curve to changes in value score. Its function is to make the transition region of the S-shaped curve function steeper, ensuring that when the cumulative value score slightly exceeds the threshold, the calculated sampling probability can quickly approach the maximum sampling rate from a low value, thereby achieving deterministic capture of high-value links and avoiding the omission of important data due to the slow growth of the function.

[0079] Preferably, the value of k ranges from 5 to 10, and in this embodiment, the value is 6.

[0080] L represents the load and serves as a negative offset. The threshold point at which the load takes effect is dynamically adjusted to make more conservative decisions when the load is high. Real-time CPU load, real-time memory load, or other indicators that can characterize the real-time load of the system can be used and normalized to a value between 0 and 1.

[0081] It should be understood that by incorporating the real-time system load of the current node as a negative offset into the calculation process, the actual effective threshold point is dynamically adjusted. This makes the sampling decision more conservative under high load conditions, reducing the sampling probability to alleviate system pressure, while expanding the sampling range under low load conditions to accumulate richer observable data.

[0082] Because the S-curve function has good monotonicity and smoothness, it can map the cumulative value score to a sampling probability range of 0-100%. When the cumulative value score equals the base value threshold, the sampling probability is 50%. When the cumulative value score is higher than the threshold, the sampling probability approaches 100% as the difference increases. When the cumulative value score is lower than the threshold, the sampling probability approaches 0 as the difference increases. Simultaneously, by introducing the real-time system load as a negative offset into the calculation process, the actual effective threshold point is dynamically adjusted, ensuring that for the same cumulative value score, the higher the system load, the lower the sampling probability, thus achieving a dynamic balance between data acquisition and system performance.

[0083] Further, the step of recording the tracking data of the current node based on the sampling probability and the sampling state includes: When the sampling state is "sampled", record the tracking data of the current node; When the sampling state is unsampled, the tracking data of the current node is recorded according to the sampling probability.

[0084] Further, the step of recording the tracking data of the current node according to the sampling probability includes: If the sampling probability is greater than or equal to the random number generated by the system, the tracking data of the current node is recorded; if the sampling probability is less than the random number generated by the system, the tracking data of the current node is not recorded; if the tracking data is recorded, the sampling status is updated to the sampled status.

[0085] If each node makes sampling decisions independently based on sampling probability, inconsistent sampling behavior can occur across different nodes for the same call chain. This means some nodes record tracking data while others do not, resulting in fragmented tracking data that cannot reconstruct the complete call chain. For example, a high-value call chain might be sampled at one node but not at subsequent nodes due to lower sampling probabilities, leading to incomplete tracking data and hindering fault localization.

[0086] This invention introduces a sampling state mechanism to ensure that once a node decides to sample the current call chain based on its accumulated value score, all subsequent nodes will recognize this sampling state and continue recording tracking data, thus guaranteeing the integrity of the entire call chain's data throughout the entire process. Specifically, the sampling state includes a sampled state and a non-sampled state. When a node decides to sample, it updates its sampling state to the sampled state and passes it to the next node. Upon receiving the sampled state, if the next node detects it as a sampled state, it directly records the tracking data without making a decision based on the sampling probability. If the previous node was in a non-sampled state, it makes a decision based on the sampling probability.

[0087] It should be understood that the recorded trace data is persistently stored in a trace data storage system (such as a database or log file) for subsequent fault location, performance analysis, and business auditing. It is important to distinguish between trace context and trace data: trace context is a lightweight data carrier that accompanies requests between nodes, containing necessary information such as Trace ID, Span ID, cumulative value score, and sampling status, used to maintain the continuity of the call chain and transmit sampling status; it is small in size and transmitted in memory. Trace data, on the other hand, is detailed operational information recorded by the current node, containing complete business attributes, running status, timestamps, and other detailed data; it is large in size and requires persistent storage.

[0088] Furthermore, the random numbers generated by the system are pseudo-random numbers that follow a uniform distribution in the interval 0 to 1.

[0089] In a specific example, a high-precision timestamp of the current system is first obtained as the initial seed to ensure the unpredictability of the random sequence at each decision. Then, a pseudo-random number generation algorithm, such as a linear congruential generator (LCG) or the Mersenne Twister algorithm, is used to calculate a floating-point number between 0 and 1 (inclusive of 0 but exclusive of 1, or a closed interval). This floating-point number statistically follows a uniform distribution, meaning that in a large number of repeated trials, the probability of falling within any equal-length subinterval is equal.

[0090] It should be understood that in adaptive sampling decision-making, using pseudo-random numbers that follow a uniform distribution is to transform the calculated theoretical sampling probability into a specific binary action (sample or not sample). Since the sampling probability represents the likelihood of sampling, comparing the sampling probability with a random number uniformly distributed between 0 and 1 ensures statistically rigorously that the actual sampling frequency converges to the theoretical probability. Although pseudo-random numbers are not truly random in the physical sense, their computational speed is extremely fast and their distribution characteristics are sufficient to meet the needs of load balancing and probability control. They can achieve a high-probability capture of high-value links and a probabilistic discarding of low-value links without blocking business threads, thereby achieving a dynamic balance between system resources and data value.

[0091] Furthermore, the step of passing the updated cumulative value score and the sampling state to the next node includes: The updated cumulative value score and the sampling status are written into the tracking context of the current node's processing request, and the tracking context is used to pass it to the next node.

[0092] It should be understood that the tracking context here has the same meaning as the tracking context described above. Its function is to serve as a carrier for value information transmission. After each node completes the calculation of its local tracking value score and the aggregation of the accumulated value score, it writes the updated accumulated value score and sampling status into the tracking context. The tracking context is then passed to the next node through a request transmission mechanism (such as HTTP headers or RPC context). This transmission mechanism ensures the dynamic accumulation and transmission of the accumulated value score in the call chain, enabling each node to obtain global value information up to the previous node. At the same time, through the transmission of sampling status, it achieves end-to-end tracking integrity guarantee that once sampling occurs, sampling continues throughout the entire process.

[0093] When the cumulative value score passed from the previous node is significantly greater than the local tracking value score, the aggregated cumulative value score tends to inherit and maintain the high value state of the previous node, and ordinary operations of the current node will not significantly dilute the overall value. When the local tracking value score is significantly greater than the cumulative value score passed from the previous node, the aggregated cumulative value score will rapidly increase and reflect the high-value events of the current node, ensuring that key signals are amplified and transmitted. Through this accumulation mechanism, once a node generates a high local value score due to business criticality, data sensitivity, or anomalies, this high score can dominate and be transmitted to all subsequent nodes, achieving a global increase in the tracking priority of key events across the entire chain.

[0094] Example 2: Please see Figure 2The diagram illustrates a system architecture block diagram of a distributed data end-to-end tracking system for energy storage collaborative response provided by an embodiment of the present invention. The system includes a value perception module 201, a value aggregation module 202, and an adaptive sampling module 203.

[0095] The value perception module 201 is used to acquire business attribute data and operation status data when the current node processes a request, evaluate the value of the business attribute data and the operation status data based on preset rules, and summarize them to obtain a local tracking value score. The value aggregation module 202 is used to obtain the cumulative value score and sampling status transmitted by the previous node; if the current node is the initial node, or has not obtained the cumulative value score and sampling status transmitted by the previous node, the cumulative value score is initialized to a preset base value and the sampling status is initialized to an unsampled state; the obtained or initialized cumulative value score and the local tracking value score are aggregated to obtain the updated cumulative value score; The adaptive sampling module 203 is used to calculate the sampling probability based on the updated cumulative value score, record the tracking data of the current node according to the sampling probability and the sampling status, and pass the updated cumulative value score and the sampling status to the next node.

[0096] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0097] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

Claims

1. A distributed data end-to-end tracking method for energy storage collaborative response, characterized in that, The method includes: Obtain business attribute data and operation status data when the current node processes a request, evaluate the value of the business attribute data and the operation status data based on preset rules, and summarize them to obtain a local tracking value score; Obtain the cumulative value score and sampling status transmitted by the previous node, and aggregate the cumulative value score transmitted by the previous node and the local tracking value score to obtain the updated cumulative value score; The sampling probability is calculated based on the updated cumulative value score. The tracking data of the current node is recorded according to the sampling probability and the sampling status. The updated cumulative value score and the sampling status are then passed to the next node.

2. The distributed data end-to-end tracking method for energy storage collaborative response according to claim 1, characterized in that, The process of obtaining the business attribute data and running status data of the current node when processing a request includes: Extract the business operation identifier, business parameter value, and data object identifier from the interface path of the request received by the current node as business attribute data; obtain the exception event type and response time value from the current node during the processing of the request as running status data.

3. The distributed data end-to-end tracking method for energy storage collaborative response according to claim 2, characterized in that, The process of evaluating and summarizing the business attribute data and the operational status data based on preset rules to obtain a local tracking value score includes: The preset rules include preset business weight rules, preset parameter weight rules, preset sensitive feature library, and preset state weight rules; The business attribute score is obtained by matching the business operation identifier with a preset business weight rule; the business attribute score is adjusted by matching the business parameter value with a preset parameter weight rule; the business attribute score is adjusted by matching the data object identifier with a preset sensitive feature library; and the running status score is obtained by matching the abnormal event type and the response time value with a preset status weight rule. The local tracking value score is obtained by summing the business attribute score and the running status score.

4. The distributed data end-to-end tracking method for energy storage collaborative response according to claim 1, characterized in that, The process of aggregating the cumulative value score transmitted from the previous node and the local tracking value score to obtain the updated cumulative value score includes: The weighting factor is determined based on the cumulative value score transmitted from the previous node and the local tracking value score; The cumulative value score transmitted from the previous node and the local tracking value score are weighted and summed based on the weighting factor to obtain the updated cumulative value score.

5. The distributed data end-to-end tracking method for energy storage collaborative response according to claim 1, characterized in that, The calculation of the sampling probability based on the updated cumulative value score includes: The sampling probability is calculated based on the difference between the updated cumulative value score and the preset value threshold, as well as the real-time system load of the current node.

6. The distributed data end-to-end tracking method for energy storage collaborative response according to claim 1, characterized in that, The step of recording the tracking data of the current node based on the sampling probability and the sampling state includes: When the sampling state is "sampled", record the tracking data of the current node; When the sampling state is unsampled, the tracking data of the current node is recorded according to the sampling probability.

7. A distributed data end-to-end tracking method for energy storage collaborative response according to claim 6, characterized in that, The step of recording the tracking data of the current node according to the sampling probability includes: If the sampling probability is greater than or equal to the random number generated by the system, the tracking data of the current node is recorded; if the sampling probability is less than the random number generated by the system, the tracking data of the current node is not recorded; if the tracking data is recorded, the sampling status is updated to the sampled status.

8. A distributed data end-to-end tracking method for energy storage collaborative response according to claim 7, characterized in that, The random numbers generated by the system are pseudo-random numbers that follow a uniform distribution in the interval 0 to 1.

9. A distributed data end-to-end tracking method for energy storage collaborative response according to claim 7, characterized in that, The step of passing the updated cumulative value score and the sampling state to the next node includes: The updated cumulative value score and the sampling status are written into the tracking context of the current node's processing request, and the tracking context is used to pass it to the next node.

10. A distributed data end-to-end tracking system for energy storage collaborative response, characterized in that, The system includes: The value perception module is used to acquire business attribute data and operation status data when the current node processes a request, evaluate the value of the business attribute data and the operation status data based on preset rules, and summarize them to obtain a local tracking value score. The value aggregation module is used to obtain the cumulative value score and sampling status transmitted by the previous node; if the current node is the initial node, or has not obtained the cumulative value score and sampling status transmitted by the previous node, the cumulative value score is initialized to a preset base value and the sampling status is initialized to an unsampled state; the obtained or initialized cumulative value score and the local tracking value score are aggregated to obtain the updated cumulative value score; An adaptive sampling module is used to calculate the sampling probability based on the updated cumulative value score, record the tracking data of the current node according to the sampling probability and the sampling status, and pass the updated cumulative value score and the sampling status to the next node.

Images