Intelligent event orchestration trigger and running link monitoring system for distributed system

Abstract

The application discloses a distributed system-oriented intelligent event arrangement trigger and running link monitoring system and relates to the technical field of distributed event arrangement.The system comprises a link data acquisition and processing module, which is used for acquiring multi-source link data and performing data preprocessing;an event candidate association generation module, which is used for extracting a trigger event and an execution event, constructing event fingerprint features for association evaluation, and generating a candidate association structure; a cause-effect chain reconstruction module, which is used for path expansion and cause-effect reconstruction, identification of cause-effect reconstruction reliability, screening of reconstructed cause-effect chains; an arrangement trigger control module, which is used for trigger arrangement decision and identification of link signatures, and realization of repetition suppression and idempotent control; and a link credibility evaluation module, which is used for offset determination, correction of monitoring caliber and adjustment of threshold value.The problems that event trigger and execution link are difficult to accurately associate, cause-effect relationship is prone to misjudgment, and arrangement is inaccurate and monitoring caliber deviates under the conditions of dynamic topology and identification distortion are solved.

Description

Technical Field

[0001] This invention relates to the field of distributed event orchestration technology, specifically to an intelligent event orchestration triggering and operation link monitoring system for distributed systems. Background Technology

[0002] With the widespread application of cloud computing, containerized deployment, and elastic scaling mechanisms, distributed systems trigger the collaborative execution of multiple services through synchronous calls and asynchronous message interactions, forming an orchestration process consisting of event triggering, task scheduling, and downstream execution linkage. During system operation, multi-source link data is continuously generated. Unified processing and link-level monitoring and analysis of this multi-source link data have become an important technical direction supporting event orchestration management and the operational assurance of distributed systems.

[0003] For example, the invention patent with publication number CN120872547A discloses a distributed job orchestration and scheduling method and device, storage medium, and computer equipment, which relates to the field of distributed task scheduling technology and is applicable to the financial and medical business fields. Its main purpose is to solve the problem that existing distributed job scheduling systems lack task dependency management and dynamic orchestration capabilities. This includes using a binary tree structure to model each task to be executed, obtaining a task binary tree corresponding to each task; using a job orchestration engine to serialize the task binary tree to obtain the corresponding task sequence; and publishing the task sequence to an event flow bus. Once the event flow bus is started, the central scheduler allocates the tasks to be executed to different distributed executors for execution. The distributed executors transmit execution results back to the event flow bus in real time, so that the event flow bus triggers downstream tasks after the upstream tasks are completed, until the entire task sequence is executed.

[0004] For example, invention patent CN102467701B discloses event-based orchestration in a distributed order orchestration system, including an event manager configured to generate and publish a set of events based on processing status and metadata stored in a database. A group of subscribers can consume this set of events, and each subscriber can perform a task based on the consumed events.

[0005] However, in dynamic topology environments such as cloud-native microservices or serverless, existing event orchestration typically relies on traces or log tags, such as traceId / spanId, message ID, and callback context, to associate triggered events with downstream execution events and perform rule-based judgments and link reconstruction. But under conditions of frequent instance scaling, asynchronous message queue delivery, timeout retries, and cross-thread or cross-process context passing, the associated identifiers may be lost, reused, or rewritten by middleware, causing the same trigger to be mistakenly merged or split into multiple fragments on the link. As a result, orchestration triggers may be executed repeatedly or missed, and the monitoring side may have a skewed interpretation of the latency, error rate, and alarm count for the same fault, thereby reducing the accuracy of link reconstruction and the reliability of cross-version or cross-environment comparisons.

[0006] Therefore, in order to address the above issues, there is an urgent need for an intelligent event orchestration, triggering, and runtime monitoring system for distributed systems. Summary of the Invention

[0007] Technical problems to be solved

[0008] To address the shortcomings of existing technologies, this invention provides an intelligent event orchestration triggering and execution link monitoring system for distributed systems. It solves the problems of inaccurate orchestration and monitoring deviation caused by difficulty in accurately associating event triggering and execution links and easy misjudgment of causal relationships under dynamic topology and label distortion conditions.

[0009] Technical solution

[0010] To achieve the above objectives, this invention provides the following technical solution: an intelligent event orchestration, triggering, and execution link monitoring system for distributed systems, comprising: a link data acquisition and processing module, used to acquire multi-source link data in real time, perform time alignment, fingerprint normalization, and association construction on the multi-source link data to form a unified event link data foundation; an event candidate association generation module, used to extract triggering events and execution events within a sliding time window, construct event fingerprint features based on multi-source link data, and combine the event fingerprint features to evaluate the degree of content matching, temporal rationality, and topological reachability, and generate candidate association structures based on the association evaluation results; and a causal chain reconstruction module. The system is used for path expansion and causal reconstruction based on candidate association structures, and to analyze the consistency aggregation and reuse conflicts of reconstructed links using association evaluation results, identify the reliability of causal reconstruction, screen reconstructed causal chains based on reliability, and complete conflict correction; the orchestration trigger control module is used to trigger orchestration decisions based on reconstructed causal chains and reliability, and to achieve duplication suppression and idempotency control by combining link signature recognition; the link trust evaluation module is used to extract original statistical results and reconstructed statistical results based on multi-source link data and reconstructed causal chains, combine the original statistical results and reconstructed statistical results to determine the offset, identify the statistical caliber offset based on the determination result, and perform monitoring caliber correction and threshold adaptive adjustment.

[0011] Furthermore, the specific process of real-time collection of multi-source link data, followed by time alignment, fingerprint normalization, and association construction to form a unified event link data foundation, is as follows: Real-time collection of message delivery data, call tracing data, runtime log data, and instance runtime data generated during the operation of the distributed system. Message delivery data includes: message identifier, topic name, production time, consumption time, delivery count, retries count, consumer group name, and message content fingerprint; call tracing data includes: tracing identifier, span identifier, parent span identifier, service name, interface name, start time, end time, execution duration, and status flag; runtime log data includes: log time, log template fingerprint, exception type, and exception stack fingerprint; instance runtime data includes: instance identifier, version identifier, and instance creation time. The process involves: converting call tracing data, runtime log data, message delivery data, and instance runtime data into system standard time and aligning them; performing fingerprinting and normalization on log template fingerprints and exception stacks, and performing consistent encoding on message content fingerprints to eliminate format differences between different collection terminals; determining whether a message event is a retry based on the number of deliveries and retries, and marking new triggers and duplicate deliveries; constructing call association relationships for call tracing data based on tracing identifiers, span identifiers, and parent span identifiers, and constructing delivery association relationships for message delivery data based on message identifiers and consumer group names, generating call relationship graphs and delivery relationship graphs based on the call association relationships and delivery association relationships respectively; and establishing an event link monitoring database to store raw and preprocessed call tracing data, runtime log data, message delivery data, and instance runtime data.

[0012] Furthermore, the specific process of extracting trigger events and execution events within the sliding time window and constructing event fingerprint features based on multi-source link data is as follows: using call tracing data and message delivery data to extract the set of trigger events and the set of execution events within the sliding time window; for any trigger event and execution event, obtain the corresponding interface name code, topic name code, log template fingerprint, exception stack fingerprint, and message content fingerprint; construct event fingerprint vectors respectively; and synchronously record the occurrence time, execution duration, instance identifier, service name, and number of retries corresponding to the event.

[0013] Furthermore, the specific process of evaluating the correlation between content matching degree, temporal rationality, and topological reachability based on event fingerprint features is as follows: The event fingerprint vectors of the triggering event and the execution event are multiplied by a vector dot product to obtain the numerator. The magnitudes of the two event fingerprint vectors are calculated separately, multiplied together, and then added to a minimum positive number to obtain the denominator. The ratio of the numerator to the denominator is calculated to obtain the content fingerprint similarity value. The time difference is obtained by subtracting the occurrence time of the triggering event from the occurrence time of the execution event. The link category is determined by the combination of the service name, interface name, and topic name of the triggering event. The historical time difference set of similar links is retrieved from the event link monitoring database, and the time difference is statistically analyzed. The median of the time difference is used as the latency reference value, and the median absolute deviation of the time difference is calculated as the latency median absolute deviation. The absolute difference between the current time difference and the latency reference value is calculated and divided by the sum of the latency median absolute deviation and the smallest positive number to obtain the latency deviation. The latency reachability probability value is obtained by taking the negative exponent of the latency deviation. Combining the call relationship graph and the delivery relationship graph, the shortest path hop count from the service to which the triggering event belongs to the service to which the execution event belongs is calculated by breadth-first search. The shortest path hop count is added to one and the reciprocal is taken to obtain the topology reachability value. The content fingerprint similarity value, the latency reachability probability value and the topology reachability value are multiplied together, the smallest positive number is added, and the cube root is taken to obtain the candidate association consistency value.

[0014] Furthermore, the specific process of generating candidate association structures based on the association evaluation results is as follows: calculate the candidate association consistency value between all pairs of trigger events and execution events within the sliding time window, and form a set of candidate association edges, which are stored in the form of triplets of trigger event identifier, execution event identifier, and candidate association consistency value; for the candidate association edges corresponding to the same trigger event and execution event, sort them in descending order according to the candidate association consistency value, and retain only the candidate association edges whose candidate association consistency value is greater than the association threshold; summarize all candidate association edges to construct a candidate association graph, with events as nodes, candidate association edges as directed edges, and the candidate association consistency value as the edge weight, and write it into the event link monitoring database.

[0015] Furthermore, based on the candidate association structure, path expansion and causal reconstruction are performed. The association evaluation results are used to analyze the consistency aggregation and reuse conflicts of the reconstructed links. The specific process for identifying the reliability of causal reconstruction is as follows: All candidate association edges and their corresponding candidate association consistency values ​​within the sliding time window are extracted from the candidate association graph. Based on directed graph path search, starting from the triggering event, events are progressively expanded downstream along the candidate association edges to generate a set of candidate causal chains. The set of candidate association edges and the corresponding sequence of candidate association consistency values ​​contained in each candidate causal chain are obtained. For each candidate causal chain, a minimum positive number is added to the candidate association consistency value of each candidate association edge in the candidate causal chain, and the natural logarithm is taken to obtain the logarithmic consistency value. The logarithmic consistency values ​​of all candidate association edges in the candidate causal chain are calculated... The average logarithmic consistency value is obtained by dividing the sum by the number of candidate associated edges. The link consistency aggregation value is obtained by performing a natural exponential operation on the average logarithmic consistency value. For all call tracing data records in the same candidate causal chain, the corresponding tracing identifier, message identifier, start time, and end time are read. Pairs of records with the same tracing identifier or the same message identifier are selected. Using the start and end times of the call tracing data records as time intervals, the intersection length and union length of the two time intervals in the record pair are calculated. The intersection length is divided by the sum of the union length and the smallest positive number to obtain the time overlap ratio of the record pair. The maximum time overlap ratio among all record pairs is taken as the reuse conflict degree value. The link consistency aggregation value is multiplied by the multiplexing conflict degree value after subtracting the reuse conflict degree value from one to obtain the causal chain confidence value.

[0016] Further, the specific process of reconstructing causal chains and correcting conflicts based on reliability screening is as follows: Calculate the causal chain confidence value corresponding to all candidate causal chains in the candidate association graph. For the same triggering event, sort the candidate causal chains in descending order of their causal chain confidence values, and retain the candidate causal chains with causal chain confidence values ​​greater than the confidence threshold as preferred causal chains. If there is more than one preferred causal chain for the same triggering event, the preferred causal chain with the highest causal chain confidence value is taken as the main chain, and the remaining preferred causal chains are marked as conflict chains. For conflict chains, if the included call tracing data records overlap with the main chain in the time interval, delete the call tracing data records that overlap with the main chain in the conflict chain, and recalculate the causal chain confidence value. If the recalculated causal chain confidence value is still greater than the confidence threshold, the conflict chain is retained as a split chain; otherwise, it is discarded. The main chain corresponding to the triggering event is used as the reconstructed causal chain. If there is no candidate causal chain with a causal chain confidence value greater than the confidence threshold, it is determined that the causal chain of the triggering event cannot be reliably reconstructed and is marked as a causal event with undetermined causality.

[0017] Furthermore, the specific process of triggering orchestration decisions based on reconstructed causal chains and reliability, and combining link signature recognition to achieve duplication suppression and idempotent control, is as follows: Read the reconstructed causal chains and causal chain confidence values ​​corresponding to all triggered events within the sliding time window; for each triggered event, if the causal chain confidence value is greater than the trigger threshold, an orchestration trigger instruction is generated, which includes the trigger event identifier, the service name sequence, interface name sequence, and time interval sequence in the reconstructed causal chain; if the causal chain confidence value is not greater than the trigger threshold or the triggered event is marked as a causal undetermined event, the triggered event is written to the delayed confirmation queue; for the reconstructed causal chain for which an orchestration trigger instruction has been generated, a link signature value is generated, which is calculated by combining the service name sequence, interface name sequence, time interval sequence, and message content fingerprint in the reconstructed causal chain using consistent encoding; the link signature value is matched with historical link signature values ​​in the event link monitoring database; if the same link signature value exists, it is determined as a duplicate trigger and the current orchestration trigger instruction is suppressed; if the same link signature value does not exist, the link signature value is written to the event link monitoring database, and the corresponding orchestration trigger instruction is executed.

[0018] Furthermore, the specific process of extracting original and reconstructed statistical results based on multi-source link data and reconstructed causal chains, and combining the original and reconstructed statistical results to determine the offset is as follows: For all triggered events within the sliding time window, call tracing data, runtime log data, and reconstructed causal chains are obtained respectively; the original statistical latency distribution is obtained based on the execution duration statistics in the call tracing data; the reconstructed statistical latency distribution is obtained based on the execution duration statistics recorded in the call tracing data in the reconstructed causal chain; the original error rate is obtained by calculating the proportion of abnormal states based on the status markers in the call tracing data; the reconstructed error rate is obtained by calculating the proportion of abnormal states based on the status markers recorded in the call tracing data in the reconstructed causal chain; and the reconstructed error rate is obtained by calculating the proportion of abnormal states based on the abnormal type statistics in the runtime log data. The original number of alarms is obtained; the reconstructed number of alarms is obtained based on the anomaly type statistics of the reconstructed causal chain within the time interval sequence; the JS divergence between the original statistical delay distribution and the reconstructed statistical delay distribution is calculated to obtain the delay distribution difference value; the error rate difference is obtained by subtracting the reconstructed error rate from the original error rate, and then squared after dividing the error rate difference by the sum of the reconstructed error rate and the smallest positive number to obtain the normalized difference square term of the error rate; the alarm number difference is obtained by subtracting the reconstructed alarm number from the original number of alarms, and then squared after dividing the alarm number difference by the sum of the reconstructed alarm number and the smallest positive number to obtain the normalized difference square term of the alarm number; the delay distribution difference value, the normalized difference square term of the error rate, and the normalized difference square term of the alarm number are added together and then square rooted to obtain the monitoring caliber offset value.

[0019] Furthermore, the specific process of identifying statistical caliber offsets based on the judgment results and performing monitoring caliber correction and threshold adaptive adjustment is as follows: When the monitoring caliber offset value is less than the offset threshold, the statistical caliber is determined to be aligned; the reconstructed statistical delay distribution, reconstruction error rate, and reconstruction alarm number are used as the official display caliber for the running link monitoring, and the current trigger threshold and association threshold remain unchanged; when the monitoring caliber offset value is greater than the offset threshold, it is determined that there is a statistical offset between the original statistical caliber and the reconstructed statistical caliber, and a statistical caliber offset prompt message is generated. The reconstructed statistical delay distribution, reconstruction error rate, and reconstruction alarm number are written as the priority monitoring caliber into the event link monitoring database, and the original statistical results are replaced in the monitoring display layer; the causal chain confidence value distribution, candidate association consistency value distribution, and monitoring caliber offset value in the current window are recorded together as caliber calibration samples, and the trigger threshold and association threshold are adjusted.

[0020] Beneficial effects

[0021] The present invention has the following beneficial effects:

[0022] (1) This invention constructs event fingerprint features by fusing multi-source link data, and conducts comprehensive correlation evaluation by combining content matching, temporal rationality and topology reachability. Then, it introduces link consistency aggregation and reuse conflict identification mechanism to perform reliability screening and conflict correction on candidate causal chains. It can stably restore the real causal chain structure in scenarios of instance scaling, asynchronous delivery and retry concurrency, and improve the link restoration accuracy.

[0023] (2) The present invention makes orchestration triggering decisions based on causal chain confidence and matches historical signatures through a link signature identification mechanism to achieve repeated triggering suppression and idempotent control, effectively avoiding the same triggering event being mistakenly merged or repeatedly triggered, and improving the determinism of event orchestration and execution consistency.

[0024] (3) This invention evaluates the distribution difference and determines the offset between the original statistical results and the reconstructed statistical results, identifies the statistical offset problem caused by the label distortion or link mis-merging, and prioritizes the use of the reconstructed statistical results for display and recording when the offset is detected, thereby improving the credibility of the running link monitoring indicators and the stability of cross-version and cross-environment comparison.

[0025] (4) This invention dynamically adjusts the trigger threshold and association threshold by recording calibration samples such as the causal chain confidence distribution, candidate association consistency distribution and monitoring caliber offset value, so as to maintain stable performance under different load scales and topology changes, and realize the adaptive optimization of association evaluation and orchestration control strategy.

[0026] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0027] Figure 1 Structure diagram of an intelligent event orchestration, triggering, and runtime monitoring system for distributed systems;

[0028] Figure 2 A distribution chart of confidence scores for causal chains;

[0029] Figure 3 A schematic diagram of a weighted directed graph for candidate association consistency. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. As those skilled in the art will understand, 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 are within the scope of protection of the present invention.

[0031] Please see Figures 1-3 This invention provides a technical solution: an intelligent event orchestration triggering and runtime link monitoring system for distributed systems, such as... Figure 1 As shown, the system includes: a link data acquisition and processing module, used to acquire multi-source link data in real time, perform time alignment, fingerprint normalization, and association construction on the multi-source link data to form a unified event link data foundation; an event candidate association generation module, used to extract trigger events and execution events within a sliding time window, construct event fingerprint features based on multi-source link data, and combine event fingerprint features to evaluate the degree of content matching, temporal rationality, and topological reachability, and generate candidate association structures based on the association evaluation results; a causal chain reconstruction module, used to perform path expansion and causal reconstruction based on the candidate association structures, and use the association evaluation results to analyze the consistency aggregation and reuse conflicts of the reconstructed links, identify the reliability of causal reconstruction, screen the reconstructed causal chains based on reliability, and complete conflict correction; an orchestration trigger control module, used to trigger orchestration decisions based on the reconstructed causal chains and reliability, and combine link signature recognition to achieve duplication suppression and idempotent control; and a link trust evaluation module, used to extract original statistical results and reconstructed statistical results based on multi-source link data and reconstructed causal chains, combine the original statistical results and reconstructed statistical results to determine the offset, identify the statistical caliber offset based on the determination results, and perform monitoring caliber correction and threshold adaptive adjustment.

[0032] Specifically, the process of real-time collection of multi-source link data, followed by time alignment, fingerprint normalization, and association construction to form a unified event link data foundation, is as follows: Real-time collection of message delivery data, call tracing data, runtime log data, and instance runtime data generated during the operation of the distributed system. Real-time collection is achieved by deploying link probe components, log collection agents, and message middleware interception plugins in each microservice instance. Message delivery data is collected by the message middleware interception plugin based on message queue client callbacks through message delivery event listening. Call tracing data is collected by the link probe component based on HTTP / gRPC interceptors through call tracking. Runtime log data is collected by the log collection agent based on the log framework Appender for structured log output. Instance runtime data is collected by the link probe component or the instance metadata interface of the container orchestration platform. All collected data is written to a streaming data channel through a unified data access gateway, preferably using a message queue for buffering and transmission to ensure data integrity and ordering in high-concurrency scenarios. Message delivery data includes: message identifier, topic name, production time, consumption time, delivery count, retries count, consumer group name, and message content fingerprint; call tracing data includes: tracing identifier, span identifier, parent span identifier, service name, interface name, start time, end time, execution duration, and status flag; runtime log data includes: log time, log template fingerprint, exception type, and exception stack fingerprint; instance runtime data includes: instance identifier, version identifier, and instance creation time; the call tracing data, runtime log data, message delivery data, and instance runtime data are converted to system standard time and time-aligned; the system standard time preferably uses UTC timestamps, and the time alignment process includes format parsing, time zone conversion, and timestamp-based sorting and rearranging of time fields from each data source, and using a sliding time window mechanism to aggregate cross-source data within a window, thereby eliminating the impact of system time deviations from different nodes on link analysis.The log template fingerprint and exception stack are fingerprinted and normalized. The log template fingerprint is generated by hashing the log text after replacing variable placeholders. The exception stack fingerprint is generated by standardizing the stack hierarchy after removing line numbers and dynamic paths, ensuring that similar exceptions have consistent identifiers across different instances or versions. Fingerprint normalization refers to standardizing the original text or structured data according to rules to generate a fixed-length deterministic identifier value. The identifier value is preferably a fixed-length hash value, preferably using SHA-256, MD5, or other deterministic digest algorithms, with the output format being a hexadecimal string or an unsigned integer. Variable placeholder replacement rules include uniformly replacing timestamps, values, IP addresses, UUIDs, file paths, and dynamic parameters with preset placeholder markers to eliminate the impact of instance differences. Exception stack standardization encoding involves extracting the class name, method name, and exception type fields according to the call hierarchy, removing line numbers and absolute paths, concatenating them into a structured string, and then performing hashing to generate the exception stack fingerprint. Consistent encoding is performed on the message content fingerprint. A fixed-length hash algorithm is preferred for digest encoding of key fields in the message body. Before encoding, field sorting and null value standardization are performed to eliminate format differences across different data collection terminals. Consistent encoding refers to generating a unique digest identifier after performing deterministic normalization on the structured message body. Specifically, this includes: sorting JSON or key-value structures lexicographically by field name, using a unified character encoding of UTF-8, representing null values ​​as preset null placeholders, removing irrelevant or configurable dynamic fields, and then performing a fixed-length hash algorithm on the normalized string to generate a digest value. The generated message content fingerprint is a fixed-length hash result used to maintain consistent identification across different nodes, languages, or serialization methods. The message event is determined based on the number of deliveries and retries, marking it as a new trigger or a duplicate delivery. Specifically, if the number of deliveries exceeds the preset initial number of deliveries or the number of retries is greater than zero, it is marked as a duplicate delivery event; otherwise, it is marked as a new trigger event, and the marked field is written into the subsequent correlation analysis process. The call tracing data is used to construct call associations based on tracing identifiers, span identifiers, and parent span identifiers. A tree structure is built with span identifiers as nodes and parent span identifiers as directed edges to restore the parent-child call relationships within a single call chain. Message delivery data is used to construct delivery associations based on message identifiers and consumer group names. By matching production and consumption records of the same message identifier in different consumer groups, a cross-service message propagation path is formed. Call relationship graphs and delivery relationship graphs are generated based on the call associations and delivery relationship graphs, respectively. Both graphs are stored using directed graph data structures, with nodes containing event identifiers and time attributes, and edges containing call or delivery direction and association attributes. An event chain monitoring database is established to store raw and preprocessed call tracing data, runtime log data, message delivery data, and instance runtime data.The event link monitoring database preferably supports graph structure storage and index query capabilities, enabling fast retrieval based on tracking identifiers, message identifiers, or time ranges to support subsequent candidate association generation and causal chain reconstruction, thereby ensuring that the overall system has feasible engineering implementation and scalability.

[0033] This implementation scheme achieves structured collection and unified access of multi-source link data by deploying link probes, log brokers, and message interception plugins on the microservice instance side. It also eliminates interference caused by cross-node time deviations and format differences through UTC time standardization, sliding window alignment, and fingerprint normalization encoding mechanisms. At the same time, it constructs call relationship graphs and delivery relationship graphs based on tracking identifiers and message identifiers respectively, forming a unified directed graph event link foundation. Combined with a monitoring database with graph structure storage and indexing capabilities, it achieves efficient retrieval and expansion support, thereby improving the consistency, relevance, and traceability of link data in a distributed environment, and providing a reliable data foundation for subsequent causal reconstruction and orchestration control.

[0034] Specifically, the process of extracting trigger events and execution events within a sliding time window and constructing event fingerprint features based on multi-source link data is as follows: The set of trigger events and the set of execution events within the sliding time window are extracted using call tracing data and message delivery data. The sliding time window is a time interval that is updated on a rolling basis according to a preset time length. The window length is adaptively set based on the historical time difference statistics from trigger events to downstream execution events in the distributed system, preferably between 5 and 300 seconds, and the window is divided using the system's standard timestamp as the boundary. A trigger event is defined as an external request entry event or a newly triggered message production event generated at the beginning of the window. An execution event is defined as a downstream service call event or message consumption event triggered by the trigger event. Both are determined through filtering using time and event type fields. The specific method for extracting the trigger event set and execution event set from call tracing data is as follows: Call tracing records whose start time falls within the sliding time window are filtered, and their service name, interface name, span identifier, and parent span identifier are read. Call tracing records with an empty parent span identifier or whose parent span identifier does not appear in the window are identified as external request entry events and written into the trigger event set. Call tracing records with a parent span identifier present in the window are identified as downstream service call events and written into the execution event set. When a call tracing record is marked as abnormal, the corresponding log template fingerprint and exception stack fingerprint are simultaneously retained for subsequent event fingerprint construction. Furthermore, the specific method for extracting the trigger event set and execution event set using message delivery data is as follows: Within a sliding time window, message delivery records whose production time falls within the window range and message delivery records whose consumption time falls within the window range are filtered respectively; message delivery records whose production time falls within the window range and whose retry count is zero are determined as newly triggered message production events and written into the trigger event set; message delivery records whose consumption time falls within the window range are determined as message consumption events and written into the execution event set; when the delivery count is greater than the preset initial delivery count or the retry count is greater than zero, the corresponding message delivery record is marked as a duplicate delivery event and the marking field is retained. Further, an event identifier is generated for each event in the trigger event set and execution event set. The event identifier is preferably a combination of a tracking identifier and a span identifier, or a combination of a message identifier and a consumer group name, and is used for the subsequent storage and retrieval of candidate related edges.For any triggering event and execution event, obtain the corresponding interface name code, topic name code, log template fingerprint, exception stack fingerprint, and message content fingerprint, and construct event fingerprint vectors for each. The interface name code and topic name code are obtained by uniformly encoding and mapping the interface path and topic name. The log template fingerprint and exception stack fingerprint are derived from normalized log data fields, and the message content fingerprint is derived from the result of summarizing and encoding the key fields of the message body. The interface name code and topic name code preferably use a deterministic discrete mapping method to generate fixed-dimensional numerical representations. Mapping methods include, but are not limited to: integer ID mapping based on a global encoding dictionary, discrete vector representation based on a One-Hot method, or low-dimensional embedded vector representation based on a preset dimension. When using an integer ID mapping method, it is preferable to normalize the encoded value to map it to the 0-1 range. When using a One-Hot method or an embedded method, the encoding dimension is predetermined during the initialization phase and remains globally consistent. The event fingerprint vector preferably adopts a fixed-length vector structure. The above encoding results are concatenated according to a preset dimensional order. Each component is concatenated in the order of "interface name encoding, topic name encoding, log template fingerprint encoding, exception stack fingerprint encoding, and message content fingerprint encoding" to form a unified structure. Before vector construction, missing field imputation and null value standardization are performed to ensure comparability between events from different sources. Missing fields of different event types are filled with zero values ​​to ensure constant vector dimensions. Each encoded component is numerically standardized before concatenation, preferably using linear normalization to ensure that the values ​​of each dimension are within a uniform scale range. Each component participates in the dot product and modulus calculations with equal weight by default in the vector space, thus ensuring that subsequent vector dot product and modulus operations have clear numerical premises. When an event does not contain a certain field, the corresponding dimension is filled with a zero vector to ensure consistency in dimensional structure between different events and to avoid uncertain impacts on similarity calculations. The system synchronously records the occurrence time, execution duration, instance identifier, service name, and number of retries for each event. The occurrence time is determined by the event type, taking the start time from the call tracing data or the production and consumption times from the message delivery data. The execution duration is derived from the execution duration field in the call tracing data. The instance identifier and service name are used to distinguish different deployment instances and service nodes. The number of retries is derived from the retry count field in the message delivery data. The above recorded information, along with the event fingerprint vector, is written into the event link monitoring database for subsequent candidate association generation and causal chain reconstruction processes. This ensures that the event feature construction process has a clear data source, processing path, and storage method, and has feasible engineering implementation capabilities.

[0035] In this implementation scheme, a sliding time window mechanism is used to perform structured filtering of call tracking data and message delivery data. Based on quantifiable fields such as parent span identifier, production time, and consumption time, the triggering event and execution event are accurately extracted. A unified event identifier generation rule is used to ensure the uniqueness and retrieval of events. At the same time, a fixed-length event fingerprint vector is constructed by combining interface name encoding, topic name encoding, and multiple fingerprint features. It is also recorded and stored synchronously with runtime attributes such as time, execution duration, and number of retries. This achieves standardized representation and enhanced comparability of events across data sources, providing a stable, consistent, and engineering-practical data foundation for subsequent candidate association evaluation and causal chain reconstruction, and improving the accuracy and reliability of event orchestration and link analysis in a distributed environment.

[0036] Specifically, the process of evaluating content matching degree, temporal rationality, and topological reachability based on event fingerprint features is as follows: The event fingerprint vectors of the triggering event and the execution event are multiplied by a vector dot product to obtain the numerator. The magnitudes of the two event fingerprint vectors are calculated separately, multiplied, and then added to a minimum positive number to obtain the denominator. The ratio of the numerator to the denominator is calculated to obtain the content fingerprint similarity value. Here, the event fingerprint vector is a numerical vector after fixed-length mapping, and the values ​​of each dimension are derived from the numerical results of interface name encoding, topic name encoding, and multiple fingerprint fields. The vector dot product is used to characterize the directional consistency of the two events in the multi-dimensional feature space. The magnitude multiplication is used for normalization to eliminate the influence of different vector lengths on similarity. The minimum positive number is used to avoid numerical instability when the denominator is zero. The time difference is obtained by subtracting the occurrence time of the triggering event from the occurrence time of the execution event. The occurrence time is uniformly represented by the system's standard timestamp. When the time difference is negative, it is directly judged as temporal inconsistency, and the corresponding candidate association consistency value is set to zero. The link category is determined by a combination of the service name, interface name, and topic name of the triggering event. A historical time difference set of similar links is retrieved from the event link monitoring database. The median of the time difference is used as the latency reference value, and the median absolute deviation of the time difference is calculated as the median absolute deviation of the latency. The historical time difference set is a sample set of time differences in confirmed causal chains within a preset historical time range. The median is used to characterize the typical propagation latency level, and the median absolute deviation is used to characterize the latency fluctuation amplitude, thus avoiding outliers from significantly affecting the statistical results. The absolute difference between the current time difference and the latency reference value is calculated and divided by the sum of the median absolute deviation of the latency and a very small positive number to obtain the latency deviation. A negative exponentiation of the latency deviation yields the latency reachability probability value. The negative exponentiation is used to map the deviation to a probability range between zero and one, so that the closer the time difference is to the historical typical value, the closer the probability is to one; the larger the time difference deviation, the faster the probability decays. By combining the call relationship graph and the delivery relationship graph, the shortest path hop count from the service to which the triggering event belongs to the service to which the execution event belongs is calculated using breadth-first search. The shortest path hop count is added to one and the reciprocal is taken to obtain the topology reachability value. This method allows direct call relationships to obtain higher topology reachability values, while multi-level propagation relationships decrease according to the hop count, thus reflecting the structural proximity between services. If no reachable path exists, the topology reachability value is set to zero. The candidate association consistency value is obtained by multiplying the content fingerprint similarity value, the latency reachability probability value, and the topology reachability value, adding a very small positive number, and taking the cube root.The candidate association consistency value comprehensively measures the strength of association between events from three independent but jointly constrained dimensions: content matching, temporal rationality, and topological reachability. Among them, the multiplication operation is used to reflect the synergistic constraint relationship of the three factors, that is, when any factor decreases significantly, the overall consistency decreases synchronously. The cube root operation is used to scale the product result to avoid excessive compression of the numerical value due to extreme values ​​in a single dimension. The final candidate association consistency value is between zero and one, which is used for subsequent candidate association edge screening and causal chain reconstruction.

[0037] The specific formula for the candidate association consistency value is as follows:

[0038] ;

[0039] In the formula, The candidate association consistency value is represented by a comprehensive measure of the causal relationship between the triggering event and the execution event, which is achieved by integrating three factors: content matching strength, time propagation rationality, and topological reachability. Indicates the index of the event that triggered it; Indicates the execution event index; This represents the event fingerprint vector that triggered the event; An event fingerprint vector representing an execution event; This represents the magnitude of the event fingerprint vector. This represents the magnitude of the execution event fingerprint vector. The vector magnitude is used for normalization to ensure a stable similarity range. Indicates the time when the execution event occurred; Indicates the time when the triggering event occurred; This represents the time delay reference value, indicating the "normal propagation time delay center," used to establish a reasonable time expectation; It represents the absolute deviation of the median delay, and the tolerance for time fluctuations, used to control the intensity of the delay deviation penalty; This represents the number of hops in the shortest path, used to measure the distance of topology propagation; Represents extremely small positive numbers, used for numerical stability protection; a value of [value to be filled in] is recommended. .

[0040] In this implementation plan, robust association determination under multi-dimensional features is achieved by uniformly normalizing and co-constraining the similarity of event fingerprints, the rationality of time differences, and the reachability of service topology. The influence of abnormal samples is suppressed by using the historical statistical median and median absolute deviation, and the numerical stability is enhanced by exponential mapping and scaling smoothing. This enables the candidate association consistency value to accurately distinguish between real causal associations and accidental co-occurrence relationships in a dynamic distributed environment, thereby improving the accuracy, robustness, and engineering feasibility of candidate association selection.

[0041] Specifically, the process of generating candidate association structures based on association evaluation results is as follows: Calculate the candidate association consistency value between all pairs of trigger events and execution events within the sliding time window, forming a set of candidate association edges, stored as triplets of trigger event identifier, execution event identifier, and candidate association consistency value. The trigger event identifier and execution event identifier are unique event identifiers generated during the event fingerprint construction phase, used for indexing and retrieval in the database. The candidate association consistency value originates from the association evaluation results of the previous stage, with a value range between zero and one. The pairwise calculation process preferably employs a batch vectorized parallel computing method to ensure computational efficiency and scalability in high-concurrency scenarios. For candidate association edges corresponding to the same trigger event and execution event, sort them in descending order of candidate association consistency value, retaining only those candidate association edges with a consistency value greater than the association threshold. The association threshold is preferably set based on historical sample distribution and can be dynamically adjusted to balance the risks of false associations and missed associations. All candidate association edges are aggregated to construct a candidate association graph, with events as nodes, candidate association edges as directed edges, and the candidate association consistency value as the edge weight, which is then written into the event link monitoring database. The candidate association graph is preferably stored using a directed weighted graph data structure. Node attributes include event identifier, occurrence time, and service name, while edge attributes include candidate association consistency value and time difference auxiliary field. This provides a structured graph data foundation for subsequent causal chain path expansion, thereby ensuring that the candidate association structure generation process has a clear data source, calculation logic, and storage path, and has feasible engineering implementation capabilities.

[0042] like Figure 3The diagram shows a weighted directed graph of candidate association consistency. It illustrates the candidate association structure between triggering events and execution events within a sliding time window. Events are represented as nodes, with triggering events (T1, T2, and T3) on the left and execution events (E1 to E7) in the middle and right. Directed edges represent candidate associations, with the direction of the edges indicating the extension from the triggering event to the downstream execution event. The values ​​labeled on the edges are candidate association consistency values, used to characterize the association strength between two events under the combined effects of content fingerprint similarity, temporal rationality, and topological reachability. As shown in the graph, triggering event T1 forms candidate associations of varying strengths with E1, E2, and E3. The candidate association consistency value from T1 to E1 is the highest, indicating the optimal matching degree in multi-dimensional features. T2 has a strong association with E2 and E4, demonstrating that the same trigger may generate multiple candidate downstream paths. The candidate association consistency value between T3 and E3 is 0.90, indicating a high degree of confidence in the direct association. Some execution events continue to extend downstream, such as E1, E2, E3, and E4 pointing to E6 or E7, forming multi-level candidate paths and providing a structural foundation for subsequent causal chain reconstruction. Overall, the graph intuitively presents the core structural features of the candidate association graph: "nodes are events, edges are candidate associations, and edge weights are consistency values," providing a visual basis for subsequent path search, causal chain reconstruction, and confidence assessment.

[0043] In this implementation scheme, by performing a full pairwise evaluation of all events within the sliding time window and constructing a directed weighted candidate association graph, a unified candidate association expression basis is formed at the structural level. Through consistency value sorting and threshold screening mechanisms, low-confidence association edges are effectively suppressed, reducing the risk of false associations. At the same time, a standardized triplet storage and graph structure writing method is adopted to ensure that the data is indexable, scalable, and traceable. This provides a high-quality, computable, and implementable structured association basis for subsequent causal chain reconstruction and orchestration triggering decisions, improving the accuracy of link reconstruction and overall stability.

[0044] Specifically, based on the candidate association structure, path expansion and causal reconstruction are performed. The association evaluation results are used to analyze the consistency aggregation and reuse conflicts of the reconstructed links. The specific process for identifying the reliability of causal reconstruction is as follows: All candidate association edges and their corresponding candidate association consistency values ​​within the sliding time window are extracted from the candidate association graph. The candidate association graph is stored in the event link monitoring database with event identifiers as nodes and candidate association consistency values ​​as edge weights. The extraction process is achieved through joint filtering using the time window index and the trigger event index to ensure that the calculation scope is limited to the data set within the current analysis window. Based on directed graph path search, starting from the trigger event, events are progressively expanded downstream along the candidate association edges to generate a set of candidate causal chains. The path search preferably uses a breadth-first search algorithm with a maximum path length constraint. If nodes are repeated in the path, the expansion is terminated to avoid exponential path expansion in high-concurrency scenarios. The set of candidate association edges and the corresponding sequence of candidate association consistency values ​​contained in each candidate causal chain are obtained. For each candidate causal chain, a minimum positive number is added to the candidate association consistency value of each candidate association edge in the candidate causal chain, and then the natural logarithm is taken to obtain the logarithmic consistency value. The minimum positive number is used to avoid the numerical anomaly where the logarithm cannot be calculated when the consistency value is zero. The logarithmic consistency values ​​of all candidate association edges in the candidate causal chain are summed and divided by the number of candidate association edges to obtain the average logarithmic consistency value. The natural exponential operation is performed on the average logarithmic consistency value to obtain the link consistency aggregation value. The above process is equivalent to performing a smooth aggregation of candidate association consistency values ​​in the form of geometric mean, which is used to suppress the excessive impact of abnormal fluctuations of a single edge on the overall link strength, so that the aggregation result is kept between zero and one and has comparability. For all call tracing data records in the same candidate causal chain, the corresponding tracing identifier, message identifier, start time, and end time are read. Pairs of records with the same tracing identifier or message identifier are then selected. This selection process is implemented by building a hash index in the database based on the tracing identifier or message identifier to ensure rapid location of records with the same identifier even under large-scale data conditions. Using the start and end times of the call tracing data records as time intervals, the intersection length and union length of the two time intervals in each record pair are calculated. The intersection length is the duration of the overlapping portion of the two time intervals, and the union length is the length of the overlap portion of the two time intervals. The total duration of the coverage area is calculated by dividing the intersection length by the sum of the union length and the smallest positive number to obtain the time overlap ratio of the record pairs. The maximum time overlap ratio among all record pairs is taken as the reuse conflict degree value. The maximum value is used to characterize the most severe identifier reuse conflict situation, thereby amplifying the risk identification of potential identifier reuse or concurrent overlap problems in the link. The causal chain confidence value is obtained by subtracting the reuse conflict degree value from one and multiplying it by the link consistency aggregation value. This allows the confidence value to be closer to one when the link consistency is higher and the reuse conflict is lower, while the confidence value decreases significantly when the conflict degree increases. This enables the quantitative judgment of the reliability of the causal chain and the screening basis for engineering feasibility.The causal chain confidence value simultaneously characterizes the comprehensive reliability of the link structure consistency and the risk of identifier reuse conflicts. Specifically, the link consistency aggregation value reflects the overall stability of each associated edge in the candidate causal chain in terms of content matching, temporal rationality, and topological reachability; the reuse conflict value characterizes the degree of abnormal overlap of the same tracking identifier or message identifier within a time interval, thereby enhancing "strongly consistent and low-conflict" links and penalizing links that are "structurally strong but have reuse conflict risks." This embodies a two-factor constraint mechanism of positive consistency enhancement and negative conflict suppression, enabling the causal chain confidence value to serve as a unified quantitative criterion for whether a causal chain can be reliably reconstructed.

[0045] The specific formula for the causal chain confidence value is as follows:

[0046] ;

[0047] In the formula, This represents the confidence value of the causal chain, used to assess the overall credibility of a candidate causal chain, and characterizes the reliability to which the candidate causal chain is considered to be true. This indicates the number of candidate related edges, representing the number of candidate related edges contained in the current candidate causal chain. It is used to average the aggregation process of edges within the chain, making chains of different lengths comparable. This represents the candidate association consistency value, used to characterize the degree of credibility of the association between the triggering event and the execution event corresponding to the edge; Indicates the candidate associated edge index; The value represents the degree of conflict, which is used to characterize the degree of unreasonable time overlap that occurs within the candidate causal chain under the same tracking identifier or the same message identifier. The larger the value, the more severe the conflict. Represents extremely small positive numbers, used for numerical stability protection; a value of [value to be filled in] is recommended. .

[0048] In this embodiment, Table 1 is a data table of causal chain confidence values. The table details the number of candidate edges, candidate consistency value sequence, link consistency aggregation value, reuse conflict degree value, and causal chain confidence value for five candidate causal chains triggering the same event. Specifically, candidate causal chain 1 has 4 candidate edges, a candidate consistency value sequence of 0.92, 0.88, 0.90, and 0.86, a link consistency aggregation value of 0.8897, a reuse conflict degree of 0.05, and a causal chain confidence value of 0.8452; candidate causal chain 2 has 3 candidate edges, a candidate consistency value sequence of 0.65, 0.72, and 0.68, a link consistency aggregation value of 0.6827, a reuse conflict degree of 0.10, and a causal chain confidence value of 0.6145; and candidate causal chain 3 has 5 candidate edges. The candidate association consistency value sequence is 0.90, 0.87, 0.85, 0.88, 0.83, the link consistency aggregation value is 0.8657, the reuse conflict degree is 0.35, and the causal chain confidence value is 0.5627; the candidate association edge number of candidate causal chain 4 is 4, the candidate association consistency value sequence is 0.40, 0.52, 0.45, 0.48, the link consistency aggregation value is 0.4604, the reuse conflict degree is 0.08, and the causal chain confidence value is 0.4236; the candidate association edge number of candidate causal chain 5 is 4, the candidate association consistency value sequence is 0.78, 0.70, 0.74, 0.69, the link consistency aggregation value is 0.7266, the reuse conflict degree is 0.55, and the causal chain confidence value is 0.3270.

[0049] Table 1. Causal Chain Confidence Values ​​Data Table

[0050]

[0051] like Figure 2 The figure shows the distribution of confidence scores for causal chains. The horizontal axis represents the candidate causal chain number, and the vertical axis represents the corresponding confidence score. Each bar corresponds to the final confidence score calculation result of a candidate causal chain, with the value labeled at the top of the bar for easy comparison of the overall confidence level of different candidate chains. (See Table 1 and...) Figure 2It can be seen that the causal chain confidence value and the link consistency aggregation value show a positive correlation trend. Candidate causal chains 1 and 3, with higher link consistency aggregation values, generally have higher confidence levels. The reuse conflict value has a significant inhibitory effect on the final causal chain confidence value. For example, although candidate causal chain 5 has a link consistency aggregation value of 0.7266, its final confidence value drops significantly to 0.3270 due to its high reuse conflict value of 0.55, demonstrating the effectiveness of the conflict penalty mechanism. When link consistency aggregation values ​​are similar, differences in reuse conflict values ​​can widen the confidence gap. For example, the link consistency aggregation values ​​of candidate causal chain 3 and candidate causal chain 2 are not significantly different, but candidate causal chain 3 has a higher reuse conflict value, resulting in a lower confidence value than candidate causal chain 2. The causal chain confidence value comprehensively reflects the impact of two dimensions: "association consistency level" and "internal time reuse conflict degree." It is a stable and comparable overall reliability indicator that can be used for main chain screening and conflict chain elimination decisions. In summary, it can be verified that the causal chain confidence value can effectively distinguish the true credibility of different candidate chains and significantly suppress highly conflicting chains, thereby supporting the reliability judgment of subsequent orchestration triggering decisions.

[0052] In this implementation scheme, controlled path expansion based on the candidate association structure is used to achieve orderly reconstruction of multi-hop event links. The link consistency aggregation in the form of geometric mean is used to suppress the interference of a single abnormal edge on the overall judgment. At the same time, a reuse conflict degree identification mechanism based on time interval overlap is introduced to amplify the constraint on the risk of identifier reuse or concurrent overlap. Finally, a causal chain confidence criterion that takes into account both structural stability and conflict risk is formed, so that the causal chain screening process has numerical stability, anti-anomaly ability and engineering feasibility, thereby improving the accuracy and reliability of link reconstruction.

[0053] Specifically, the process of reconstructing causal chains and correcting conflicts based on reliability screening is as follows: Calculate the causal chain confidence value corresponding to all candidate causal chains in the candidate association graph. The causal chain confidence value is calculated by combining the link consistency aggregation value and the reuse conflict value, with a value range between zero and one, and has been uniformly written into the event link monitoring database for sorting and retrieval. For the same triggering event, the candidate causal chains are sorted in descending order according to the causal chain confidence value, and candidate causal chains with a causal chain confidence value greater than the confidence threshold are retained as preferred causal chains. The confidence threshold is a configurable parameter that can be dynamically adjusted according to historical statistical distribution to adapt to the accuracy requirements under different business scenarios. If there are more than one preferred causal chain for the same triggering event, the preferred causal chain with the highest confidence value is taken as the main chain, and the remaining preferred causal chains are marked as conflict chains. The main chain represents the candidate path with the most structural stability and low conflict characteristics within the current window, and is used to represent the final reconstruction result of the triggering event. For conflict chains, if the included call tracing data records overlap with the main chain in terms of time interval, the call tracing data records overlapping with the main chain in the conflict chain are deleted. The determination of time interval overlap is based on whether the start time and end time of the call tracing data records intersect. If the intersection length is greater than zero, it is considered as overlapping, and the causal chain confidence value is recalculated. If the recalculated value is... If the confidence value of the causal chain is still greater than the confidence threshold, the conflict chain is retained as a split chain. The split chain is used to characterize the independent sub-paths formed by the same triggering event in concurrent or branch execution scenarios; otherwise, it is discarded. The main chain corresponding to the triggering event is used as the reconstructed causal chain, and the link structure, causal chain confidence value, and related statistical fields are written into the event link monitoring database for subsequent orchestration triggering and monitoring evaluation. If there is no candidate causal chain with a causal chain confidence value greater than the confidence threshold, the causal chain of the triggering event is determined to be unreliable and marked as a causal undetermined event. Causal undetermined events will be recorded and can enter the delayed confirmation process, thereby ensuring robustness and traceability in uncertain scenarios.

[0054] In this implementation scheme, a reliability determination mechanism centered on structural consistency and conflict suppression is established by uniformly ranking candidate causal chains with confidence levels and screening with thresholds. When multiple candidate paths exist for the same triggering event, the optimal main chain can be automatically identified and conflicting chains can be split or eliminated, thereby effectively avoiding erroneous merging and splitting problems. At the same time, when the confidence level is insufficient, an undetermined causal result is output, ensuring the robustness and traceability of the system in uncertain scenarios, and improving the accuracy, consistency and engineering feasibility of causal chain reconstruction as a whole.

[0055] Specifically, the orchestration decision-making process, based on reconstructing causal chains and reliability, and combined with link signature recognition to achieve duplication suppression and idempotency control, is as follows: The reconstructed causal chains and their confidence values ​​corresponding to all triggered events within the sliding time window are read. This reading process retrieves the corresponding reconstructed causal chain structure and its confidence result from the event link monitoring database through an index query based on the triggered event identifier, limiting the data set to the current time window range to avoid cross-window data interference. For each triggered event, if the causal chain confidence value is greater than the trigger threshold, an orchestration trigger instruction is generated. The trigger threshold is a reliability judgment threshold, which can be dynamically configured based on the historical distribution of causal chain confidence values ​​to ensure that orchestration actions are performed only on highly reliable causal chains. The orchestration trigger instruction includes the trigger event identifier, the service name sequence in the reconstructed causal chain, the interface name sequence, and the time... The time interval sequence, where the service name sequence and interface name sequence are arranged in the topological order of the causal chain, and the time interval sequence is the start time and end time interval of the corresponding call tracing record, is used for order constraints and range verification during the execution phase; if the causal chain confidence value is not greater than the trigger threshold or the trigger event is marked as a causal undetermined event, the trigger event is written to the delayed confirmation queue. The delayed confirmation queue preferably adopts an ordered queue structure based on time priority, and a re-evaluation time interval is set to re-evaluate the causal chain confidence value in subsequent windows, thereby avoiding false triggers or missed triggers due to instantaneous data fluctuations; the trigger condition for re-determination is preferably to automatically trigger re-evaluation after the sliding time window completes one update, and the re-evaluation time interval is preferably the same as or an integer multiple of the length of the sliding time window to ensure that the evaluation rhythm is consistent with the link analysis rhythm. For the reconstructed causal chain with generated orchestration trigger instructions, a link signature value is generated. The link signature value is calculated by combining the service name sequence, interface name sequence, time interval sequence, and message content fingerprint in the reconstructed causal chain and performing consistent encoding. The consistent encoding is a deterministic fixed-length hash encoding function, preferably SHA-256 or other fixed-length digest algorithms. The above fields are sorted according to the causal chain time order and then concatenated in a preset order to form a standard string representation. The fields are connected by a fixed delimiter. Before concatenation, the fields are standardized, including uniform character encoding to UTF-8, uniform uppercase and lowercase format, and removal of leading and trailing spaces. The time interval sequence is normalized according to a preset quantization granularity, preferably using millisecond-level timestamps and rounded down to a uniform time precision. This ensures that the reconstructed causal chain with the same structure generates a consistent link signature value in different instances or deployment environments, achieving stable suppression of repeated triggering and idempotent control.The link signature value is matched with historical link signature values ​​in the event link monitoring database. The matching process is preferably implemented by establishing a unique index of the link signature value to support fast deduplication and atomicity judgment in high-concurrency scenarios. If the same link signature value exists, it is determined to be a duplicate trigger and the current orchestration trigger command is suppressed. The suppression method includes recording the duplicate trigger log and terminating the current orchestration execution process to achieve idempotent control. If the same link signature value does not exist, the link signature value is written to the event link monitoring database and the corresponding orchestration trigger command is executed. The execution process preferably uses a transaction mechanism to ensure the atomic consistency of signature writing and orchestration execution, thereby avoiding the risk of duplicate execution in abnormal interruption scenarios.

[0056] In this implementation scheme, the causal chain confidence level is used as the triggering basis to achieve accurate orchestration decisions for highly reliable links. At the same time, a link signature mechanism is introduced for unique identification and duplicate suppression. Combined with delayed confirmation and idempotent control strategies, the problems of false triggering, missed triggering and duplicate execution are effectively avoided. While ensuring the accuracy of triggering, the system's execution stability and consistency are improved in high-concurrency, asynchronous retry and dynamic scaling scenarios of instances, thereby enhancing the controllability and engineering reliability of event orchestration.

[0057] Specifically, the process of extracting original and reconstructed statistical results based on multi-source link data and reconstructed causal chains, and then determining the offset by combining the original and reconstructed statistical results, is as follows: For all triggered events within the sliding time window, call tracing data, runtime log data, and reconstructed causal chains are obtained respectively; among them, call tracing data and runtime log data come from the standardized data set in the event link monitoring database after time alignment and normalization, and reconstructed causal chains come from the link results output by the causal chain reconstruction module and which have undergone reliability screening. All three types of data are retrieved by association using the trigger event identifier and time window index to ensure the consistency and traceability of statistical standards. The original statistical latency distribution is obtained based on the execution duration statistics in the call tracing data. The statistics are preferably implemented by constructing a probability density distribution for the execution duration field within the current sliding time window to reflect the temporal characteristics of the overall call behavior. The reconstructed statistical latency distribution is obtained based on the execution duration statistics of the call tracing data records in the reconstructed causal chain. Here, the statistics only filter and summarize the call tracing data records belonging to the reconstructed causal chain path, thus forming a latency distribution from a structured link perspective. The "latency distribution" is preferably constructed using a discrete probability distribution with fixed buckets. The execution duration field is divided into intervals within the sliding time window, with the number of buckets preferably between 10 and 50. The bucket boundaries are determined using equal width or based on historical quantiles. The number of samples in each bucket is counted and normalized by dividing by the total number of samples to form a probability distribution vector. The original statistical latency distribution and the reconstructed statistical latency distribution use the same bucketing rules, and the probability values ​​are smoothed by adding a very small positive number before calculating the JS divergence to avoid logarithmic aberrations. The original error rate is obtained by calculating the proportion of abnormal states based on the status markers in the call tracing data. The abnormal states are preferably determined based on the status marker fields in the call tracing data. Records with status markers of failure, timeout, exception, or non-successful states such as HTTP 5xx are all considered abnormal records. The proportion of abnormal states is obtained by the ratio of the number of abnormal records in the statistics window to the total number of records in the call tracing data, thus ensuring consistent statistical standards and engineering feasibility. The reconstruction error rate is obtained by calculating the proportion of abnormal states based on the status markers of the call tracing data records in the reconstructed causal chain. This calculation also uses a proportional statistical method, but the statistical scope is limited to the set of records within the reconstructed causal chain. The original alarm count is obtained based on the anomaly type statistics in the operation log data, preferably by classifying and counting the anomaly type field within the current time window; the reconstructed alarm count is obtained based on the anomaly type statistics of the reconstructed causal chain within the time interval sequence, that is, only the number of anomaly log records that intersect with the time interval of the reconstructed causal chain are counted; the JS divergence between the original statistical delay distribution and the reconstructed statistical delay distribution is calculated to obtain the delay distribution difference value; the JS divergence is obtained by calculating the symmetric information entropy of the two delay probability distributions, and is used to measure the overall degree of difference between the two statistical distributions, with the value range limited to between zero and one.The error rate difference is obtained by subtracting the reconstruction error rate from the original error rate. This difference is then divided by the sum of the reconstruction error rate and the smallest positive number, and squared to obtain the normalized error rate difference square term. This normalization method eliminates the influence of different error rate magnitudes on the comparison results, with the square operation amplifying significant deviations. Similarly, the alarm number difference is obtained by subtracting the reconstruction alarm number from the original alarm number. This difference is then divided by the sum of the reconstruction alarm number and the smallest positive number, and squared to obtain the alarm number normalized difference square term, which is also used for order-of-magnitude standardization and deviation amplification. Finally, the delay distribution difference, the normalized error rate difference square term, and the alarm number normalized difference square term are added together and square-rooted to obtain the monitoring caliber offset value. This square-root operation comprehensively smooths the multi-dimensional difference terms, keeping the final offset value within an interpretable continuous range. This offset is used for subsequent threshold determination and monitoring caliber adjustment decisions, ensuring that the monitoring and evaluation process has clear data sources, calculation paths, and engineering feasibility. The monitoring caliber offset value quantifies the difference between the "original statistical results" and the "statistical results based on the reconstructed causal chain". It uses a single indicator to characterize the consistency between the two statistical calibers. Essentially, it is a comprehensive deviation intensity indicator that reflects the degree of statistical consistency. It is used to determine whether the original link statistics and the reconstructed link statistics are aligned and to provide a quantitative basis for the correction of the monitoring caliber.

[0058] The specific formula for the monitoring aperture offset value is as follows:

[0059] ;

[0060] In the formula, This represents the monitoring caliber offset value, used to quantify the overall degree of difference between the original statistical caliber and the reconstructed statistical caliber; This represents the original statistical latency distribution, which is the latency probability distribution obtained from the execution time statistics in the call trace data; This represents the reconstructed statistical latency distribution, which is the latency probability distribution obtained by statistically analyzing the execution time of the call tracing data in the reconstructed causal chain. This represents the raw error rate, which is the percentage of abnormal states obtained from the status markers in the call trace data. The refactoring error rate is the percentage of abnormal states obtained by statistically analyzing the status markers of the call tracing data in the refactoring causal chain. This represents the original alarm count, which is the alarm count obtained by statistically analyzing the anomaly types in the runtime log data. This represents the number of reconstruction alarms, which is the alarm count obtained by statistically analyzing the anomaly types in the corresponding time interval of the reconstruction causal chain. Represents extremely small positive numbers, used for numerical stability protection; a value of [value to be filled in] is recommended. .

[0061] In this implementation plan, structured alignment statistics are performed on multi-source link data and reconstructed causal chain data within the same sliding time window. A unified offset metric is constructed from three key operational dimensions: latency distribution, error rate, and alarm count. This enables quantitative determination of the consistency between the original and reconstructed statistical calibers. By combining probability distribution difference measurement with a normalized deviation amplification mechanism, the comparability between indicators of different dimensions is ensured, while sensitivity to significant offset scenarios is improved. Ultimately, a single, continuous, threshold-determinable monitoring caliber offset value is formed, providing the monitoring and evaluation process with clear data sources, unified calculation logic, and engineering feasibility. This helps improve the accuracy, stability, and reliability of distributed system operation link monitoring.

[0062] Specifically, the process of identifying statistical caliber offset based on the judgment result and performing monitoring caliber correction and threshold adaptive adjustment is as follows: when the monitoring caliber offset value is less than the offset threshold, the statistical caliber is determined to be aligned; the offset threshold is preferably set statistically based on the distribution of monitoring caliber offset values ​​during historical stable operation phases; the reconstruction statistical delay distribution, reconstruction error rate, and reconstruction alarm number are used as the official display caliber for operation link monitoring, while maintaining the current trigger threshold and associated threshold unchanged; at the same time, the monitoring caliber offset value and corresponding time interval in this window are written into the event link monitoring database to form a historical benchmark sample for subsequent threshold adaptive adjustment. When the monitoring caliber offset value exceeds the offset threshold, a statistical offset is determined between the original statistical caliber and the reconstructed statistical caliber, and a statistical caliber offset prompt message is generated. This message includes the trigger event identifier, time window range, monitoring caliber offset value, and the dimension identifier of the difference source, used for visual annotation and alarm prompts on the monitoring interface. The reconstructed statistical latency distribution, reconstruction error rate, and reconstruction alarm number are written as priority monitoring calibers into the event link monitoring database, replacing the original statistical results in the monitoring display layer. The replacement process is implemented through a display layer configuration switch, ensuring that the display caliber switching process has traceable records and does not affect the underlying original data storage. The causal chain confidence value distribution, candidate association consistency value distribution, and monitoring caliber offset value within the current window are recorded together as caliber calibration samples, and the trigger threshold and association threshold are adjusted. The threshold adjustment is preferably based on the statistical characteristics of the caliber calibration samples for adaptive updates, preferably using an adaptive update rule based on statistical quantiles and offset direction constraints. Specifically, within the current sliding time window, the distribution of causal chain confidence values ​​and candidate association consistency values ​​are arranged in ascending order, and preset quantile values ​​are calculated for each. The 70th to 95th quantiles are preferably used as the threshold benchmark. When the monitoring caliber offset value is greater than the offset threshold and the offset direction indicates that the reconstructed statistical result is lower than the original statistical result, the trigger threshold and association threshold are adjusted upwards to the weighted average between the current quantile value and the original threshold. When the offset direction indicates that the reconstructed statistical result is higher than the original statistical result, the trigger threshold and association threshold are adjusted downwards to the weighted average between the current quantile value and the original threshold. The weighted average is preferably updated using an exponential sliding method. When multiple consecutive windows experience offset exceeding the threshold, multiple progressive updates are allowed, but the adjustment range for each instance is preferably limited to ±10% of the original threshold to ensure stability. The updated trigger threshold and association threshold are written to the database configuration table, along with an update timestamp and window identifier, for subsequent window calculation and retrieval, thus forming a traceable, implementable, and dynamically optimized threshold mechanism with clear algorithmic rules and adjustment direction constraints.

[0063] In this implementation plan, by determining the threshold of the monitoring caliber offset value and linking the display caliber switching and threshold adaptive adjustment, this method realizes the automatic identification and dynamic correction of the consistency between the original statistical caliber and the reconstructed statistical caliber. It can promptly calibrate the monitoring benchmark when the link structure changes, the identification is abnormal, or the statistical deviation increases, avoiding misjudgment and repeated triggering, improving the stability, interpretability and cross-window comparability of the monitoring results, and ensuring that the system has continuous adaptive optimization capabilities and engineering feasibility in complex distributed environments.

[0064] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0065] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. As those skilled in the art will understand, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. An intelligent event orchestration triggering and runtime monitoring system for distributed systems, characterized in that, include: The link data acquisition and processing module is used to collect multi-source link data in real time, and to perform time alignment, fingerprint normalization and correlation construction on the multi-source link data to form a unified event link data foundation. The event candidate association generation module is used to extract trigger events and execution events within the sliding time window, construct event fingerprint features based on multi-source link data, and combine event fingerprint features to evaluate the degree of content matching, temporal rationality and topological reachability, and generate candidate association structures based on the association evaluation results. The causal chain reconstruction module is used to expand paths and reconstruct causality based on candidate association structures, and to analyze the consistency aggregation and reuse conflicts of the reconstructed links using association evaluation results, identify the reliability of causal reconstruction, screen the reconstructed causal chains according to reliability and complete the conflict correction. The orchestration trigger control module is used to trigger orchestration decisions based on the reconstruction of causal chains and reliability, and to achieve duplication suppression and idempotent control by combining link signature recognition; The link trust assessment module is used to extract the original statistical results and reconstructed statistical results based on multi-source link data and reconstructed causal chains, combine the original statistical results and reconstructed statistical results to determine the offset, identify the statistical caliber offset based on the determination result, and perform monitoring caliber correction and threshold adaptive adjustment.

2. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of real-time acquisition of multi-source link data, time alignment, fingerprint normalization, and correlation construction of the multi-source link data to form a unified event link data foundation is as follows: Real-time collection of message delivery data, call tracing data, runtime log data, and instance runtime data generated during the operation of the distributed system. Message delivery data includes: message identifier, topic name, production time, consumption time, delivery count, retries count, consumer group name, and message content fingerprint; call tracing data includes: tracing identifier, span identifier, parent span identifier, service name, interface name, start time, end time, execution duration, and status flag; runtime log data includes: log time, log template fingerprint, exception type, and exception stack fingerprint; instance runtime data includes: instance identifier, version identifier, and instance creation time. The call tracing data, runtime log data, message delivery data, and instance runtime data are converted to system standard time and aligned accordingly. Log template fingerprints and exception stacks are fingerprinted and normalized, and message content fingerprints are consistently encoded to eliminate format differences between different data collection terminals. Message events are judged as retry events based on delivery count and retrieval count, and newly triggered or repeatedly delivered events are marked. Call tracing data is used to construct call associations based on tracing identifiers, span identifiers, and parent span identifiers, and message delivery data is used to construct delivery associations based on message identifiers and consumer group names. Call relationship graphs and delivery relationship graphs are generated based on these call and delivery associations, respectively. An event chain monitoring database is established to store raw and preprocessed call tracing data, runtime log data, message delivery data, and instance runtime data.

3. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of extracting trigger events and execution events within the sliding time window and constructing event fingerprint features based on multi-source link data is as follows: By utilizing call tracing data and message delivery data, the set of triggered events and the set of executed events within the sliding time window are extracted. For any triggered event and executed event, the corresponding interface name code, topic name code, log template fingerprint, exception stack fingerprint, and message content fingerprint are obtained. Event fingerprint vectors are constructed respectively, and the occurrence time, execution duration, instance identifier, service name, and number of retries corresponding to the event are recorded synchronously.

4. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of evaluating the correlation between content matching degree, temporal rationality, and topological reachability by combining event fingerprint features is as follows: The content fingerprint similarity value is obtained by performing a vector dot product operation on the event fingerprint vector of the triggering event and the event fingerprint vector of the execution event, and then multiplying the magnitudes of the two event fingerprint vectors respectively, and adding them to the smallest positive number. The ratio of the numerator to the denominator is calculated. The time difference is obtained by subtracting the occurrence time of the triggering event from the occurrence time of the execution event. The link category is determined by the combination of the service name, interface name, and topic name of the triggering event. The historical time difference set of the same type of link is retrieved from the event link monitoring database. The median of the time difference is used as the latency reference value. At the same time, the median absolute deviation of the time difference is calculated as the median absolute deviation of the latency. The absolute difference between the current time difference and the latency reference value is calculated and divided by the sum of the median absolute deviation of the latency and the smallest positive number to obtain the latency deviation. The negative exponent of the latency deviation is used to obtain the latency reachability probability value. By combining the call relationship graph and the delivery relationship graph, the shortest path hop count from the service to which the triggering event belongs to the service to which the execution event belongs is calculated by breadth-first search. The shortest path hop count is added to one and the reciprocal is taken to obtain the topology reachability value. The candidate association consistency value is obtained by multiplying the content fingerprint similarity value, the latency reachability probability value, and the topological reachability value, adding a very small positive number, and taking the cube root.

5. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process for generating candidate association structures based on the association evaluation results is as follows: Calculate the candidate association consistency values ​​between all pairs of trigger events and execution events within the sliding time window, and form a set of candidate association edges, which are stored in the form of triplets of trigger event identifier, execution event identifier and candidate association consistency value; For candidate association edges corresponding to the same triggering event and execution event, sort them in descending order according to the candidate association consistency value, and retain only candidate association edges whose candidate association consistency value is greater than the association threshold; All candidate association edges are aggregated to construct a candidate association graph. The candidate association graph uses events as nodes and candidate association edges as directed edges, and the candidate association consistency value is written into the event link monitoring database as the edge weight.

6. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of expanding and reconstructing paths based on candidate association structures, analyzing the consistency aggregation and reuse conflicts of reconstructed links using association evaluation results, and identifying the reliability of causal reconstruction is as follows: Extract all candidate association edges and their corresponding candidate association consistency values ​​within the sliding time window from the candidate association graph. Based on the directed graph path search, starting from the triggering event, execute the event level by level along the candidate association edge downstream to generate a set of candidate causal chains. Then, obtain the set of candidate association edges and the corresponding sequence of candidate association consistency values ​​contained in each candidate causal chain. For each candidate causal chain, the logarithmic consistency value is obtained by adding a small positive number to the candidate association consistency value of each candidate association edge in the candidate causal chain and taking the natural logarithm. The average logarithmic consistency value is obtained by summing the logarithmic consistency values ​​of all candidate association edges in the candidate causal chain and dividing by the number of candidate association edges. The link consistency aggregation value is obtained by performing natural exponential calculation on the average logarithmic consistency value; For all call tracing data records in the same candidate causal chain, read the corresponding tracing identifier, message identifier, start time, and end time; and filter out pairs of records with the same tracing identifier or the same message identifier; using the start time and end time of the call tracing data record as the time interval, calculate the intersection length and union length of the two time intervals in the record pair, divide the intersection length by the sum of the union length and the smallest positive number to obtain the time overlap ratio of the record pair, and take the maximum time overlap ratio among all record pairs as the reuse conflict degree value; The causal chain confidence value is obtained by subtracting the reuse conflict value from one and then multiplying it by the link consistency aggregation value.

7. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of reconstructing the causal chain based on reliability and completing conflict correction is as follows: Calculate the causal chain confidence value corresponding to all candidate causal chains in the candidate association graph. For the same triggering event, sort the candidate causal chains in descending order of causal chain confidence value and retain the candidate causal chains with causal chain confidence value greater than the confidence threshold as preferred causal chains. If there is more than one preferred causal chain for the same triggering event, the preferred causal chain with the largest causal chain confidence value is taken as the main chain, and the remaining preferred causal chains are marked as conflict chains. For conflict chains, if the call tracing data records contained therein overlap with the main chain in terms of time interval, the call tracing data records that overlap with the main chain in the conflict chain are deleted, and the causal chain confidence value is recalculated. If the recalculated causal chain confidence value is still greater than the confidence threshold, the conflict chain is retained as a split chain; otherwise, it is discarded. The main chain corresponding to the triggering event is used as the causal chain for reconstruction; if there is no candidate causal chain with a causal chain confidence value greater than the confidence threshold, the causal chain of the triggering event is determined to be unreliable and marked as an event with undetermined causality.

8. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of triggering orchestration decisions based on reconstructing causal chains and reliability, and combining link signature recognition to achieve duplication suppression and idempotent control is as follows: Read the reconstructed causal chain and causal chain confidence value corresponding to all triggered events within the sliding time window; for each triggered event, if the causal chain confidence value is greater than the trigger threshold, generate an orchestration trigger instruction, which includes the trigger event identifier, the service name sequence, the interface name sequence, and the time interval sequence in the reconstructed causal chain; If the confidence value of the causal chain is not greater than the trigger threshold or the triggering event is marked as a causal undetermined event, the triggering event will be written to the delayed confirmation queue. For the reconstructed causal chain that has generated orchestration trigger instructions, a link signature value is generated. The link signature value is obtained by combining the service name sequence, interface name sequence, time interval sequence and message content fingerprint in the reconstructed causal chain and performing consistency coding calculation. The link signature value is matched with the historical link signature values ​​in the event link monitoring database. If the same link signature value exists, it is determined to be a duplicate trigger and the current orchestration trigger command is suppressed. If no matching link signature value exists, the link signature value is written to the event link monitoring database, and the corresponding orchestration trigger command is executed.

9. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of extracting the original and reconstructed statistical results based on multi-source link data and reconstructed causal chains, and then combining the original and reconstructed statistical results to determine the offset is as follows: For all triggered events within the sliding time window, call trace data, runtime log data, and causal chains are obtained and reconstructed; the raw statistical latency distribution is obtained based on the execution duration statistics in the call trace data. The reconstruction statistical latency distribution is obtained based on the execution time statistics of the call tracing data records in the reconstructed causal chain; The original error rate is obtained by calculating the proportion of abnormal states based on the status markers in the call tracing data; the reconstruction error rate is obtained by calculating the proportion of abnormal states based on the status markers recorded in the call tracing data in the reconstructed causal chain. The original alarm count is obtained by statistically analyzing the anomaly types in the operation log data; the reconstructed alarm count is obtained by statistically analyzing the anomaly types in the reconstructed causal chain within the time interval sequence. The delay distribution difference is obtained by calculating the JS divergence between the original statistical delay distribution and the reconstructed statistical delay distribution. The error rate difference is obtained by subtracting the reconstructed error rate from the original error rate. The error rate difference is then squared after dividing the error rate difference by the sum of the reconstructed error rate and the smallest positive number. The alarm number difference is obtained by subtracting the reconstructed alarm number from the original alarm number. The alarm number difference is then squared after dividing the alarm number difference by the sum of the reconstructed alarm number and the smallest positive number. The alarm number normalization difference squared term is then added together and the alarm number normalization difference squared term is then squared to obtain the monitoring caliber offset value.

10. The intelligent event orchestration triggering and operation link monitoring system for distributed systems according to claim 1, characterized in that, The specific process of identifying statistical caliber offset based on the judgment result and performing monitoring caliber correction and threshold adaptive adjustment is as follows: When the monitoring caliber offset value is less than the offset threshold, the statistical caliber is determined to be aligned; the reconstruction statistical delay distribution, reconstruction error rate and reconstruction alarm number are used as the official display caliber of the running link monitoring, and the current trigger threshold and associated threshold remain unchanged. When the monitoring caliber offset value is greater than the offset threshold, it is determined that there is a statistical offset between the original statistical caliber and the reconstructed statistical caliber, and a statistical caliber offset prompt message is generated. The reconstructed statistical delay distribution, reconstructed error rate and reconstructed alarm number are written into the event link monitoring database as priority monitoring calibers and the original statistical results are replaced in the monitoring display layer. The causal chain confidence value distribution, candidate association consistency value distribution and monitoring caliber offset value in the current window are recorded as caliber calibration samples, and the trigger threshold and association threshold are adjusted.

Images