Trinity full-link intelligent monitoring system from new energy station to centralized control center

Abstract

This application relates to the field of monitoring technology for new energy power plants, and discloses a three-in-one full-link intelligent monitoring system from a new energy power plant to a centralized control center, including a data acquisition and transmission layer, a data processing and analysis layer, and an application display layer. The system uniformly collects network performance, application status, and server resource data, uses a business topology model for correlation mapping, and achieves automatic fault location through a cross-layer root cause analysis engine. When an application malfunctions, the system can automatically trace the dependency path, accurately identify the root cause of the lowest-level fault, and effectively solve the problems of difficult fault location and alarm information overload in traditional monitoring systems. This application realizes a shift from a passive response to a proactive early warning operation and maintenance mode, improving the operational reliability and maintenance efficiency of new energy power plants.

Description

Technical Field

[0001] This application relates to the field of monitoring technology for new energy power stations, specifically a three-in-one full-link intelligent monitoring system from a new energy power station to a central control center. Background Technology

[0002] With the large-scale construction and distributed access of new energy power plants such as wind power and photovoltaics, the complexity of their operation and maintenance management has increased significantly.

[0003] Currently, the central control center typically uses decentralized and independent systems to monitor its subordinate sites, monitoring network devices, server hardware, or applications in isolation. This siloed monitoring model has inherent flaws: when business applications malfunction, maintenance personnel struggle to quickly determine whether the root cause lies in the application itself, the server resources it hosts, or the underlying network transmission links. This leads to inefficient fault location, long average repair times, and maintenance work often relegated to a reactive, firefighting-like state. Furthermore, due to the lack of a unified business topology perspective, numerous derivative alarms triggered by the same root cause can emerge simultaneously, creating an alarm storm that further interferes with fault diagnosis and handling.

[0004] Therefore, there is an urgent need for an end-to-end intelligent monitoring solution that can achieve collaborative analysis of networks, applications, and hardware, and accurately locate the root cause of faults. Summary of the Invention

[0005] The purpose of this application is to provide a three-in-one full-link intelligent monitoring system from new energy power plants to the central control center, so as to solve the technical problems mentioned in the background art.

[0006] To achieve the above objectives, this application discloses the following technical solution: a three-in-one full-link intelligent monitoring system from a new energy power station to a central control center, comprising: The data acquisition and transmission layer is deployed on the side of the new energy power station and is configured to collect network performance data, application status data and server resource data through a unified acquisition frequency and time synchronization mechanism. The data processing and analysis layer, deployed at the central control center, includes a unified spatiotemporal correlation module and a cross-layer root cause analysis engine. The unified spatiotemporal correlation module is configured to assign a unified timestamp and device identifier to all collected data, and based on a predefined business topology model, to correlate and map the network performance data, the application status data, and the server resource data to generate a full-link status dataset with correlation relationships. The cross-layer root cause analysis engine is configured to perform collaborative analysis on the full-link status dataset. The collaborative analysis includes: when an application status anomaly is detected, automatically locating its dependent nodes in the business topology model, concurrently querying the performance data of the dependent nodes before and after the anomaly time point, and based on preset fault propagation rules, determining the lowest-level dependent node that simultaneously experiences performance degradation as the root cause fault point and generating a root cause alarm. The application presentation layer is configured to visualize the business topology model and receive the output of the cross-layer root cause analysis engine, highlighting the root cause failure points on the topology view.

[0007] Optionally, the data acquisition and transmission layer includes: A lightweight proxy module is deployed on a server at the site and configured to collect the network performance data, application status data, and server resource data. The data aggregation module is configured to encapsulate the collected data into a message with the unified timestamp and the device identifier, and send it to the central control center through a dual-link transmission mechanism.

[0008] Optionally, the collection of application status data includes service port availability checks; the service port availability checks are implemented by simulating the establishment of a TCP connection with the service port of the target application, and recording the complete handshake time from sending the connection request to receiving the response. When the handshake time exceeds a preset threshold, the lightweight proxy module marks the corresponding application status data as a port response timeout state and sends the application status data to the data aggregation module.

[0009] Optionally, the process of constructing the business topology model includes: The physical port connections between network devices within the site are detected using the LLDP protocol to establish the network layer topology. Analyze the pre-configured server and application deployment list to determine the host server running each application process and its resource usage, and establish an application deployment mapping table; Based on predefined business flow rules and combined with network topology and deployment mapping table, the end-to-end logical communication path between the site monitoring unit and the central control center server is derived to form the business topology model.

[0010] Optionally, when the cross-layer root cause analysis engine receives application state data marked as port response timeout and performs collaborative analysis, it locates the application process node that generated the data in the business topology model and traverses all dependent nodes downwards along the end-to-end logical communication path.

[0011] Optionally, when the cross-layer root cause analysis engine traverses all dependent nodes, it prioritizes checking the lowest-level network device nodes. When it finds that the network performance data of a network device node is continuously abnormal within a preset time window, it determines that the network device node as the root cause failure point.

[0012] Optionally, the cross-layer root cause analysis engine is further configured to use a linear regression algorithm to fit continuously collected historical disk usage data for server disk utilization and calculate the disk capacity consumption rate; when the prediction result shows that the remaining available space will be exhausted within a set warning period, a disk capacity shortage warning is generated, and the disk capacity shortage warning is used as an input parameter of the cross-layer root cause analysis engine to participate in the comprehensive weight calculation when assessing the system health status.

[0013] Optionally, the data processing and analysis layer further includes an alarm convergence module; the alarm convergence module is configured to suppress all derivative alarms generated by upper-layer applications and services when the underlying device is determined to be the root cause of the failure, based on the dependency relationships defined in the business topology model.

[0014] Optionally, after receiving the output of the alarm convergence module, the application presentation layer highlights only the nodes identified as root cause faults in the visualization interface, and displays the corresponding nodes of the suppressed derivative alarms in a normal state.

[0015] Optionally, the data processing and analysis layer uses a time series database to store the full-link state dataset and performs a hierarchical retention strategy on the stored data. The hierarchical retention strategy includes: retaining the data with full precision for a first predetermined time, and after the first predetermined time, retaining only the downsampled low-precision data and transferring it to a low-cost storage medium.

[0016] Beneficial Effects: The integrated intelligent monitoring system from new energy power plants to the central control center, as described in this application, breaks down monitoring silos between networks, applications, and hardware through unified data collection and correlation mapping, achieving transparency and visualization of the entire link status. Through the collaboration of a cross-layer root cause analysis engine and a business topology model, it can automatically and quickly locate the root cause of the fault at the lowest level when application anomalies occur. This transforms the operation and maintenance mode from passive response to proactive early warning and precise handling, shortening the average fault repair time and improving the reliability of new energy power plant operation and the scheduling and command efficiency of the central control center. Simultaneously, the system effectively suppresses derivative alarms through an alarm convergence mechanism, reducing operational interference and improving the effectiveness and operability of alarms. Attached Figure Description

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

[0018] Figure 1 This is a system block diagram of the three-in-one full-link intelligent monitoring system from new energy power station to central control center provided in the embodiments of this application. Detailed Implementation

[0019] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below. With the rapid development of the new energy industry, wind power, photovoltaic and other new energy power plants are characterized by both large-scale centralized construction and widespread distributed access, resulting in an exponential increase in the number of power plants, equipment scale and business complexity. These power plants are generally distributed in areas with large geographical spans and complex environmental conditions, and their operating status directly affects the power supply stability of the power system. As the core of remote operation and maintenance and dispatch, the central control center needs to achieve comprehensive monitoring and centralized management of dozens or even hundreds of subordinate power plants, which places extremely high demands on the refinement and efficiency of operation and maintenance management.

[0020] However, current monitoring systems in centralized control centers generally adopt a "siloed" distributed architecture, forming three independent monitoring islands: network, application, and hardware. 1. Data collection level: Network device monitoring focuses on indicators such as port traffic and packet loss rate of routers and switches, server hardware monitoring only focuses on resource status such as CPU utilization, memory usage, and disk space, and application monitoring only checks business indicators such as service availability and response time. The three use different collection frequencies, data formats and storage methods, and lack a unified time synchronization mechanism and device identification system, which makes it impossible to directly correlate and compare various types of data. 2. Fault location level: Due to the lack of data interoperability, when business applications experience abnormalities (such as service port response timeouts), maintenance personnel need to manually query data in multiple independent systems and check for possible causes such as "application failure itself - server resource exhaustion - network transmission interruption". This is not only cumbersome and time-consuming, but also prone to misjudgment due to data asynchrony and missing correlation logic, resulting in a high mean time to repair (MTTR) and maintenance work is always in a passive firefighting state of "repairing after the fault occurs". 3. Alarm Management Level: Due to the lack of a unified business topology perspective, the system cannot identify the causal relationships between alarms. When critical underlying equipment (such as core switches and host servers) fails, it will trigger multiple applications and services that depend on it to generate alarms simultaneously, forming an "alarm storm." A large number of derivative alarms and root cause alarms are mixed together, which not only increases the information screening burden of operation and maintenance personnel, but may also cause the core fault point to be flooded, further prolonging the fault handling cycle. 4. Topology Awareness Level: Existing monitoring systems can only provide a single-dimensional topology view (such as pure network physical topology or pure application deployment list), lacking end-to-end business logic topology mapping from new energy power station monitoring units to the central control center server. Maintenance personnel cannot intuitively grasp the dependency relationship between "application-server-network devices" and find it difficult to quickly trace the path of fault propagation.

[0021] These shortcomings directly lead to low efficiency and insufficient reliability in the operation and maintenance management of new energy power plants by the centralized control center, making it unable to meet the monitoring needs after large-scale new energy access. Specifically, decentralized data collection results in data fragmentation, making it difficult to support end-to-end status analysis; the lack of a unified business topology leads to unclear fault location paths; the absence of an alarm convergence mechanism exacerbates operation and maintenance interference; and the passive response mode leads to an expansion of the scope of fault impact.

[0022] Therefore, there is an urgent need for an end-to-end intelligent monitoring solution that can break down monitoring silos, establish unified data associations, achieve cross-layer root cause tracing, and suppress derivative alarms, in order to solve the core problems existing in the current technology, such as opaque status across the entire link, low accuracy of fault location, passive operation and maintenance mode, and poor alarm effectiveness.

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application. Secondly, in this document, the term "comprising" is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0024] This embodiment presents a three-in-one full-link intelligent monitoring system from the new energy power station to the central control center, such as... Figure 1 As shown, it includes: a data acquisition and transmission layer, a data processing and analysis layer, and an application presentation layer, as detailed below.

[0025] The data acquisition and transmission layer is deployed on the side of the new energy power station and is configured to collect network performance data, application status data and server resource data through a unified acquisition frequency and time synchronization mechanism.

[0026] In practical implementation, the unified time synchronization mechanism adopts the NTPv4 protocol, with a time synchronization accuracy of ≤1ms, ensuring the spatiotemporal consistency of data across devices. The collection frequency is dynamically configured according to the indicator type: network performance data (including port traffic, packet loss rate, and transmission latency) is collected at a high frequency of 1 second / time; server resource data (including CPU utilization, memory usage, and disk I / O) is collected at a medium frequency of 5 seconds / time; and application status data (including service availability and port response status) is collected at a frequency of 10 seconds / time, balancing real-time performance and resource consumption.

[0027] The data processing and analysis layer, deployed at the central control center, includes a unified spatiotemporal correlation module and a cross-layer root cause analysis engine.

[0028] The unified spatiotemporal correlation module is configured to assign a unified timestamp and device identifier to all collected data, and based on a predefined business topology model, it correlates and maps network performance data, application status data, and server resource data to generate a full-link status dataset with correlation relationships.

[0029] The cross-layer root cause analysis engine is configured to perform collaborative analysis on the entire link status dataset. The collaborative analysis includes: when an application status anomaly is detected, automatically locating its dependent nodes in the business topology model, concurrently querying the performance data of the dependent nodes within ±3 collection cycles before and after the abnormal time point, and based on the preset fault propagation rules, determining the lowest-level dependent node that simultaneously experiences performance degradation as the root cause fault point and generating a root cause alarm.

[0030] In practice, the timestamp format is UTC time with millisecond precision. The device identifier consists of "site number - device type - unique device serial number", such as "WF-001-SW-20230510001". The business topology model includes a three-level dependency relationship of "application process - server - network device" and an end-to-end logical communication path.

[0031] Furthermore, the determination of root cause failure points is achieved through a root cause confidence calculation model, the formula of which is as follows: in, Let be the root cause confidence of the i-th dependent node (within the range [0,1]). When the root cause confidence of a dependent node exceeds 0.8, it is determined to be a root cause failure point. The fault propagation weight coefficient (value 0.6, obtained by gradient descent based on 1000 sets of fault simulation data) characterizes the ability of node faults to propagate the impact on upper-layer applications. The failure propagation probability of the i-th node (range [0,1]) is determined by the dependency level of that node in the business topology model (bottom network nodes). server node Application Node ); The performance degradation magnitude of the i-th node within the abnormal time window (e.g., network latency degradation magnitude = abnormal latency - normal average latency, resource utilization degradation magnitude = abnormal utilization - normal threshold). This is the average performance baseline value for this type of node (obtained from statistical data of normal operation during the first 30 days after system deployment). The node importance weight coefficient (with a value of 0.4, and...) satisfy This represents the core importance of a node in the business chain; The importance index of the i-th node (range [0.5, 1.0]) is determined based on whether the node is a critical path node and the number of services it carries (core switch). Edge switch ordinary application server ); This is the time decay coefficient (valued at 0.3, determined experimentally based on the fault propagation time characteristics). The duration of the performance anomaly of the i-th node (in seconds) is the time from the first detection of the anomaly to the current moment.

[0032] The application presentation layer is configured as a visual business topology model and receives the output of the cross-layer root cause analysis engine, highlighting the root cause failure points on the topology view.

[0033] In practice, the business topology model is displayed as a hierarchical topology diagram, supporting zooming, dragging, and node drill-down. Highlighting can be achieved using methods such as flashing red indicators combined with fault icon displays.

[0034] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment ensures the spatiotemporal consistency and balance of acquisition efficiency of network, application, and hardware data through a unified time synchronization mechanism and differentiated acquisition frequency design at the data acquisition and transmission layers, laying a data foundation for subsequent correlation analysis. The unified spatiotemporal correlation module transforms the originally fragmented multi-source data into a full-link status dataset with clear dependencies through standardized timestamps and device identifiers, as well as its combination with the business topology model. This breaks down the silo barriers of traditional "vertical" monitoring from the bottom layer and realizes the transparent presentation of the full-link status. The cross-layer root cause analysis engine innovatively adopts a root cause confidence calculation model, comprehensively considering multiple dimensions such as fault propagation capability, node importance, performance degradation magnitude, and anomaly duration. This avoids the one-sidedness of judging by a single indicator and can accurately identify the root cause fault point at the lowest level, replacing the tedious process of traditional manual troubleshooting. This transforms the operation and maintenance mode from "passive firefighting" to "proactive early warning and precise handling," effectively shortening the average fault repair time. At the same time, the application's topology visualization and root cause highlighting functions allow operation and maintenance personnel to intuitively grasp the fault location and correlation, further improving fault handling efficiency. The overall system, through a full-process design of "unified data collection - correlation mapping - intelligent analysis - visualization display," comprehensively improves the reliability of new energy power plant operation and the scheduling and command efficiency of the central control center, providing an efficient solution for operation and maintenance management after large-scale new energy access.

[0035] As an optional implementation of this embodiment, the data acquisition and transmission layer includes: A lightweight proxy module is deployed on the server at the site and configured to collect network performance data, application status data, and server resource data. The data aggregation module is configured to encapsulate the collected data into messages with a unified timestamp and device identifier, and send them to the central control center through a dual-link transmission mechanism.

[0036] In practical implementation, the lightweight proxy module adopts a containerized deployment approach, with an image size not exceeding 50MB, CPU utilization not exceeding 2%, and memory usage not exceeding 100MB, avoiding the consumption of core business server resources. The lightweight proxy module utilizes eBPF (Extended Berkeley Packet Filter) technology to achieve non-intrusive data collection without modifying business application code. It obtains network packet characteristics by hooking kernel-mode functions, acquires server resource status by reading the / proc file system, and probes application port status through the Socket interface.

[0037] Secondly, the message adopts JSON format, with fields including "timestamp", "device_id", "data_type", "metrics", and "status". The "metrics" field stores specific indicator key-value pairs according to data type. The dual-link transmission mechanism includes a primary link (fiber optic private network, using TCP protocol to ensure data reliability) and a backup link (4G / 5G wireless private network, using UDP protocol to ensure real-time transmission). The data aggregation module monitors the connectivity status of the primary link in real time. When the primary link packet loss rate is detected to be no less than 3% or the latency is no less than 100ms, it automatically switches to the backup link for transmission, with a switching time of no more than 1 second. At the same time, the transmitted data adopts the LZ4 compression algorithm (compression ratio no less than 3:1) to reduce bandwidth consumption, and key indicator data (such as application port response timeout, network packet loss rate exceeding the standard) adopts encrypted transmission (AES-256 algorithm) to ensure data security.

[0038] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment employs containerized deployment and eBPF non-intrusive data acquisition technology in its lightweight agent module. This ensures comprehensive collection of three types of core data while minimizing resource consumption on the new energy power station's business servers, avoiding the problem of traditional acquisition agents affecting normal business operation due to excessive resource consumption. Its multi-dimensional acquisition methods (kernel-mode hooking, file system reading, and socket probing) ensure the comprehensiveness and accuracy of data collection. The data aggregation module encapsulates data using standardized message formats, providing standardized input for subsequent unified spatiotemporal correlation. The dual-link transmission mechanism, combined with automatic primary / backup switching logic, solves the problem of data loss caused by a single transmission link interruption, ensuring the continuity and reliability of data transmission to the central control center. The combination of LZ4 compression and AES-256 encryption reduces bandwidth consumption and ensures security during data transmission, avoiding the risk of leakage or tampering of critical monitoring data. This layer design, through the combination of "lightweight acquisition + reliable transmission," provides high-quality, highly available data source support for upper-layer data processing and analysis, improving the overall reliability and data processing efficiency of the full-link intelligent monitoring system.

[0039] Based on the data acquisition and transmission layer composed of the aforementioned lightweight proxy module and data aggregation module, as a further optional implementation method in this embodiment, the acquisition of application status data includes service port availability checking; the service port availability checking is implemented by simulating the establishment of a TCP connection with the service port of the target application, and recording the complete handshake time from sending the connection request to receiving the response. When the handshake time exceeds a preset threshold, the lightweight proxy module marks the corresponding application status data as a port response timeout state, and sends the application status data to the data aggregation module.

[0040] In practice, the service port availability check process includes: 1) The lightweight proxy module sends a SYN packet to the target port according to the pre-configured application port list (including application name, target IP, port number, protocol type, such as "PV data acquisition service-192.168.1.10-8080-TCP"); 2) Record the SYN message sending time ; 3) Wait for the SYN-ACK packet returned by the target port and record the reception time. ; 4) Send an ACK packet to the target port to complete the three-way handshake, and record the sending time. Complete handshake time .

[0041] Secondly, the design principle for the preset threshold corresponding to the handshake time is: based on the handshake time statistics of the application port during its historical normal operation, the 95th percentile value is taken. and set a threshold ( The threshold is the standard deviation of the historical handshake time, ensuring that the threshold can effectively identify anomalies while avoiding misjudgments. For example, if the historical 95th percentile handshake time of a photovoltaic data acquisition service port is 20ms and the standard deviation is 5ms, then its preset threshold is 35ms.

[0042] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment realizes the service port availability check by simulating the TCP three-way handshake process. It can realistically restore the actual communication status of the application port. Compared with the traditional detection method that only sends connection requests without waiting for the complete handshake, it can more accurately reflect the service response capability of the port. The calculation of the complete handshake time covers the entire process of request sending, response receiving, and connection confirmation, which can comprehensively characterize the communication latency status of the port. The preset threshold adopts a dynamic design method of 95th percentile value + 3 times the standard deviation, which fully combines the historical operating characteristics of the application port and avoids the incompatibility of fixed thresholds in different applications and operating scenarios, effectively reducing the false alarm rate and false negative rate of port status judgment. When a port response timeout is detected and an abnormal status is marked, the relevant data can be quickly uploaded to the data aggregation module, providing accurate abnormal trigger source information for the upper-layer cross-layer root cause analysis engine, ensuring that root cause analysis can quickly locate the dependent nodes related to the port abnormality, and improving the pertinence and efficiency of fault location.

[0043] As an optional implementation method of this embodiment, the process of constructing the business topology model includes: The network topology is established by probing the physical port connections between network devices within the site using the LLDP (Link Layer Discovery Protocol). Analyze the pre-configured server and application deployment list to determine the host server running each application process and its resource usage, and establish an application deployment mapping table; Based on predefined business flow rules, combined with network topology and deployment mapping table, the end-to-end logical communication path between the site monitoring unit and the central control center server is derived to form a business topology model.

[0044] In practice, the process of establishing the network layer topology is as follows: Network devices (switches, routers) periodically (30 seconds / time by default) send LLDP messages, which contain information such as device name, port identifier, MAC address, and management IP. After receiving the messages, adjacent network devices parse and store the connection relationship. The system automatically draws the network layer physical topology map by aggregating the LLDP neighbor information of all network devices, clarifying the physical connection relationship such as "switch A - port 1 → switch B - port 3", and establishing the network layer topology.

[0045] Secondly, the server and application deployment configuration list is a JSON file containing server node information (server IP, hostname, hardware configuration, and affiliated site), application information (application name, process ID, listening port, and deployment path), and the binding relationship between the application and the server (e.g., "PV power prediction application - process ID 1234 - deployed on server 192.168.2.20"). The resource usage in the application deployment mapping table is updated by real-time collection of CPU and memory usage data.

[0046] Furthermore, the business flow rules are defined based on the core business types of new energy power plants, including "PV data acquisition → data preprocessing → central control center storage" and "wind turbine status monitoring → fault early warning → central control center alarm," etc. Each rule clearly defines the source node, destination node, transmission protocol, and critical path identifier of the business data. The end-to-end logical communication path between the power plant monitoring unit (such as the PV inverter monitoring module and wind turbine control cabinet) and the central control center server is derived using a depth-first search (DFS) algorithm, for example, "PV inverter monitoring unit → edge switch → core switch → router → central control center access switch → central control center application server (PV data storage service)," forming a business topology model. This business topology model supports dynamic updates; when network device connection relationships change (detected via LLDP message updates) or application deployments are adjusted (triggered by configuration list updates), the system automatically reconstructs the topology structure within 5 minutes.

[0047] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment automatically detects the network physical topology through the LLDP protocol. Compared with the traditional method of manually drawing topology maps, this not only reduces the manual cost of topology construction but also ensures the accuracy and real-time performance of network layer connections, avoiding the problem of discrepancies between the topology and reality caused by manual maintenance. By parsing the pre-set deployment configuration list and combining it with real-time resource usage data, the application deployment mapping table contains both static binding relationships and dynamic resource status awareness capabilities, providing a precise basis for application-server dependency associations. Based on business flow rules and the DFS algorithm, the end-to-end logical communication path is derived, and the physical topology is combined with application deployment to construct a three-in-one business topology model of physical layer, resource layer, and business layer, solving the defect that traditional single-dimensional topology cannot reflect business dependencies. The dynamic updating characteristics of the business topology model can adapt to changes in scenarios such as new energy power station equipment expansion and application upgrades, ensuring that the topology view is always consistent with the actual operating status. As the core basis for end-to-end data association mapping, the business topology model provides a clear reference for the fault propagation path for the cross-layer root cause analysis engine, enabling root cause location to be accurately traced along the path of "application anomaly point → dependent server → underlying network device", while providing a dependency relationship basis for alarm convergence.

[0048] Based on the aforementioned business topology model or service port availability check, as a further optional implementation method of this embodiment, when the cross-layer root cause analysis engine receives application status data marked as port response timeout and performs collaborative analysis, it locates the application process node that generated the data in the business topology model and traverses all dependent nodes downward along the end-to-end logical communication path.

[0049] In practical implementation, this process first extracts the device identifier and timestamp from the data. Then, in the business topology model, the application process node for generating this data is located using the association index of "application name-process ID-server IP". Subsequently, based on the predefined end-to-end logical communication path in the business topology model, all dependent nodes are traversed downwards in the order of "application process node → host server node → access switch node → core switch node → router node → central control center access device node". During the traversal, a "layered filtering" mechanism is adopted: for each layer of nodes, the performance data of that layer's nodes within ±3 collection cycles before and after the abnormal time point is first queried. If the performance data of all nodes in that layer are normal, the child nodes under that layer are skipped directly, and only other abnormal candidate layers are traversed to improve traversal efficiency. For example, if the CPU, memory, and disk I / O of the host server corresponding to the application process node are all within the normal threshold range, there is no need to traverse other internal resource nodes of the server; the process directly jumps to the access switch node for verification.

[0050] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment ensures rapid and accurate location of application process nodes in the business topology model through a multi-dimensional association index of "application name-process ID-server IP," avoiding location delays caused by ambiguous node identifiers. Traversing dependent nodes downwards in the order of "application → server → network device" aligns with the typical path of fault propagation (faults in lower-level devices propagate upwards to the application), making the traversal process more targeted and significantly shortening query time compared to a ruleless full traversal. The adopted "layered filtering" mechanism can dynamically adjust the traversal path based on the performance status of the current layer nodes, skipping nodes without anomalies, reducing invalid data queries and analysis operations, and further improving the efficiency of collaborative analysis. This traversal logic, combined with the root cause confidence calculation model of the cross-layer root cause analysis engine, can quickly focus on abnormal candidate nodes, providing efficient support for the accurate determination of root cause fault points. This ensures that the system can quickly trace back to the root cause of the underlying fault in abnormal scenarios such as application port response timeouts, shortening the average fault repair time.

[0051] In the design of the aforementioned collaborative analysis process, as a further optional implementation method of this embodiment, when the cross-layer root cause analysis engine traverses all dependent nodes, it prioritizes checking the lowest-level network device nodes. When it finds that the network performance data of a network device node is continuously abnormal within a preset time window, the network device node is determined to be the root cause failure point.

[0052] In practical implementation, the lowest-level network device nodes include core switches, routers, access switches, etc. The priority inspection logic is based on the probability of fault propagation to the network device node in the root cause confidence calculation model. Assign the highest weight (core switch) ,router Access switch ), higher than the server node ) and application nodes ). Secondly, the length of the preset time window is dynamically configured according to the network device type: the time window for core network devices (core switches, routers) is 3 collection cycles (i.e., 3 seconds), and the time window for access layer network devices is 5 collection cycles (i.e., 5 seconds).

[0053] In addition, the criteria for determining continuous abnormality in network performance data are: packet loss rate exceeding the preset threshold continuously (no less than 1% for core devices and no less than 3% for access devices), or transmission delay exceeding the preset threshold continuously (no less than 50ms for core devices and no less than 100ms for access devices), or port traffic being 0 for 3 consecutive collection cycles (determined as port interruption).

[0054] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment prioritizes the lowest-level network device nodes for inspection based on the statistical laws of fault propagation. It assigns higher fault propagation probability weights to these nodes in the root cause confidence model, enabling rapid identification of the core fault sources most likely to cause upper-layer application anomalies. Network device faults (such as link interruptions and bandwidth congestion) are high-frequency causes of service anomalies at new energy power stations, and this priority strategy improves the hit rate of root cause localization. The dynamically configured preset time windows and differentiated performance anomaly judgment criteria fully consider the operating characteristics of network devices at different levels (core devices have higher stability requirements and stricter thresholds; access devices have complex environments and appropriately relaxed thresholds), avoiding misjudgments or omissions caused by a one-size-fits-all standard. When a network device node meets the continuous anomaly conditions, it is directly identified as the root cause fault point, simplifying the subsequent analysis process, shortening the root cause confirmation time, and enabling maintenance personnel to quickly focus on and handle network device faults, effectively reducing the duration of fault impact on new energy power station services.

[0055] As an optional implementation of this embodiment, the cross-layer root cause analysis engine is also configured to use a linear regression algorithm to fit continuously collected historical disk usage data for server disk usage rate and calculate disk capacity consumption rate; when the prediction result shows that the remaining available space will be exhausted within the set warning period, a disk capacity shortage warning is generated, and the disk capacity shortage warning is used as an input parameter of the cross-layer root cause analysis engine to participate in the comprehensive weight calculation when assessing the system health status.

[0056] In practical implementation, the calculation formula for the linear regression algorithm is as follows: in, Disk capacity consumption rate (unit: GB / hour); The value represents the sliding window size, which is set to 24 collection cycles (i.e., 24 × 5 = 120 seconds, covering 2 hours of historical data). Let be the weight coefficient of the j-th historical data point, satisfying ( Corresponding to the earliest data point, (corresponding to the latest data points), implementing a weighted logic where newer data has a higher weight; The collection timestamp of the j-th data point (converted to a continuous hourly variable, such as...) , (Unix timestamp) The disk usage capacity of the j-th data point (in GB); This is a weighted average of the timestamps collected within the sliding window. ; This is a weighted average of the disk usage within the sliding window. .

[0057] Secondly, the remaining available space , Total disk capacity, warning period Based on a 24-hour operation and maintenance response time for new energy power plants, the estimated depletion time is... ,when An alert is triggered at any time.

[0058] In addition, the insufficient disk capacity warning includes a warning level (based on...) Divided into emergency warnings: Hours; General warning: Information such as hourly rate, disk identifier, current usage, and consumption rate are used as input parameters for this alert in the root cause confidence model. Dynamic adjustment of coefficients (the weighting coefficient for emergency warnings is 0.3, and the weighting coefficient for general warnings is 0.1).

[0059] Based on the above, the three-in-one intelligent monitoring system from the new energy power station to the central control center in this embodiment adopts a linear regression algorithm with a sliding window weighting mechanism to assign higher weights to recent disk usage data. Compared with traditional equal-weighted linear regression, it can more accurately capture the short-term trend of disk capacity consumption, avoid interference from long-term historical data on fitting accuracy, and make the calculation of disk capacity consumption rate more in line with the actual situation. Based on the prediction model of consumption rate and remaining space, it can identify the risk of insufficient disk capacity 24 hours in advance, extending the operation and maintenance mode from post-fault repair to pre-fault warning, reserving sufficient time for operation and maintenance personnel to handle (such as cleaning up redundant data and expanding disk capacity), effectively avoiding application service interruption due to disk exhaustion, and realizing proactive system warning. The disk capacity shortage warning participates in the comprehensive weight calculation of system health status, enabling the cross-layer root cause analysis engine to combine disk resource risk status when judging the root cause of other anomalies, avoiding the omission of hidden fault sources caused by insufficient disk capacity leading to abnormal application response, further improving the comprehensiveness and accuracy of root cause location, and ensuring the stable operation of the new energy power station server.

[0060] As an optional implementation of this embodiment, the data processing and analysis layer also includes an alarm convergence module; the alarm convergence module is configured to suppress all derivative alarms generated by upper-layer applications and services when the underlying device is determined to be the root cause of the failure, based on the dependency relationship defined in the business topology model.

[0061] In practical implementation, an alarm convergence module is established to create a mapping rule base for root cause alarms and derived alarms based on this dependency relationship. When the underlying device is determined to be the root cause failure point, the rule base is used to identify all upper-layer applications and services that depend on the underlying device and suppress the derived alarms they generate.

[0062] Secondly, the construction logic of the mapping rule base is as follows: For each node N in the business topology model, if node M is a direct or indirect dependent node of N (i.e., the operation of N depends on the normal operation of M), then the alarm generated by N is marked as a derived alarm of alarm M. The alarm suppression execution flow is as follows: 1) Receive root cause fault point identifiers and root cause alarms output by the cross-layer root cause analysis engine; 2) Traverse the mapping rule base and query all upper-level derived alarm nodes corresponding to the root cause fault point; 3) Mark the alarms generated by these nodes within the current abnormal time window and set a suppression state; 4) Output the suppressed alarm set (only retaining the root cause alarms) to the application presentation layer; at the same time, the alarm convergence module records the suppression log, including the root cause alarm ID, the number of suppressed derivative alarms, the suppression time, the mapping rule number and other information, so as to facilitate the traceability of the operation and maintenance personnel.

[0063] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment uses an alarm convergence module to construct a root cause alarm-derived alarm mapping rule base based on the dependency relationship of the business topology model. This module can accurately identify the causal relationship between alarms, solving the defect of traditional monitoring systems that cannot distinguish between root cause alarms and derived alarms. By suppressing upper-level derived alarms caused by underlying root cause faults, it effectively avoids alarm storms, reduces the number of invalid alarms that maintenance personnel need to handle, lowers the information filtering burden, and enables maintenance personnel to quickly focus on core root cause alarms, thus improving the efficiency of fault handling. The alarm suppression log recording function provides complete data support for maintenance review, facilitating subsequent optimization of alarm mapping rules and root cause analysis algorithms. The design of this module improves the effectiveness and operability of alarms through the alarm convergence mechanism, and in collaboration with the cross-layer root cause analysis engine, achieves the maintenance goal of accurate positioning and efficient handling.

[0064] Based on the aforementioned derivative alarms, as a further optional implementation method of this embodiment, after receiving the output of the alarm convergence module, the application presentation layer highlights only the nodes identified as root cause faults in the visualization interface, and displays the nodes corresponding to the suppressed derivative alarms in a normal state.

[0065] In practical implementation, a hierarchical topology + alarm aggregation display method is adopted in the visualization interface to highlight only the nodes identified as root cause faults. Highlighting methods include: the node color changes to red (emergency alarm) or orange (general alarm), the node icon flashes (blinking frequency of 2 times / second), a red halo appears around the node, and root cause alarm details (including fault type, abnormal indicators, confidence level, and occurrence time) pop up when the mouse hovers over it. Nodes in normal states are displayed in green without flashing, but maintenance personnel can manually view them using the "Display Suppressed Alarms" switch. When viewing, derived alarm nodes are marked in yellow, and a prompt message "Derived Alarm (Suppressed) - Root Cause: XXX Node Fault" is displayed when the mouse hovers over them. Simultaneously, the visualization interface provides a "Root Cause Tracing" function; clicking on the root cause fault node automatically highlights all its upper-level dependent nodes and communication paths, intuitively presenting the fault propagation range.

[0066] Based on the above, the three-in-one full-link intelligent monitoring system from the new energy power station to the central control center in this embodiment adopts a visualization design that highlights the root cause and displays derivative nodes normally. This design can intuitively distinguish the core fault point from the affected nodes, avoiding the visual confusion caused by highlighting all abnormal nodes in the traditional topology diagram. This allows maintenance personnel to quickly locate the root cause of the fault and its scope of impact. The normal display and manual viewing modes for derivative alarm nodes ensure both interface simplicity and complete alarm information, meeting the viewing needs of maintenance personnel in different scenarios (focusing on the root cause during fault handling and viewing all alarms during review). The root cause tracing function automatically highlights the fault propagation path, transforming abstract business topology dependencies into intuitive visual paths. This helps maintenance personnel quickly understand the scope of impact and propagation logic of the fault, providing intuitive support for developing targeted fault handling solutions. This display method, in deep collaboration with the alarm convergence module and the cross-layer root cause analysis engine, achieves full-process visualization and accuracy of data collection, analysis, alarming, and display, improving the operational experience and work efficiency of maintenance personnel.

[0067] As an optional implementation of this embodiment, the data processing and analysis layer uses a time series database to store the full-link state dataset and performs a hierarchical retention strategy on the stored data. The hierarchical retention strategy includes: retaining the data with full precision for a first predetermined time, and after the first predetermined time, only retaining the downsampled low-precision data and transferring it to a low-cost storage medium.

[0068] In practical implementation, InfluxDB can be selected as the time series database, which supports high write throughput and low-latency queries and is adapted to the time series characteristics of end-to-end state datasets.

[0069] Secondly, the tiered retention strategy specifically includes: 1) Complete and accurate data retention: The collected raw data (including the precise values ​​of all indicators, timestamps, and device identifiers) will be retained for a first predetermined time. The first predetermined time is set according to the data type: network performance data (high-frequency collection) will be retained for 7 days, server resource data will be retained for 30 days, and application status data will be retained for 90 days. 2) Downsampling: After the first predetermined time has elapsed, the original data is downsampled. The downsampling rules are as follows: network performance data is averaged at 10-minute intervals, server resource data is averaged at 1-hour intervals, and application status data is statistically analyzed at 2-hour intervals (such as percentage of available time and number of timeouts). 3) Low-precision data storage: Downsampled low-precision data is transferred to low-cost storage media (such as object storage service OSS) and retained for a second predetermined period: network performance low-precision data is retained for 180 days, server resource low-precision data is retained for 365 days, and application status low-precision data is retained for 730 days. 4) Data cleaning: Automatically clean up low-precision data that has exceeded the second predetermined time, or transfer it to offline storage devices (such as tape libraries) according to the user-configured archiving strategy.

[0070] Based on the above, the three-in-one intelligent monitoring system from the new energy power station to the central control center in this embodiment uses the time-series database InfluxDB to store the entire link status dataset. This fully adapts to the core requirements of high write speed, high query speed, and time-range retrieval of time-series data, ensuring the storage reliability and query efficiency of large-scale collected data, and providing performance support for concurrent data queries of the cross-layer root cause analysis engine. The hierarchical retention strategy dynamically adjusts the storage cycle and precision based on the data collection frequency, importance, and usage frequency. While ensuring core requirements such as fault tracing and trend analysis, it minimizes storage costs. High-frequency collected raw data is retained for short periods (reducing storage overhead), while low-precision data is retained for long periods (meeting long-term trend analysis and compliance requirements). Offline archiving further optimizes storage resource allocation. This strategy avoids the problem of excessively high storage costs caused by traditional full-volume long-term storage and solves the defect that short-term storage cannot meet the needs of long-term data analysis, achieving a balance between performance, cost, and requirements. The long-term retention and hierarchical management of data also provide rich historical data support for subsequent optimization of root cause analysis algorithms, adjustment of collection frequency, and improvement of business topology models, helping the system to continuously iterate and optimize, and improving the long-term availability and scalability of the system.

[0071] In the embodiments provided in this application, it should be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, code, or any suitable combination thereof. For hardware implementation, the processor may be implemented in one or more of the following: application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to implement the functions described herein, or combinations thereof. For software implementation, some or all of the processes of the embodiments may be performed by a computer program instructing the associated hardware. During implementation, the program may be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media may be any available medium accessible to a computer. Computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having the form of instructions or data structures and accessible to a computer.

[0072] Finally, it should be noted that the above description is only a preferred embodiment of this application and is not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A three-in-one end-to-end intelligent monitoring system from new energy power plants to centralized control centers, characterized in that, include: The data acquisition and transmission layer is deployed on the side of the new energy power station and is configured to collect network performance data, application status data and server resource data through a unified acquisition frequency and time synchronization mechanism. The data processing and analysis layer, deployed at the central control center, includes a unified spatiotemporal correlation module and a cross-layer root cause analysis engine. The unified spatiotemporal correlation module is configured to assign a unified timestamp and device identifier to all collected data, and based on a predefined business topology model, to correlate and map the network performance data, the application status data, and the server resource data to generate a full-link status dataset with correlation relationships. The cross-layer root cause analysis engine is configured to perform collaborative analysis on the full-link state dataset. This collaborative analysis includes: when an application state anomaly is detected, automatically locating its dependent nodes in the business topology model, concurrently querying the performance data of the dependent nodes before and after the anomaly time point, and, based on preset fault propagation rules, identifying the lowest-level dependent node experiencing simultaneous performance degradation as the root cause failure point and generating a root cause alarm. The root cause failure point is determined through a root cause confidence calculation model, the calculation formula of which is: ； in, Let be the root cause confidence of the i-th dependent node. When the root cause confidence of a dependent node exceeds 0.8, it is determined to be a root cause failure point. This is the fault propagation weighting coefficient, which characterizes the ability of a node fault to propagate its impact on upper-layer applications. Let be the probability of fault propagation at the i-th node; This represents the performance degradation of the i-th node within the abnormal time window. This is the average performance benchmark value for this type of node; This is the node importance weighting coefficient, representing the coreness of a node in the business chain; Let i be the importance index of the i-th node; This is the time decay coefficient; The duration of the performance anomaly of the i-th node; The application presentation layer is configured to visualize the business topology model and receive the output of the cross-layer root cause analysis engine, highlighting the root cause failure points on the topology view.

2. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 1, characterized in that, The data acquisition and transmission layer includes: A lightweight proxy module is deployed on a server at the site and configured to collect the network performance data, application status data, and server resource data. The data aggregation module is configured to encapsulate the collected data into a message with the unified timestamp and the device identifier, and send it to the central control center through a dual-link transmission mechanism.

3. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 2, characterized in that, The collection of application status data includes service port availability checks. The service port availability checks are implemented by simulating the establishment of a TCP connection with the service port of the target application and recording the complete handshake time from sending the connection request to receiving the response. When the handshake time exceeds a preset threshold, the lightweight proxy module marks the corresponding application status data as a port response timeout state and sends the application status data to the data aggregation module.

4. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 1, characterized in that, The process of constructing the business topology model includes: The physical port connections between network devices within the site are detected using the LLDP protocol to establish the network layer topology. Analyze the pre-configured server and application deployment list to determine the host server running each application process and its resource usage, and establish an application deployment mapping table; Based on predefined business flow rules and combined with network topology and deployment mapping table, the end-to-end logical communication path between the site monitoring unit and the central control center server is derived to form the business topology model.

5. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 4, characterized in that, When the cross-layer root cause analysis engine receives application status data marked as port response timeout and performs collaborative analysis, it locates the application process node that generated the data in the business topology model and traverses all dependent nodes downwards along the end-to-end logical communication path.

6. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 5, characterized in that, When the cross-layer root cause analysis engine traverses all dependent nodes, it prioritizes checking the lowest-level network device nodes. When it finds that the network performance data of a network device node is continuously abnormal within a preset time window, it determines that the network device node is the root cause failure point.

7. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 1, characterized in that, The cross-layer root cause analysis engine is also configured to use a linear regression algorithm to fit continuously collected historical disk usage data for server disk utilization and calculate the disk capacity consumption rate; when the prediction result shows that the remaining available space will be exhausted within the set warning period, a disk capacity shortage warning is generated, and the disk capacity shortage warning is used as the input parameter of the cross-layer root cause analysis engine to participate in the comprehensive weight calculation when assessing the system health status.

8. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 1, characterized in that, The data processing and analysis layer also includes an alarm convergence module; the alarm convergence module is configured to suppress all derivative alarms generated by upper-layer applications and services when the underlying device is determined to be the root cause of the failure, based on the dependency relationship defined in the business topology model.

9. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 8, characterized in that, After receiving the output from the alarm convergence module, the application presentation layer highlights only the nodes identified as root cause faults in the visualization interface, and displays the corresponding nodes of the suppressed derivative alarms in a normal state.

10. The three-in-one full-link intelligent monitoring system from new energy power station to centralized control center according to claim 1, characterized in that, The data processing and analysis layer uses a time series database to store the full-link state dataset and performs a hierarchical retention strategy on the stored data. The hierarchical retention strategy includes: retaining the data with full precision for a first predetermined time, and after the first predetermined time, retaining only the downsampled low-precision data and transferring it to a low-cost storage medium.

Images