Distributed cooperative monitoring and data synchronization method and system for multi-node information system

Abstract

The application relates to the technical field of information system operation and maintenance monitoring, and particularly provides a distributed cooperative monitoring and data synchronization method and system for a multi-node information system, which comprises the following steps: dividing cooperative monitoring groups based on the business association attributes and network deployment positions of each node, and determining the synchronization management nodes of each group; collecting data according to the association characteristic extraction rules of the nodes in the group, extracting characteristic data carrying cross-node association identifiers, and forming a shared monitoring data set through point-to-point interaction of the nodes in the group; carrying out cross-node cross-checking based on the shared data set, generating local alarms and group state information, and reporting the center control node; the synchronization management nodes continuously execute group synchronization, the configuration type data is incrementally synchronized according to the version identifier, the running state data is continuously synchronized, and the breakpoint continuation transmission is triggered when the nodes are offline and reconnected; and the center node collects and reports the information to implement global control, so that the monitoring accuracy and data synchronization reliability of the multi-node system are effectively improved, and the operation and maintenance complexity is reduced.

Description

Technical Field

[0001] This invention relates to the field of information system operation and maintenance monitoring technology, specifically to a distributed collaborative monitoring and data synchronization method and system for multi-node information systems. Background Technology

[0002] With the continuous advancement of information technology construction in power grid enterprises, information systems are increasingly widely used in power grid production, operation, and management. The system scale is constantly expanding, gradually evolving into a multi-node distributed architecture encompassing various dispersed nodes such as data center environmental monitoring systems, servers, databases, middleware, storage, security equipment, virtualization platforms, and business applications. In existing operation and maintenance solutions, a centralized monitoring architecture is typically adopted for these multi-node information systems, where a central control node centrally manages data collection, storage, analysis, and alarm triggering for each dispersed node. However, as the node scale grows and the dimensions of collected indicators become increasingly refined, the centralized monitoring architecture is gradually revealing the following technical shortcomings: First, there is a lack of collaborative monitoring capabilities among nodes, resulting in poor timeliness of fault assessment. Under the existing centralized monitoring model, each distributed node only undertakes passive data collection and reporting tasks, with no monitoring data interaction or collaborative assessment mechanism between nodes, and each node is independent and isolated from the others. Anomalies and fault events must all be aggregated to the central control node before correlation analysis and alarm determination can be carried out, making it impossible to achieve local collaborative verification and nearby anomaly identification by multiple nodes. The fault assessment chain is lengthened, and alarm response is delayed, making it difficult to meet the high real-time and high reliability operation and maintenance monitoring requirements of the power grid information system.

[0003] Secondly, the multi-node monitoring data synchronization mechanism is imperfect, making it difficult to guarantee the consistency of monitoring status. In distributed monitoring scenarios, configuration data such as asset configuration, monitoring templates, collection strategies, and alarm rules, as well as runtime monitoring data such as monitoring indicators, device status, and fault alarms, all need to be consistent across nodes. Traditional solutions often use full push or static file distribution to complete configuration distribution and rely on a central management node to relay runtime data synchronization. When configurations change, network fluctuations and the efficiency of replication mechanisms can easily lead to problems such as version inconsistencies, update delays, missing nodes, or configuration overwrite conflicts. Furthermore, the lack of configuration change auditing, rollback mechanisms, and effective status feedback makes fault localization difficult. In the face of network jitter, unstable links, and temporary node offline scenarios, runtime monitoring data is prone to synchronization delays, inconsistencies between replicas, alarm loss, and data update misalignments. Overall, there is a lack of data verification, conflict handling, and breakpoint resumption capabilities adapted to distributed architectures, resulting in high operational risks.

[0004] In summary, the existing centralized monitoring architecture and its supporting data synchronization methods are difficult to adapt to the development trend of large-scale and distributed multi-node information systems. There are technical problems such as nodes lacking collaborative monitoring capabilities and imperfect multi-node monitoring data synchronization. There is an urgent need for a solution that can effectively realize distributed collaborative monitoring and efficient data synchronization of multi-node information systems in order to improve the stability of overall monitoring, the timeliness of fault diagnosis, and the accuracy of operation and maintenance data. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides a distributed collaborative monitoring and data synchronization method and system for multi-node information systems, in order to solve the problems in existing technologies.

[0006] One embodiment of the present invention provides a distributed collaborative monitoring and data synchronization method for multi-node information systems, comprising the following steps: Based on the business association attributes and network deployment location of each node, multiple collaborative monitoring groups are divided. Association feature extraction rules and collaborative judgment rules are configured for each collaborative monitoring group, and the synchronization management node of each collaborative monitoring group is determined. Each node in the collaborative monitoring group collects local monitoring data in real time, extracts key status indicators and abnormal feature data according to the correlation feature extraction rules, and exchanges the extracted key status indicators and abnormal feature data point by point within the group to form a shared monitoring dataset within the group. Based on the shared monitoring dataset and collaborative judgment rules within the group, the nodes in each collaborative monitoring group perform cross-node cross-verification and anomaly judgment, generate local alarm information and group status information, and report them to the central control node. The central control node aggregates the local alarm information and group status information reported by each collaborative monitoring group, and performs global control over the collaborative monitoring and data synchronization process of each collaborative monitoring group. During the process of data interaction and anomaly detection within each collaborative monitoring group, the synchronization management node of each collaborative monitoring group continuously performs data synchronization operations within the group: When configuration data changes and a corresponding version identifier is generated, perform incremental point-to-point synchronization within the group on the configuration data; continuously perform point-to-point synchronization within the group on the runtime monitoring data. When a node in the group reconnects offline, it triggers a resume function to fill in the missing configuration data and runtime monitoring data.

[0007] This invention also relates to a distributed collaborative monitoring and data synchronization system for multi-node information systems, comprising: The grouping module is used to divide multiple collaborative monitoring groups based on the business association attributes and network deployment location of each node, configure association feature extraction rules and collaborative judgment rules for each collaborative monitoring group, and determine the synchronization management node for each collaborative monitoring group. The data acquisition module is used to collect local monitoring data in real time by nodes in each collaborative monitoring group, extract key status indicators and abnormal feature data according to the correlation feature extraction rules, and perform point-to-point interaction of the extracted key status indicators and abnormal feature data within the group to form a shared monitoring dataset within the group. The verification module is used by nodes in each collaborative monitoring group to perform cross-node verification and anomaly determination based on the shared monitoring dataset and collaborative judgment rules within the group, generate local alarm information and group status information, and report them to the central control node. The data synchronization module is used to control the synchronization management nodes of each collaborative monitoring group to continuously perform data synchronization operations during the data interaction and anomaly judgment process within each collaborative monitoring group: when configuration data changes and a corresponding version identifier is generated, incremental point-to-point synchronization is performed on the configuration data within the group; point-to-point synchronization is continuously performed on the running monitoring data within the group; when a node in the group goes offline and reconnects, the interruption resume transmission is triggered to fill in the missing configuration data and running monitoring data; The management and control module is used by the central management and control node to aggregate local alarm information and group status information reported by each collaborative monitoring group, and to perform global management and control over the collaborative monitoring and data synchronization process of each collaborative monitoring group.

[0008] This application also relates to a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described distributed collaborative monitoring and data synchronization method for a multi-node information system.

[0009] This application also relates to a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described distributed collaborative monitoring and data synchronization method for a multi-node information system.

[0010] The distributed collaborative monitoring and data synchronization method and system for multi-node information systems provided in the above embodiments have the following beneficial effects: This invention divides collaborative monitoring groups based on both business association attributes and network deployment location, balancing business coupling and network proximity to reduce intra-group collaboration overhead. It collects feature data carrying cross-node association identifiers through association feature extraction rules, forming a shared monitoring dataset through point-to-point interaction within the group, providing native association data support for cross-node verification. Cross-node cross-verification is performed based on the shared dataset to distinguish between node anomalies, link anomalies, and isolated false alarms, improving alarm accuracy. Synchronization management nodes continuously perform intra-group synchronization, incrementally synchronizing configuration data by version identifier, continuously synchronizing runtime data, and triggering breakpoint resume for offline node reconnection, avoiding full synchronization overhead and data loss risks, ensuring data consistency within the group. The central control node aggregates all reported information for global control, breaking down cross-group information barriers. Overall, this effectively improves the monitoring accuracy, data synchronization reliability, and operational efficiency of multi-node systems while reducing operational complexity. Attached Figure Description

[0011] Figure 1 A flowchart of a distributed collaborative monitoring and data synchronization method for multi-node information systems provided in this embodiment of the invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions in the embodiments of the present invention will now be clearly and completely described in conjunction with the accompanying drawings.

[0013] Reference Figure 1 One embodiment of the present invention provides a distributed collaborative monitoring and data synchronization method for multi-node information systems, comprising the following steps: S10. Divide each node into multiple collaborative monitoring groups based on its business association attributes and network deployment location, configure association feature extraction rules and collaborative judgment rules for each collaborative monitoring group, and determine the synchronization management node for each collaborative monitoring group. S20. Nodes within each collaborative monitoring group collect local monitoring data in real time, extract key status indicators and abnormal feature data according to the correlation feature extraction rules, and exchange the extracted key status indicators and abnormal feature data point-to-point within the group to form a shared monitoring dataset within the group. S30. Nodes within each collaborative monitoring group perform cross-node cross-verification and anomaly determination based on the shared monitoring dataset and collaborative judgment rules within the group, generate local alarm information and group status information, and report them to the central control node. S40, the central control node summarizes the local alarm information and group status information reported by each collaborative monitoring group, and performs global control over the collaborative monitoring and data synchronization process of each collaborative monitoring group; During the process of data interaction and anomaly detection within each collaborative monitoring group, the synchronization management node of each collaborative monitoring group continuously performs data synchronization operations within the group: When configuration data changes and a corresponding version identifier is generated, perform incremental point-to-point synchronization within the group on the configuration data; continuously perform point-to-point synchronization within the group on the runtime monitoring data. When a node in the group reconnects offline, it triggers a resume function to fill in the missing configuration data and runtime monitoring data.

[0014] In this embodiment, as described in steps S10~S40 above, specifically: In step S10, the executing entity is the central control node, and the executing object is a multi-node information system including data center environmental monitoring, servers, databases, middleware, storage, security equipment and business applications. The aim is to divide the large-scale distributed nodes into logical groups with autonomous capabilities. Among them, business association attributes refer to a set of metadata characterizing the degree of business logic coupling between nodes, including at least the business system to which the node belongs, the type of service it carries, the business call chain between nodes, and the frequency of business calls, used to measure the tightness of business layer between nodes; network deployment location refers to a set of metadata characterizing the physical or logical network topology location of the node, including at least the data center, rack, network segment, and network topology connection relationship to which the node belongs, used to measure the physical cost of network transmission between nodes; collaborative monitoring group is a logical set of nodes with high business association and high network proximity that are grouped into the same management domain, serving as the basic unit for collaborative monitoring and data synchronization within the group; association feature extraction rules are a set of strategies used to define the data types and collection frequencies that nodes within the group need to collect; collaborative judgment rules are a set of strategies used to define the algorithm logic and anomaly judgment thresholds used when nodes within the group perform cross-validation; synchronization management node is a specific node within each collaborative monitoring group that is responsible for data aggregation, synchronization scheduling, and communication with the central control node.

[0015] In this step, the central control node first collects the business association attributes and network deployment location information of all nodes. Based on the affinity criteria of both business and network dimensions, the nodes are divided into different collaborative monitoring groups to ensure that the nodes in the group have a low-latency, high-bandwidth interaction foundation. Differentiated association feature extraction rules and collaborative judgment rules are configured for each collaborative monitoring group to adapt to the monitoring needs of different business scenarios. Finally, the node with the best resources in each collaborative monitoring group is selected as the synchronous management node.

[0016] In step S20, the execution entity is the node within each collaborative monitoring group. The aim is to complete the collection and feature extraction of local monitoring data based on the correlation feature extraction rules configured in step S10, and to form a shared monitoring dataset that supports cross-node collaborative verification through point-to-point interaction within the group. Local monitoring data refers to multi-source heterogeneous data generated by the node during operation, reflecting its own operational status, including at least the node's own operational indicators, local indicators of the business call chain, and local abnormal log features. Key status indicators refer to feature data extracted from local monitoring data according to correlation feature extraction rules, capable of quantifying the core operational status of the node. Abnormal feature data refers to feature data extracted from local monitoring data according to correlation feature extraction rules, capable of reflecting abnormal symptoms of the node. Point-to-point interaction refers to the interaction mode between nodes within the group, where data is sent and received via a synchronous management node as a convergence and relay, or through direct peer-to-peer connections. The shared monitoring dataset within the group refers to a unified data set formed after the key status indicators and abnormal feature data extracted by each node within the group are interactively aggregated, and accessible and usable by any node within the group.

[0017] This step is executed in parallel by nodes within each collaborative monitoring group: each node collects local monitoring data in real time and extracts key status indicators and abnormal feature data from it according to the correlation feature extraction rules configured for the group in step S10; the nodes complete the distribution and aggregation of feature data through point-to-point interaction, and finally form a unified intra-group shared monitoring dataset, providing a unified data foundation for subsequent cross-node cross-verification and anomaly judgment.

[0018] In step S30, the execution entity is the node within each collaborative monitoring group. The aim is to complete cross-node cross-verification and anomaly determination within the group based on the aforementioned shared monitoring dataset and collaborative judgment rules, generating local alarm information and group status information, and reporting them to the central control node. Specifically, cross-node cross-verification refers to a verification mode where nodes within the group compare and verify feature data collected from multiple sides for the same business link or related nodes based on the shared monitoring dataset; anomaly determination refers to the process of matching verification results according to collaborative judgment rules to identify node anomalies, link anomalies, or isolated false alarms; local alarm information refers to alarm records generated by nodes based on anomaly determination results, containing anomaly node identifiers, anomaly type identifiers, and anomaly link identifiers; and group status information refers to status records generated by nodes based on verification results, used to characterize the health status of each node within the group, the connectivity status of related links, and verification timestamps.

[0019] This step is executed in parallel by nodes within each collaborative monitoring group: nodes retrieve the shared monitoring dataset within the group and match the corresponding collaborative judgment rules; cross-node cross-verification and anomaly judgment are performed based on the rules; local alarm information and group status information are generated based on the judgment results, and the above information is reported to the central control node.

[0020] In step S40, the executing entity is the central control node, which aims to aggregate the local alarm information and group status information reported by each collaborative monitoring group, and to perform global control over the collaborative monitoring and data synchronization process of each collaborative monitoring group. Global control refers to the control mode in which the central control node, based on the aggregated full-domain monitoring information, coordinates and manages the collaborative monitoring and data synchronization process of each collaborative monitoring group. The collaborative monitoring and data synchronization process refers to the complete operational process in which nodes within each collaborative monitoring group perform data collection, feature extraction, sharing and interaction, cross-validation, anomaly detection, and data synchronization within the group.

[0021] This step is executed by the central control node: receiving and summarizing local alarm information and group status information reported by each collaborative monitoring group, and coordinating and managing the collaborative monitoring execution and data synchronization process of each group based on the aggregated data across the entire domain.

[0022] During the process of data interaction and anomaly determination within each collaborative monitoring group, the synchronization management node of each collaborative monitoring group continuously performs data synchronization operations within the group. This synchronization operation is performed in parallel with the data interaction and anomaly determination process within the group, and its core function is to continuously ensure the consistency and integrity of configuration data and runtime monitoring data within the group. Configuration data refers to system configuration information that needs to be kept consistent across all nodes in the group, including at least related feature extraction rules, collaborative judgment rules, asset configuration data, monitoring templates, and collection strategies; version identifiers are feature identifiers generated when configuration data changes, used to uniquely identify the configuration version, and serve as the basis for version comparison in incremental synchronization; runtime monitoring data refers to data generated by each node during operation that reflects its real-time running status, including at least monitoring indicator data, device status data, and fault alarm data; intra-group incremental point-to-point synchronization refers to a synchronization mode in which the synchronization management node synchronizes only the changed configuration data to the remaining nodes in the group in a point-to-point manner based on the version identifier comparison results; breakpoint resume transmission refers to a mechanism in which, after a node reconnects offline, the synchronization management node, based on the node's synchronization progress offset, only fills in the missing data.

[0023] When configuration data changes and a corresponding version identifier is generated, the synchronization management node performs incremental point-to-point synchronization of the configuration data within the group; it continuously performs point-to-point synchronization of the runtime monitoring data within the group; when a node in the group goes offline and reconnects, the synchronization management node triggers breakpoint resume transmission to fill in the missing configuration data and runtime monitoring data of that node.

[0024] In one embodiment, step S10, which involves dividing multiple collaborative monitoring groups based on the service association attributes and network deployment locations of each node, specifically includes: S111. Based on the business association attributes of each node, obtain the business call chain and business call frequency between any two nodes, and quantify the business association degree between nodes based on the business call chain and business call frequency. S112. Based on the network deployment location of each node, obtain the network topology connection relationship and network round-trip time between any two nodes, and quantify the network proximity between nodes based on the network topology connection relationship and network round-trip time. S113. Based on the business correlation and network proximity between nodes, a preset clustering algorithm is used to divide nodes that meet the preset affinity conditions into the same collaborative monitoring group. The preset affinity condition is that the network round-trip latency between nodes is less than a preset latency threshold, and the frequency of service calls between nodes is greater than a preset frequency threshold.

[0025] In this embodiment, as described in steps S111~S113 above, specifically: Step S111 is the quantitative calculation step for the business dimensions divided by the collaborative monitoring group, which is the core prerequisite step for completing node grouping based on business association attributes in step S10. Here, business call links refer to the transmission paths of business requests and responses between nodes, including at least HTTP / HTTPS call links, RPC remote call links, database connection links, and message queue consumption links, used to characterize the business dependencies between nodes; business call frequency refers to the number of requests initiated between nodes through business call links per unit time, used to quantify the activity level of business interactions between nodes; business association degree is a quantitative value representing the strength of business coupling between nodes, calculated by combining the dependency depth of business call links and the activity level of business call frequency. The higher the value, the tighter the business association between nodes. This step first traverses the business association attributes of all nodes, extracts all business call links between any two nodes, and counts the business call frequency of the corresponding links; then, using a preset weighted calculation, such as a linear weighted fusion model, a normalized weighted scoring model, or an entropy weighted model, it fuses the dependency weight of the business call links with the activity weight of the business call frequency to obtain the business association degree value between the two nodes. This step solves the problem that traditional grouping methods can only qualitatively determine business relevance and cannot quantify the coupling strength, providing a quantifiable business dimension basis for the subsequent refined division of collaborative monitoring groups.

[0026] Step S112 is the network dimension quantification calculation step for the collaborative monitoring group, which is another core pre-step in step S10 to complete node grouping based on network deployment location. Here, network topology connection relationship refers to the physical or logical connection path of nodes in the network architecture, including at least the access port mapping relationship of the Layer 2 switching network, the forwarding path of the Layer 3 routing network, and the cross-data center leased line connection relationship, used to characterize the network connectivity between nodes; network round-trip time refers to the total time it takes for a data packet to travel from the source node to the receiving destination node and back to the source node, used to quantify the network transmission efficiency between nodes; network proximity is a quantitative value characterizing the convenience of network transmission between nodes, calculated by combining the hop count of the network topology connection relationship and the network round-trip time, with a higher value indicating lower network interaction costs between nodes. This step first traverses the network deployment location information of all nodes, extracts the network topology connection relationship between any two nodes, and measures the network round-trip latency of the corresponding path. Then, using a preset weighted calculation, such as a linear weighted fusion model, a normalized weighted scoring model, or an entropy weighted model, it fuses the path weight of the network topology hop count with the efficiency weight of the network round-trip latency to obtain the network proximity value between the two nodes. This step solves the problem that traditional grouping methods only qualitatively determine network location and cannot quantify transmission efficiency, providing a quantifiable network dimension basis for the subsequent refined division of collaborative monitoring groups.

[0027] Step S113 is the collaborative monitoring group clustering and partitioning step based on the dual-dimensional quantization results, which is the final execution step in step S10 to realize the logical grouping of nodes. The preset clustering algorithm refers to an unsupervised learning algorithm used to group nodes with similar characteristics into the same class, including at least the density-based DBSCAN clustering algorithm, K-Means clustering algorithm, and hierarchical clustering algorithm, used to automatically group nodes with similar business relevance and network proximity into the same group; the preset affinity condition refers to the admission rules used to determine whether nodes meet the requirements for grouping, specifically, the network round-trip latency between nodes is less than a preset latency threshold, and the business call frequency between nodes is greater than a preset frequency threshold, used to simultaneously ensure the network interaction efficiency and business coupling strength of nodes within the group. This step first inputs the business relevance and network proximity of all nodes as two-dimensional feature vectors into a pre-defined clustering algorithm. Then, it iterates through the candidate groups output by the clustering algorithm, verifying whether each node in a candidate group meets the pre-defined affinity conditions. Nodes that do not meet the affinity conditions are removed, and the clustering is re-completed. Finally, nodes that meet the pre-defined affinity conditions are grouped into the same collaborative monitoring group. This step solves the problems of traditional grouping methods failing to simultaneously consider business coupling and network efficiency, and having poor adaptability of grouping results, achieving accurate two-dimensional partitioning of collaborative monitoring groups.

[0028] To facilitate understanding by those skilled in the art, it is assumed that a multi-node cluster in a power grid dispatch automation system is used as a practical application scenario: First, step S111 is executed. The system iterates through the business association attributes of the scheduling master node, SCADA front-end node, database node, and application service node. It extracts the RPC call link between the scheduling master node and the SCADA front-end node, finding a call frequency of 1200 times per unit time, and calculates a business association degree of 0.92. It also extracts the database connection link between the SCADA front-end node and the database node, finding a call frequency of 800 times per unit time, and calculates a business association degree of 0.85. Simultaneously, step S112 is executed. The system iterates through the network deployment location information of the above nodes, extracting the network topology connection relationship between the scheduling master node and the SCADA front-end node as Layer 2 interconnection within the same data center, and measuring a network round-trip latency of 0.8ms. The calculated network proximity between the two nodes is 0.95. The network topology connection between the SCADA front-end node and the remote backup adjustment point is extracted as a cross-data center dedicated line connection. The measured network round-trip latency is 35ms, and the calculated network proximity between the two nodes is 0.32. Finally, step S113 is executed. The system uses the business correlation and network proximity as two-dimensional features to input the DBSCAN clustering algorithm. The affinity condition verification (network round-trip latency < 5ms, business call frequency > 500 times / second) is performed on the node combination output by the clustering. Compliant nodes are selected to form the final collaborative monitoring group. Finally, the scheduling master node, SCADA front-end node and database node are assigned to the first collaborative monitoring group, and the remote backup adjustment point is assigned to the second collaborative monitoring group, so as to achieve accurate matching between the grouping results and business and network characteristics.

[0029] In one embodiment, step S10, determining the synchronization management node of each collaborative monitoring group, specifically includes: S121. Collect resource load parameters of each node in the collaborative monitoring group. The resource load parameters include at least CPU idle rate, memory remaining amount and network bandwidth utilization rate. S122. Calculate the node health score based on the resource load parameters of each node; S123. The node with the highest health score within the same collaborative monitoring group is designated as the synchronization management node for that group.

[0030] In this embodiment, as described in steps S121-S123 above, specifically: Step S121 is the resource parameter collection step for the synchronization management node election, a core prerequisite for determining the synchronization management node. Among these parameters, CPU idle rate refers to the proportion of currently unused computing resources on a node's CPU relative to the total CPU resources, representing the node's computing load margin; memory remaining refers to the storage capacity in the node's physical or virtual memory not occupied by business processes, representing the node's storage load margin; and network bandwidth utilization rate refers to the ratio of the node's currently used network throughput to the rated total bandwidth, representing the node's network transmission load margin. This step first iterates through all surviving nodes in the collaborative monitoring group. Real-time resource load parameters can be directly extracted from the local monitoring data collected in step S20, or a dedicated collection can be initiated when the synchronization node election is triggered. Then, all collected parameters are validated for legality, eliminating null values ​​and out-of-limit values ​​caused by collection anomalies, resulting in a compliant set of resource load parameters. This step solves the problems of lack of unified standards and low data reliability in traditional leader election processes, providing an accurate input data source for subsequent health score calculations.

[0031] Step S122 is the node health score quantification calculation step, which is the core judgment step for the synchronous management node election. The node health score is a quantitative value representing the current operational health status of a node, calculated by comprehensively considering multi-dimensional resource load parameters. All indicators are uniformly mapped to a standard range of 0-1 for easy weighted fusion calculation; a higher value indicates lower node load and stronger operational stability. This step first uses a preset weighted calculation model, such as a linear weighted fusion model, a normalized weighted scoring model, or an entropy weighted model, to assign corresponding weights to CPU idle rate, remaining memory, and network bandwidth utilization. Then, the collected three types of resource parameters are mapped to normalized intervals, and the weighted sum is calculated to obtain the health score of each node. For example, a weight can be set for CPU idle rate (0.4), remaining memory (0.3), and network bandwidth utilization (0.3). If a node has a CPU idle rate of 85%, remaining memory of 50%, and network bandwidth utilization of 15%, its health score is 0.85×0.4 + 0.5×0.3 + (1-0.15)×0.3 = 0.795. This step solves the problem of traditional leader selection lacking quantitative evaluation standards and being highly subjective, providing a quantifiable basis for selecting synchronization management nodes.

[0032] Step S123 is the final selection step for the synchronization management node, which is the execution step to determine the synchronization management node. This step first iterates through the health scores of all nodes in the collaborative monitoring group, sorting them from highest to lowest score. Then, it selects the node with the highest score as a candidate for the synchronization management node of that group. If multiple nodes have the same score, the node with the smallest lexicographical order of its node identifier is selected as the final candidate. Finally, the selection result is synchronized to all nodes in the group and the central control node, completing the initial establishment of the synchronization management node. This step solves the problems of strong randomness and lack of unified judgment rules in traditional leader selection, ensuring optimal performance and operational stability of the management nodes within the group.

[0033] To facilitate understanding by those skilled in the art, the following example of the first collaborative monitoring group scenario in the aforementioned power grid dispatch automation system is provided: The group consists of three nodes: a scheduling master node, a SCADA front-end node, and a database node. The resource load parameters collected in step S121 are as follows: scheduling master node CPU idle rate 70%, memory remaining 40GB, network bandwidth utilization 20%; SCADA front-end node CPU idle rate 85%, memory remaining 32GB, network bandwidth utilization 15%; database node CPU idle rate 60%, memory remaining 64GB, network bandwidth utilization 25%. Step S122 calculates the health scores of the three nodes according to preset weights: Dispatch master node: 0.7×0.4+(40 / 64)×0.3+(1-0.2)×0.3≈0.708; SCADA front-end node: 0.85×0.4+(32 / 48)×0.3+(1-0.15)×0.3≈0.795; Database node: 0.6×0.4+(64 / 128)×0.3+(1-0.25)×0.3≈0.615. Step S123 selects the SCADA front-end node with the highest score as the synchronization management node of the first collaborative monitoring group after sorting, and synchronizes the results to all nodes in the group and the central control node, completing the initial master node selection process.

[0034] In one embodiment, after step S10, the method further includes: S131. When a failure is detected in the synchronization management node, the synchronization context information of the failure node is obtained. The synchronization context information includes at least the current effective version identifier of the configuration data and the synchronization progress offset of the running monitoring data. S132. Among the remaining nodes after removing faulty nodes in the same collaborative monitoring group, select candidate nodes whose health scores meet the preset health threshold and whose configuration data corresponding to the current effective version identifier has been fully cached. S133. The node with the smallest difference between the synchronization progress offset of the running monitoring data and the faulty node among the candidate nodes is determined as the new synchronization management node.

[0035] In this embodiment, as described in steps S131-S133 above, specifically: Step S131 is the context information collection step after the synchronization management node fails, and it is a core preliminary step in the fault takeover process. Synchronization context information refers to the state snapshots periodically and persistently saved by the synchronization management node during runtime, used to ensure the continuity of synchronization tasks after a failure. The current effective version identifier of configuration data is a unique marker of the configuration data version used by the failed node before its crash, corresponding to the version identifier generated by the configuration data change in step S10. The synchronization progress offset of the running monitoring data is the maximum position marker of the running monitoring data that the failed node has successfully synchronized with the nodes in the group, used to identify the interruption point of data synchronization. This step first detects the liveness status of the synchronization management node through a heartbeat detection mechanism among nodes in the group. When no response is received from the failed node for three consecutive preset heartbeat cycles, it is determined that the node has failed and crashed. Then, the above two types of core information are read from the local persistent storage of the failed node or the backed-up context copy within the group. This step solves the problems of traditional fault takeover processes lacking state inheritance basis and being prone to data inconsistency or loss of synchronization breakpoints after takeover, providing core state support for subsequent smooth takeover.

[0036] Step S132 is the candidate node screening step, which is the qualification verification step of the fault takeover process. The preset health threshold refers to the minimum health threshold value at which a node can assume the responsibilities of a synchronization management node. This threshold uses the same normalized scale (e.g., 0~1 range) as the health score calculated in step S122. Its specific value can be determined comprehensively based on the historical health distribution of nodes within the group, the minimum performance requirements of the business for synchronization management nodes, and fault tolerance. For example, it can be set to 0.5 to filter out nodes with excessive load, insufficient resources, or unstable operation, ensuring that the selected candidate nodes have the ability to assume synchronization management responsibilities. "Completely cached configuration data corresponding to the current effective version identifier" means that the configuration data stored locally on the node is completely consistent with the current effective version of the faulty node, with no missing or version mismatches. This step first removes faulty nodes from the collaborative monitoring group to obtain a set of surviving nodes; then it iterates through the health scores of the surviving nodes, filtering out nodes with scores greater than or equal to the preset health threshold; finally, it verifies the local configuration cache of the candidate nodes, retaining only nodes that have completely stored the configuration data of the current effective version, forming the final set of candidate nodes. This step addresses the issues of traditional failover not considering node capacity and configuration consistency, and the inability of newly selected nodes to take over synchronization tasks, thus ensuring the availability and data compliance of nodes after takeover.

[0037] Step S133 is the selection of the new synchronization management node, which is the final execution step in the fault takeover process. This step first iterates through the synchronization progress offsets of the running monitoring data of candidate nodes, calculating the absolute difference between each offset and the offset of the faulty node. The node with the smallest difference is selected first. If multiple nodes have the same difference, the node with the highest health score is selected. If the health scores are still the same, the node with the smallest lexicographical order of its node identifier is selected. Finally, the selection result is synchronized to all nodes in the group and the central control node, completing the seamless switchover of the synchronization management node. This step solves the problem of traditional fault takeover requiring full data synchronization and long business interruption times, achieving low latency and high availability in the takeover process by minimizing the amount of data replenishment.

[0038] To facilitate understanding by those skilled in the art, the following example of the first collaborative monitoring group scenario in the aforementioned power grid dispatch automation system is provided: The initial synchronization management node in this group is the SCADA front-end node. Before the failure, its synchronization context was configuration version ID V1.2 and running data synchronization progress offset of 10240. Step S131 determines that the SCADA front-end node has crashed and retrieves the aforementioned context information from its local persistent storage. Step S132 filters the remaining nodes in the group: the scheduling master node has a health score of 0.708 (meeting the preset threshold of ≥0.5) and has cached version V1.2 configuration; the database node has a health score of 0.615 (meeting the preset threshold of ≥0.5) and has cached version V1.2 configuration. Both are included in the candidate node set. Step S133 compares the synchronization progress offsets: the scheduling master node's offset is 10230 (a difference of 10 from the failed node), and the database node's offset is 10238 (a difference of 2 from the failed node). The database node with the smaller offset difference is selected as the new synchronization management node, and the result is synchronized to the nodes in the group and the central control node, achieving seamless switching of synchronization services in the event of a failure.

[0039] In one embodiment, step S20 specifically includes: S21. For any two nodes in the collaborative monitoring group whose business correlation is greater than a preset correlation threshold, based on the pre-configured correlation feature extraction rules, determine the correlation feature extraction parameters that match the business call chain of the node pair. The correlation feature extraction parameters include at least the feature collection frequency, and the collection frequency is positively correlated with the business call frequency of the node pair. S22. Each node collects local monitoring data in real time based on the determined correlation feature extraction parameters and extracts key status indicators and abnormal feature data containing cross-node correlation identifiers. The cross-node correlation identifiers include at least the source node identifier, the target node identifier, and the business call link identifier. The local monitoring data includes at least the node's own operating indicators, the local side indicators of the business call link, and the local abnormal log features. S23. The node will extract the key status indicators and abnormal feature data carrying cross-node association identifiers and send them to the synchronization management node according to the transmission path with the synchronization management node as the aggregation node and the point-to-point interaction between each node in the group and the synchronization management node as the transmission path. S24. The synchronization management node performs association matching and redundancy filtering on the received key status indicators and abnormal feature data based on the cross-node association identifier. After removing irrelevant data that does not carry a valid cross-node association identifier, the key status indicators and abnormal feature data that have been successfully associated are sent to the corresponding nodes in the associated node pairs to form a shared monitoring dataset within the group.

[0040] In this embodiment, as described in steps S21-S24 above, specifically: Step S21 is the dynamic adaptation step for associated feature parameters, a core prerequisite for differentiated data collection in step S20, and corresponds to the pre-configured associated feature extraction rules in step S10. Specifically, the preset association threshold refers to the minimum business association degree threshold used to determine whether a node pair has a strong business association. It uses the same normalized scale (e.g., 0~1 range) as the business association degree calculated in step S111, for example, it can be set to 0.6. Node pairs exceeding this threshold require key monitoring. The associated feature extraction parameters refer to a set of collection rules customized for specific business call links, which may include collection dimensions, data precision, and other parameters in addition to collection frequency. The extraction parameters for business call link matching refer to exclusive collection rules strongly bound to the call links of specific node pairs, avoiding interference between collection configurations of different links. This step first iterates through all node pairs within the collaborative monitoring group, retrieves the business correlation calculated in step S111, and filters out strongly correlated node pairs with a correlation greater than a preset correlation threshold. Then, it reads the business call frequency of these node pairs and configures the collection frequency according to positive correlation rules: for example, links with a call frequency > 1000 times / second are configured with 1 second / call, those between 100 and 1000 times / second with 5 seconds / call, and those < 100 times / second with 10 seconds / call. Finally, the configured parameters are bound to the extraction rules for the corresponding business call links. This step solves the problems of traditional collection strategies using unified and fixed judgment standards, missing high-frequency links, and wasting collection resources on low-frequency links, achieving precise allocation of collection resources.

[0041] Step S22 is the feature extraction step with association identifiers, which is the core execution step of data collection in step S20. The cross-node association identifier is a triple index that uniquely identifies a business call relationship. The source node identifier is the unique ID of the node initiating the business request, the target node identifier is the unique ID of the node receiving the business request, and the business call link identifier is the dedicated link ID of this call (e.g., RPC_SCH_SCA_001). The combination of these three can accurately locate any cross-node business interaction. Local side indicators refer to business link-related indicators collected by the node on its own side, such as request timeout and request packet size collected by the source node, and response time and error codes collected by the target node. Local abnormal log features refer to abnormal logs generated by the node during the business call, such as call timeout logs and connection rejection logs. This step first reads the association feature extraction parameters configured for each link in step S21; then, each node collects local monitoring data in real time according to the parameter requirements. When extracting key status indicators and abnormal feature data, the corresponding cross-node association identifier of the business call link is automatically added; simultaneously, the node's own operating indicators and local abnormal log features are collected to form a complete feature data package. This step solves the problems of traditional data collection lacking a unified association identifier, upstream and downstream data in the same link not being able to correspond, and anomalies being impossible to trace, providing a core index for subsequent data association and matching.

[0042] Step S23 is the data aggregation and transmission stage within the group, a key step in step S20 to reduce network transmission overhead. The aggregation node is the node responsible for receiving, processing, and distributing all feature data within the group, i.e., the synchronization management node determined in step S123, which is completely consistent with the aforementioned definition of the synchronization management node. The point-to-point transmission path means that nodes within the group only establish dedicated data transmission links with the aggregation node, without needing to establish direct links with other nodes, thus avoiding the large-scale network traffic congestion and bandwidth impact problems caused by the full-node mesh data interaction mode. In this step, each node will carry feature data packets with cross-node association identifiers and send them through the dedicated point-to-point link between itself and the synchronization management node; the synchronization management node receives the uploaded data from all nodes and temporarily stores it in its local high-speed cache, awaiting subsequent processing. This step solves the problems of high network bandwidth consumption and low transmission efficiency caused by the fully interconnected transmission of traditional distributed acquisition, reducing the network bandwidth consumption and transmission efficiency of the group transmission link from O( The number of steps is reduced to O(N), significantly reducing network overhead.

[0043] Step S24 involves data association, integration, and shared dataset construction, which is the core step in step S20 to form a unified data foundation. Association matching refers to the process by which the synchronization management node, based on cross-node association identifiers, aggregates and pairs the feature data of different nodes in the same business call chain. For example, it matches the request data of the source node with the response data of the target node to form a complete link call record. Redundancy filtering refers to the process of eliminating three types of invalid data: first, garbage data without valid cross-node association identifiers; second, redundant data repeatedly reported by multiple nodes; and third, out-of-bounds data not under the jurisdiction of this collaborative monitoring group. This step first traverses all feature data in the synchronization management node's cache, filtering out invalid data without valid cross-node association identifiers; then, according to the business call chain identifier in the cross-node association identifier, it associates and matches the feature data of multiple sides of the same link to form a complete call record; next, it eliminates redundant data reported repeatedly; finally, it only sends the link-related data after association matching to the corresponding source and target nodes of that link to avoid irrelevant nodes receiving redundant data, and at the same time, it forms a shared monitoring dataset within the group for subsequent cross-node verification. This step solves the problems of disorganized, redundant, and unrepresentative data collection in traditional methods, providing a high-quality data foundation for cross-node verification within a group.

[0044] To facilitate understanding by those skilled in the art, the following example of the first collaborative monitoring group scenario in the aforementioned power grid dispatch automation system is provided: This group includes a scheduling master node (ID: SCH_01), a SCADA front-end node (ID: SCA_01), a database node (ID: DB_01), and a synchronization management node (SCA_01). Step S21: The system retrieves the node pair correlation calculated in S111. The business correlation between SCH_01 and SCA_01 is 0.92, which is greater than the preset correlation threshold of 0.6. The business call frequency is 1200 times / second, therefore the collection frequency for this link is configured to be 1 second / time. The business correlation between SCA_01 and DB_01 is 0.85, which is greater than 0.6. The call frequency is 800 times / second, so the collection frequency is configured to be 2 seconds / time. Step S22: SCH_01 collects the request time (50ms) of calling SCA_01 and marks it with a cross-node association identifier: Source = SCH_01, Destination = SCA_01, Link ID = RPC_SCH_SCA_001; SCA_01 collects the response time (45ms) and error code (0) of the corresponding request and marks them with the same association identifier; at the same time, each node collects its own CPU, memory and other operating indicators. Step S23: SCH_01 and DB_01 upload feature data to the aggregation node SCA_01 through their respective point-to-point links with SCA_01. Execution step S24: After receiving the data, SCA_01 first filters out irrelevant logs without associated identifiers; then, it matches the request data of SCH_01 with the response data of SCA_01 according to the link ID (RPC_SCH_SCA_001) to form a complete call record; it removes duplicate system synchronization messages; finally, it sends the associated link data to SCH_01 and SCA_01, and at the same time, it integrates the data of the entire group to form a shared monitoring dataset within the group for subsequent anomaly verification.

[0045] In one embodiment, step S30 specifically includes: S31. For each pair of related nodes in the shared monitoring dataset within the group, extract the bidirectional association feature data of the node pair based on the cross-node association identifier. The bidirectional association feature data includes at least the forward call feature from the source node to the target node, the reverse response feature from the target node to the source node, and the corroborating feature of third-party related nodes accessing the target node. S32. Based on the consistency verification rules of the associated link, compare the bidirectional associated feature data: if the reverse response feature of the target node shows that it is running normally, and the supporting features show that the target node can be accessed normally, then the link between the source node and the target node is determined to be abnormal; if the reverse response feature of the target node shows that it is running abnormally, and the supporting features confirm that the target node access is abnormal, then the target node itself is determined to be abnormal; if there are no supporting features to confirm the abnormal reporting of the source node, and the reverse response feature of the target node has no abnormal record, then it is determined to be an isolated false alarm. S33. Generate local alarm information and group status information based on the judgment result. The local alarm information includes at least an abnormal node identifier, an abnormal type identifier, an abnormal link identifier, and a verification confidence level. The group status information includes at least a health status identifier of each node in the group, an on / off status identifier of the associated link, and a verification timestamp. S34. After the generated local alarm information and group status information are aggregated through the synchronization management node, they are reported to the central control node.

[0046] In this embodiment, as described in steps S31-S34 above, specifically: Step S31 is the bidirectional correlation feature extraction step, which is the data foundation for cross-node collaborative verification in step S30. It completely corresponds to the group-shared monitoring dataset output in step S24 and the cross-node correlation identifier defined in step S22. Among them, the correlation node pair refers to the combination of strongly correlated nodes selected in step S21 whose business correlation degree is greater than the preset correlation threshold (such as the scheduling master node SCH_01 and the SCADA front-end node SCA_01); the forward call feature refers to the local side indicators collected when the source node initiates a business request, including at least request time, request packet size, and packet success rate; the reverse response feature refers to the response side indicators returned by the target node after receiving the request, including at least response time, error code, and packet success rate; the corroborating feature refers to the verification data generated when a third-party correlation node other than the source and target nodes accesses the target node, including at least Ping connectivity results, TCP connection test results, and business call response results, which are used to corroborate the actual operating status of the target node. This step first iterates through all cross-node association identifiers in the shared monitoring dataset within the group to locate each pair of associated nodes. Then, based on the association identifiers, it extracts the forward call features and reverse response features of the node pair, while simultaneously retrieving records of third-party nodes accessing the target node from the shared dataset as supporting features. Finally, it integrates these three types of features into the bidirectional association feature data of the node pair. This step solves the problem that traditional single-node verification can only obtain data from one side and cannot distinguish between link and node anomalies, providing comprehensive feature support for subsequent consistency verification.

[0047] Step S32 is the correlation link consistency verification step, which is the core logic step in step S30 to achieve accurate anomaly determination. The correlation link consistency verification rule refers to a three-branch judgment criterion based on bidirectional feature matching logic, completely consistent with the aforementioned judgment logic: The first branch judgment logic is "target reverse response normal + circumstantial evidence accessible → link anomaly," applicable to scenarios where the target node itself is operating normally but the transmission path from the source to the target is faulty; the second branch judgment logic is "target reverse response abnormal + circumstantial evidence abnormal → target itself abnormal," applicable to scenarios where target node hardware or software failures cause service unavailability; the third branch judgment logic is "no circumstantial evidence + target no anomaly record → isolated false alarm," applicable to scenarios where the source node causes false alarms due to its own data collection anomalies or momentary jitter. This step first retrieves the bidirectional correlation feature data of each pair of related nodes and matches it sequentially against the above three-branch judgment logic: if it meets the first branch, it is marked as a link anomaly; if it meets the second branch, it is marked as a node itself abnormality; if it meets the third branch, it is marked as an isolated false alarm; for edge scenarios that cannot match the above rules (such as only circumstantial evidence abnormality but bidirectional features normal), it is marked as awaiting manual verification. This step addresses the shortcomings of traditional verification rules, such as their simplistic approach, inability to distinguish the root causes of anomalies, and high false alarm rates, thereby achieving accurate classification of anomaly types.

[0048] Step S33 is the alarm and status information generation stage, which is a key step in step S30 to realize the structured verification results. Here, the abnormal node identifier refers to the unique ID of the node determined to be abnormal (e.g., SCA_01); the abnormal type identifier refers to the classification label corresponding to the judgment logic, including three categories: link abnormality, node self-abnormality, and isolated false alarm; the abnormal link identifier refers to the cross-node association identifier of the abnormality (e.g., RPC_SCH_SCA_001); the verification confidence score refers to the judgment credibility calculated based on feature completeness, using a 0-1 normalized scale, for example, the confidence score is 0.95 when all three types of features are complete, and 0.7 when only two types of features are present; the health status identifier refers to the current operating level label of the node, including three levels: healthy, sub-healthy, and abnormal; the connectivity status identifier refers to the connectivity label of the associated link, including three categories: connected, disconnected, and congested; and the verification timestamp refers to the precise time when this verification was completed, used for subsequent time-series tracing. This step first fills in the four types of fields of local alarm information based on the judgment result of S32, and at the same time generates three types of fields of group status information by combining the verification results of all nodes and links in the group; finally, a structured alarm and status data packet is formed. This step solves the problems of missing fields, lack of confidence reference, and inability to support subsequent global analysis in traditional alarm information, and provides standardized data for information reporting and fault handling.

[0049] Step S34 is the verification information aggregation and reporting stage, which is the implementation step of step S30 to realize data aggregation within the group and interaction with the center. It is completely consistent with the responsibilities of the synchronization management node determined in step S123. In this step, the synchronization management node first receives the local alarm information and group status information generated by all nodes in the group, and performs deduplication and integration on multiple reported data on the same link (if the source and target nodes report the same link anomaly, only one complete record is retained); then, it supplements the group's global verification timestamp and synchronization management node identifier to form the final aggregation data packet; finally, it reports the aggregation data packet to the central control node through a dedicated link. This step solves the problems of high central data processing pressure and duplicate alarm interference caused by traditional multi-node independent reporting, and reduces the overhead of cross-layer transmission.

[0050] To facilitate understanding by those skilled in the art, the following example of the first collaborative monitoring group scenario in the aforementioned power grid dispatch automation system is provided: The synchronization management node for this group is SCA_01, and the core business link is SCH_01→SCA_01 (link ID: RPC_SCH_SCA_001). Step S31: SCA_01 extracts the bidirectional correlation characteristics of this link from the shared monitoring dataset within the group: the forward call characteristic is that the request reported by SCH_01 takes 50ms and has a packet success rate of 100%; the reverse response characteristic is that the response reported by SCA_01 takes 45ms and has an error code of 0; the circumstantial evidence characteristic is that the response reported by DB_01 in the same group to access SCA_01 takes 30ms and has normal connectivity. Step S32: Matching the first branch judgment logic, the reverse response of SCA_01 is normal and the circumstantial evidence is accessible, therefore, the SCH_01→SCA_01 link is determined to be abnormal. Step S33: Generate local alarm information: Abnormal node identifier = SCA_01, Abnormal type identifier = Link abnormal, Abnormal link identifier = RPC_SCH_SCA_001, Verification confidence = 0.95; Generate group status information: SCA_01 health status identifier = Healthy, RPC_SCH_SCA_001 connectivity status identifier = Disconnected, Verification timestamp = 2024-05-20T10:30:00.000Z. Step S34: SCA_01 deduplicatively aggregates the above alarms and status information, and reports them to the central control node through a dedicated link, completing the global synchronization of the group's verification results.

[0051] In one embodiment, step S40 specifically includes: S41. The central control node parses the local alarm information and group status information reported by each collaborative monitoring group, and constructs a topology mapping table that includes at least the inter-node association paths and path connectivity status across collaborative monitoring groups. S42. Based on the topology mapping table, perform correlation and source tracing on local alarm information involving cross-group business call links. If the local alarm information reported by the first collaborative monitoring group indicates that the first node is abnormal, and the local alarm information reported by the second collaborative monitoring group contains the reverse response characteristics of the second node, and the reverse response characteristics show that the second node is running abnormally, and there is a business call link between the first node and the second node, then the root cause of the abnormality of the first node is located as the cascading abnormality caused by the failure of the second node. S43. Based on the abnormal root cause location result, issue a synchronization strategy adjustment instruction to the synchronization management node of the first collaborative monitoring group. The synchronization strategy adjustment instruction includes at least reducing the data synchronization frequency pointing to the second node within the first collaborative monitoring group and / or suspending the incremental synchronization operation pointing to the second node within the first collaborative monitoring group. S44. Monitor the health score and synchronization context information of the synchronization management node in each collaborative monitoring group. When the health score of the synchronization management node in the first collaborative monitoring group is lower than the preset threshold and no failure or downtime has occurred, issue a synchronization management node reselection trigger command to the first collaborative monitoring group to trigger the synchronization management node reselection process in the collaborative monitoring group.

[0052] In this embodiment, as described in steps S41-S44 above, specifically: Step S41 is the global topology mapping table construction step, which is the foundation for achieving cross-group information integration in step S40 and completely corresponds to the group status information and local alarm information reported in step S34. The topology mapping table refers to the global logical topology structure maintained by the central control node, with cross-group business call links as edges and nodes within each collaborative monitoring group as vertices. It contains at least two types of core fields: first, the inter-node association path across collaborative monitoring groups, i.e., the business call link identifier between nodes in different groups and the group information of the source / target node; second, the path connectivity status, i.e., the link connectivity, congestion level, and other statuses marked based on the group status information reported by each group. This step first receives and parses all the local alarm information and group status information reported by the collaborative monitoring groups, extracting core data such as cross-group business call links and node running status; then, using the cross-group call links as a link, it splices and integrates the node association relationships and status data scattered in the information reported by different groups to construct a global topology mapping table; it also supports dynamic updates of the mapping table based on subsequent reported information to ensure the real-time nature of topology information. This step solves the problem of fragmented cross-group information and the inability to form a global view in traditional centralized management, and provides a core data foundation for subsequent cross-group correlation and tracing.

[0053] Step S42 is the cross-group correlation tracing and cascading anomaly localization step, which is the core logical step in step S40 to achieve accurate identification of the root cause of the anomaly. Among them, cascading anomaly refers to a non-self-fault type in which the failure of a downstream node causes anomalies in an upstream node, which is different from the node's own anomaly or link anomaly determined in step S32; the reverse response feature refers to the set of indicators reported by the nodes (second nodes) in the second collaborative monitoring group, which reflects their own operating status, and is completely consistent with the cross-node correlation identifier defined in step S22 and the reverse response feature definition in step S32. This step first retrieves local alarm information related to cross-group business call links based on the topology mapping table, locating the first node (located in the first collaborative monitoring group) and the second node (located in the second collaborative monitoring group) with upstream and downstream call relationships. Then, it matches three criteria: first, anomaly information of the first node reported by the first collaborative monitoring group; second, reverse response characteristics of the second node reported by the second collaborative monitoring group indicating operational anomalies; and third, the topology mapping table confirms the existence of a valid business call link between the first and second nodes. When all three criteria are met, the possibility of a fault in the first node itself is ruled out, and the root cause of the anomaly is located as a cascading anomaly caused by a fault in the second node. This step solves the problems of isolated cross-group alarms, delayed root cause analysis, and easy misjudgment as node-specific faults in traditional methods, achieving accurate source tracing of cross-group anomalies.

[0054] Step S43 is the dynamic optimization stage of the synchronization strategy, which is the execution stage of step S40 to reduce the impact of faults and optimize synchronization efficiency. It corresponds to the mechanism by which the synchronization management node continuously executes data synchronization operations within the group. The synchronization strategy adjustment instruction refers to the control instruction issued by the central control node to the synchronization management node within the group to adjust synchronization behavior. In addition to reducing the synchronization frequency and pausing incremental synchronization, it may also include extended instructions such as resuming synchronization and switching synchronization links. This step first determines the group to which the faulty node (second node) belongs and the affected caller group (first collaborative monitoring group) based on the anomaly root cause location results output in S42. Then, it issues targeted adjustment instructions to the synchronization management node of the first collaborative monitoring group: if the second node is in a sub-healthy state, it issues an instruction to reduce the synchronization frequency pointing to the second node to reduce ineffective synchronization overhead; if the second node is in a faulty and downtime state, it issues an instruction to pause incremental synchronization operations pointing to the second node to avoid synchronization blockage. After receiving the instructions, the synchronization management node dynamically adjusts the synchronization strategy within the group without the central node's intervention in the specific synchronization execution. This step solves the problems of rigid traditional synchronization strategies, network resource waste and synchronization blockage caused by maintaining full synchronization in fault scenarios, and improves synchronization reliability in fault scenarios.

[0055] Step S44 is the active reselection triggering step for the sub-healthy synchronization management node. It is a key step in perfecting the two-layer fault tolerance mechanism in step S40 and must be strictly distinguished from the spontaneous reselection process after a failure in steps S131-S133. The preset threshold and the preset health threshold mentioned in step S132 use the same normalized scale (e.g., the 0-1 range, for example, set to 0.5) to determine whether the synchronization management node has entered a sub-healthy state. "No failure" refers to a sub-healthy state where the synchronization management node can still maintain basic communication capabilities and has not triggered the fault takeover process described in steps S131-S133; this is a prerequisite for triggering this step. The synchronization management node reselection process refers to the existing standard process within the collaborative monitoring group for reselecting the synchronization management node (e.g., the process in steps S131-S133 or the initial election process). This step involves the central control node continuously monitoring the health scores and synchronization context information of the synchronization management nodes within each collaborative monitoring group. When a synchronization management node in a group is found to have a health score below a preset threshold but can still maintain basic communication (without crashing), it is determined that the node is in a sub-healthy state, and prolonged operation may lead to synchronization anomalies. At this time, the center proactively issues a synchronization management node reselection trigger command to the group, triggering the execution of a standard reselection process within the group to select a node with better health to take over the responsibilities. This step solves the problem that traditional fault tolerance mechanisms only cover failure and downtime scenarios and cannot cope with the implicit synchronization risks caused by sub-healthy nodes. Together with the fault takeover process in steps S131~S133, it forms a two-layer fault tolerance system of "proactive intervention in sub-health + spontaneous takeover after failure," further improving the reliability of synchronization management.

[0056] To facilitate understanding by those skilled in the art, an example of a cross-group scenario in a power grid dispatch automation system is provided: The first collaborative monitoring group is designated as the scheduling master station group (including the scheduling master station node SCH_01, and the synchronization management node within the group is SCH_MGR), and the second collaborative monitoring group is designated as the SCADA front-end group (including the SCADA front-end node SCA_01, and the synchronization management node within the group is SCA_MGR). Step S41: The central control node receives information reported by both groups, parses it to find that there is a cross-group service call link LINK_CROSS_001 between SCH_01 and SCA_01, and the current connectivity status of the link is "connected," and constructs a global topology mapping table containing this link. Step S42: The first collaborative monitoring group reports an exception information indicating that SCH_01 failed to call LINK_CROSS_001, and the second collaborative monitoring group reports that the reverse response characteristics of SCA_01 show a CPU utilization rate of 95% and a response timeout; the central control node checks the topology mapping table to confirm the existence of a cross-group call relationship between the two, and determines that the exception of SCH_01 is a cascading exception caused by a fault in SCA_01. Step S43: The center issues an instruction to the synchronization management node SCH_MGR of the first collaborative monitoring group to suspend the incremental synchronization operation pointing to SCA_01 within the first group, to avoid invalid synchronization consuming bandwidth. Step S44: The center continuously monitors and finds that the health score of the synchronization management node SCH_MGR of the first group drops to 0.4 (below the preset threshold of 0.5), but the node can still respond to heartbeat requests and has not triggered the failure downtime process; the center then issues a synchronization management node reselection trigger instruction to the first collaborative monitoring group, triggering the reselection process within the group, and finally selects SCH_02 with a health score of 0.78 as the new synchronization management node, completing the active replacement of the sub-healthy node.

[0057] In one embodiment, a distributed collaborative monitoring and data synchronization system for multi-node information systems is provided, which corresponds to the distributed collaborative monitoring and data synchronization method for multi-node information systems described in the above embodiments. This distributed collaborative monitoring and data synchronization system for multi-node information systems includes: The grouping module is used to divide multiple collaborative monitoring groups based on the business association attributes and network deployment location of each node, configure association feature extraction rules and collaborative judgment rules for each collaborative monitoring group, and determine the synchronization management node for each collaborative monitoring group. The data acquisition module is used to collect local monitoring data in real time by nodes in each collaborative monitoring group, extract key status indicators and abnormal feature data according to the correlation feature extraction rules, and perform point-to-point interaction of the extracted key status indicators and abnormal feature data within the group to form a shared monitoring dataset within the group. The verification module is used by nodes in each collaborative monitoring group to perform cross-node verification and anomaly determination based on the shared monitoring dataset and collaborative judgment rules within the group, generate local alarm information and group status information, and report them to the central control node. The data synchronization module is used to control the synchronization management nodes of each collaborative monitoring group to continuously perform data synchronization operations during the data interaction and anomaly judgment process within each collaborative monitoring group: when configuration data changes and a corresponding version identifier is generated, incremental point-to-point synchronization is performed on the configuration data within the group; point-to-point synchronization is continuously performed on the running monitoring data within the group; when a node in the group goes offline and reconnects, the interruption resume transmission is triggered to fill in the missing configuration data and running monitoring data; The management and control module is used by the central management and control node to aggregate local alarm information and group status information reported by each collaborative monitoring group, and to perform global management and control over the collaborative monitoring and data synchronization process of each collaborative monitoring group.

[0058] Optional, also includes: The fault perception module is used to obtain the synchronization context information of the faulty node when a fault is detected in the synchronization management node. The synchronization context information includes at least the current effective version identifier of the configuration data and the synchronization progress offset of the running monitoring data.

[0059] The candidate node filtering module is used to filter out candidate nodes whose health scores meet the preset health threshold and whose configuration data corresponding to the current effective version identifier have been fully cached from the remaining nodes after removing faulty nodes in the same collaborative monitoring group.

[0060] The new node selection module is used to determine the node with the smallest difference between the synchronization progress offset of the running monitoring data and the faulty node among the candidate nodes as the new synchronization management node.

[0061] Specific limitations regarding a distributed collaborative monitoring and data synchronization system for multi-node information systems can be found in the above description of the distributed collaborative monitoring and data synchronization method for multi-node information systems, and will not be repeated here. Each module in the aforementioned distributed collaborative monitoring and data synchronization system for multi-node information systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0062] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 2As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database is used for data storage, data processing, and data analysis. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a distributed collaborative monitoring and data synchronization method for multi-node information systems.

[0063] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a distributed collaborative monitoring and data synchronization method for a multi-node information system.

[0064] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements a distributed collaborative monitoring and data synchronization method for a multi-node information system.

[0065] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0067] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A distributed collaborative monitoring and data synchronization method for multi-node information systems, characterized in that, Includes the following steps: Based on the business association attributes and network deployment location of each node, multiple collaborative monitoring groups are divided. Association feature extraction rules and collaborative judgment rules are configured for each collaborative monitoring group, and the synchronization management node of each collaborative monitoring group is determined. Each node in the collaborative monitoring group collects local monitoring data in real time, extracts key status indicators and abnormal feature data according to the correlation feature extraction rules, and exchanges the extracted key status indicators and abnormal feature data point by point within the group to form a shared monitoring dataset within the group. Based on the shared monitoring dataset and collaborative judgment rules within the group, the nodes in each collaborative monitoring group perform cross-node cross-verification and anomaly judgment, generate local alarm information and group status information, and report them to the central control node. The collaborative judgment rules include consistency verification rules for associated links based on cross-node association identifiers. Nodes within each collaborative monitoring group perform cross-node cross-verification and anomaly judgment within the group based on the shared monitoring dataset and collaborative judgment rules, generating local alarm information and group status information, and reporting them to the central control node. Specifically, this includes: For each pair of related nodes in the shared monitoring dataset within the group, bidirectional association feature data of the node pair is extracted based on the cross-node association identifier. The bidirectional association feature data includes at least the forward call feature from the source node to the target node, the reverse response feature from the target node to the source node, and the corroborating feature of third-party related nodes accessing the target node. Based on the consistency verification rules of the associated links, the bidirectional associated feature data is compared: if the reverse response feature of the target node shows that it is running normally, and the supporting features show that the target node can be accessed normally, then the link between the source node and the target node is determined to be abnormal; if the reverse response feature of the target node shows that it is running abnormally, and the supporting features confirm that the target node access is abnormal, then the target node itself is determined to be abnormal; if there are no supporting features to confirm the abnormal reporting of the source node, and the reverse response feature of the target node has no abnormal record, then it is determined to be an isolated false alarm. Based on the judgment result, local alarm information and group status information are generated. The local alarm information includes at least the abnormal node identifier, abnormal type identifier, abnormal link identifier and verification confidence level. The group status information includes at least the health status identifier of each node in the group, the on / off status identifier of the associated link and the verification timestamp. The generated local alarm information and group status information are aggregated through the synchronization management node and then reported to the central control node; The central control node aggregates the local alarm information and group status information reported by each collaborative monitoring group, and performs global control over the collaborative monitoring and data synchronization process of each collaborative monitoring group. During the process of data interaction and anomaly detection within each collaborative monitoring group, the synchronization management node of each collaborative monitoring group continuously performs data synchronization operations within the group: When configuration data changes and a corresponding version identifier is generated, perform incremental point-to-point synchronization within the group on the configuration data; continuously perform point-to-point synchronization within the group on the runtime monitoring data. When a node in the group reconnects offline, it triggers a resume function to fill in the missing configuration data and runtime monitoring data.

2. The distributed collaborative monitoring and data synchronization method for multi-node information systems as described in claim 1, characterized in that, The division of each node into multiple collaborative monitoring groups based on its business association attributes and network deployment location specifically includes: Based on the business association attributes of each node, obtain the business call chain and business call frequency between any two nodes, and quantify the business association degree between nodes based on the business call chain and business call frequency; Based on the network deployment location of each node, obtain the network topology connection relationship and network round-trip time between any two nodes, and quantify the network proximity between nodes based on the network topology connection relationship and network round-trip time. Based on the business relevance and network proximity between nodes, a preset clustering algorithm is used to group nodes that meet the preset affinity conditions into the same collaborative monitoring group. The preset affinity condition is that the network round-trip latency between nodes is less than a preset latency threshold, and the frequency of service calls between nodes is greater than a preset frequency threshold.

3. The distributed collaborative monitoring and data synchronization method for multi-node information systems as described in claim 1, characterized in that, The determination of the synchronization management node for each collaborative monitoring group specifically includes: Collect resource load parameters of each node in the collaborative monitoring group. The resource load parameters include at least CPU idle rate, memory remaining amount and network bandwidth utilization. Calculate the node health score based on the resource load parameters of each node; The node with the highest health score within the same collaborative monitoring group is designated as the synchronization management node for that group.

4. The distributed collaborative monitoring and data synchronization method for multi-node information systems as described in claim 3, characterized in that, Also includes: When a failure is detected in the synchronization management node, the synchronization context information of the failure node is obtained. The synchronization context information includes at least the current effective version identifier of the configuration data and the synchronization progress offset of the running monitoring data. In the same collaborative monitoring group, after removing faulty nodes, select candidate nodes whose health scores meet the preset health threshold and whose configuration data corresponding to the current effective version identifier has been fully cached. The node with the smallest difference between the synchronization progress offset of the running monitoring data and the faulty node among the candidate nodes is determined as the new synchronization management node.

5. The distributed collaborative monitoring and data synchronization method for multi-node information systems as described in claim 2, characterized in that, The nodes within each collaborative monitoring group collect local monitoring data in real time, extract key status indicators and abnormal feature data according to the correlation feature extraction rules, and then exchange the extracted key status indicators and abnormal feature data point-to-point within the group to form a shared monitoring dataset within the group, specifically including: For any two nodes in the collaborative monitoring group whose business correlation is greater than a preset correlation threshold, based on the pre-configured correlation feature extraction rules, the correlation feature extraction parameters that match the business call chain of the node pair are determined. The correlation feature extraction parameters include at least the feature collection frequency, and the collection frequency is positively correlated with the business call frequency of the node pair. Each node collects local monitoring data in real time based on determined correlation feature extraction parameters and extracts key status indicators and abnormal feature data containing cross-node correlation identifiers. The cross-node correlation identifiers include at least the source node identifier, the target node identifier, and the business call link identifier. The local monitoring data includes at least the node's own operating indicators, local indicators of the business call link, and local abnormal log features. The nodes will extract key status indicators and abnormal feature data carrying cross-node association identifiers and send them to the synchronization management node, with the synchronization management node as the aggregation node and the point-to-point interaction between each node in the group and the synchronization management node as the transmission path. The synchronization management node performs association matching and redundancy filtering on the received key status indicators and abnormal feature data based on cross-node association identifiers. After removing irrelevant data that does not carry valid cross-node association identifiers, the key status indicators and abnormal feature data that have been successfully matched are sent to the corresponding nodes in the associated node pairs to form a shared monitoring dataset within the group.

6. The distributed collaborative monitoring and data synchronization method for multi-node information systems as described in claim 1, characterized in that, The central control node aggregates local alarm information and group status information reported by each collaborative monitoring group, and performs global control over the collaborative monitoring and data synchronization process of each collaborative monitoring group, specifically including: The central control node parses the local alarm information and group status information reported by each collaborative monitoring group, and constructs a topology mapping table that includes at least the inter-node association paths and path connectivity status across collaborative monitoring groups. Based on the topology mapping table, the local alarm information involving cross-group business call links is correlated and traced. If the local alarm information reported by the first collaborative monitoring group indicates that the first node is abnormal, and the local alarm information reported by the second collaborative monitoring group contains the reverse response characteristics of the second node, and the reverse response characteristics show that the second node is running abnormally, and there is a business call link between the first node and the second node, then the root cause of the abnormality of the first node is located as the cascading abnormality caused by the failure of the second node. Based on the root cause localization results, a synchronization strategy adjustment instruction is issued to the synchronization management node of the first collaborative monitoring group. The synchronization strategy adjustment instruction includes at least reducing the data synchronization frequency pointing to the second node within the first collaborative monitoring group and / or suspending the incremental synchronization operation pointing to the second node within the first collaborative monitoring group. The system monitors the health score and synchronization context information of the synchronization management nodes in each collaborative monitoring group. When the health score of the synchronization management node in the first collaborative monitoring group is found to be lower than the preset threshold and no failure or downtime has occurred, a synchronization management node reselection trigger command is sent to the first collaborative monitoring group to trigger the synchronization management node reselection process in that collaborative monitoring group.

7. A distributed collaborative monitoring and data synchronization system for multi-node information systems, used to implement the steps of the distributed collaborative monitoring and data synchronization method for multi-node information systems as described in any one of claims 1-6, characterized in that, include: The grouping module is used to divide multiple collaborative monitoring groups based on the business association attributes and network deployment location of each node, configure association feature extraction rules and collaborative judgment rules for each collaborative monitoring group, and determine the synchronization management node for each collaborative monitoring group. The data acquisition module is used to collect local monitoring data in real time by nodes in each collaborative monitoring group, extract key status indicators and abnormal feature data according to the correlation feature extraction rules, and perform point-to-point interaction of the extracted key status indicators and abnormal feature data within the group to form a shared monitoring dataset within the group. The verification module is used by nodes in each collaborative monitoring group to perform cross-node verification and anomaly determination based on the shared monitoring dataset and collaborative judgment rules within the group, generate local alarm information and group status information, and report them to the central control node. The data synchronization module is used to control the synchronization management node of each collaborative monitoring group to continuously perform data synchronization operations during the data interaction and anomaly judgment process within each collaborative monitoring group: when configuration data changes and a corresponding version identifier is generated, incremental point-to-point synchronization is performed on the configuration data within the group; point-to-point synchronization is continuously performed on the running monitoring data within the group. When a node in the group reconnects offline, it triggers a resume function to fill in the missing configuration data and runtime monitoring data. The management and control module is used by the central management and control node to aggregate local alarm information and group status information reported by each collaborative monitoring group, and to perform global management and control over the collaborative monitoring and data synchronization process of each collaborative monitoring group.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the distributed collaborative monitoring and data synchronization method for a multi-node information system as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the distributed collaborative monitoring and data synchronization method for a multi-node information system as described in any one of claims 1-6.

Images