A Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method

Abstract

A Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method, belonging to the field of server monitoring technology, is implemented based on a monitored server and an intelligent operation and maintenance server. The monitored server includes acquisition software consisting of a heartbeat module, a data sending module, and a performance monitoring module. This software periodically collects CPU, memory, and disk performance indicators of the monitored server, generates performance data, and sends it to the intelligent operation and maintenance server. The intelligent operation and maintenance server includes intelligent operation and maintenance service software consisting of a data receiving module and a logic processing module. This software receives and parses the heartbeat data and performance data from the monitored server and periodically sends heartbeat signals to the monitored server to keep it online. The acquisition software features high real-time performance, strong scalability, and easy integration, effectively improving the efficiency and reliability of the operation and maintenance management of the monitored server.

Description

Technical Field

[0001] This invention relates to the field of server monitoring technology, and in particular to a Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method, specifically applied to the online status detection of monitored servers, long-term trend analysis of performance data, and threshold over-limit alarms in intelligent operation and maintenance scenarios of rail transit. Background Technology

[0002] With the rapid development of the rail transit industry, the scale and complexity of servers are constantly increasing, making server performance monitoring and health status detection crucial aspects of operation and maintenance management. Traditional server monitoring tools typically rely on specific operating systems or hardware platforms, lacking cross-platform compatibility. Furthermore, existing monitoring systems often fail to monitor server performance data in real time and lack effective heartbeat detection mechanisms, resulting in delayed responses to server failures.

[0003] With the intelligent development of rail transit systems, servers, as core infrastructure, undertake important tasks such as train dispatching, signal control, and passenger services. However, traditional server monitoring tools have the following problems: poor cross-platform compatibility: rail transit systems often use multiple operating systems (such as Windows and Linux), making it difficult for traditional tools to monitor them uniformly; insufficient real-time performance: existing monitoring systems mostly use polling mechanisms, which cannot capture server performance fluctuations in real time, leading to delayed fault response; lack of heartbeat mechanism: the lack of an effective heartbeat detection mechanism makes it impossible to quickly detect server downtime or network isolation problems, affecting the continuity and safety of rail transit operations.

[0004] In addition, intelligent operation and maintenance of rail transit places extremely high demands on the health status of servers, and traditional monitoring tools are unable to meet the requirements of real-time performance, reliability and scalability. Summary of the Invention

[0005] To address the shortcomings of existing technologies, such as poor cross-platform compatibility, insufficient real-time performance, and lack of a heartbeat mechanism, this invention proposes a Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method. Specifically optimized for intelligent operation and maintenance scenarios in rail transit, this method is used for performance monitoring and online status detection of monitored servers in rail transit. The method utilizes the oshi (Operating System and Hardware Information) open-source library in the Java programming language to collect real-time CPU, memory, and disk performance data of the monitored server and periodically send this performance data to the intelligent operation and maintenance server via HTTP requests. Simultaneously, the data collection software has a heartbeat detection function, periodically sending heartbeat signals to the monitored server to ensure its online status. The data collection software features high real-time performance, strong scalability, and easy integration, effectively improving the efficiency and reliability of the operation and maintenance management of the monitored server.

[0006] The technical solution adopted in this invention is: a Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method, the method being implemented based on a monitored server and an intelligent operation and maintenance server; the monitored server includes acquisition software consisting of a heartbeat module, a data sending module, and a performance monitoring module, used to periodically collect CPU, memory, and disk performance indicators of the monitored server and generate performance data, which is then sent to the intelligent operation and maintenance server;

[0007] The intelligent operation and maintenance server includes intelligent operation and maintenance service software consisting of a data receiving module and a logic processing module. It is used to receive and parse heartbeat data and performance data from the monitored server; and periodically send heartbeat signals to the monitored server to keep the monitored server online.

[0008] The workflow of the performance monitoring module includes: initializing a SystemInfo object through a custom utility class SystemInfoUtil; obtaining the CPU, memory, and disk performance indicators of the monitored server through the SystemInfo object, generating performance data, storing the collected performance data in the local cache of the monitored server, and processing it by the data sending module.

[0009] The workflow of the data sending module includes: obtaining performance data from the performance monitoring module; encapsulating the performance data into a ComPerf object; and sending the ComPerf object to the intelligent operation and maintenance server data receiving module through the encapsulated HTTP utility class.

[0010] The workflow of the heartbeat module includes: encapsulating heartbeat data into a key-value pair set Map; periodically sending HTTP POST requests to the intelligent operation and maintenance server's data receiving module through the data sending module as heartbeat signals; and the intelligent operation and maintenance server determining the online status of the monitored server based on the received heartbeat signals.

[0011] The workflow of the data receiving module includes: receiving data requests from the data sending module of the monitored server; determining the data category based on the request type, distinguishing between performance monitoring data and heartbeat detection data; parsing the performance monitoring data to extract the CPU, memory, and disk performance data of the monitored server; parsing the heartbeat detection data to extract the device number and timestamp information of the monitored server; and transmitting the parsed performance monitoring data and heartbeat detection data to the logic processing module for storage and status analysis.

[0012] The workflow of the logic processing module includes: receiving performance monitoring data and heartbeat detection data from the data receiving module of the monitored server; writing the performance monitoring data into the database, continuously recording and analyzing the performance data of the monitored server during operation, realizing long-term trend analysis of performance data and threshold over-limit alarms; determining the online status of the monitored server based on the heartbeat detection data, and determining that the monitored server is offline when no heartbeat signal is received for several consecutive times; the logic processing module realizes real-time online and offline status monitoring and performance data monitoring of the monitored server through the storage of performance data and the analysis of heartbeat data.

[0013] The method supports dynamic loading of configuration files, allowing users to set the line number to which the sending device belongs, the subsystem number to which the sending device belongs, the device number to which the sending device belongs, and HTTP request address parameters through the configuration file.

[0014] The technical effects of this invention are as follows: This invention supports real-time monitoring of key performance data such as CPU, memory, disk, and network of the monitored server; it supports periodic uploading of performance data to the intelligent operation and maintenance server via HTTP protocol; it continuously records and analyzes the performance data of the monitored server during operation, enabling long-term trend analysis of performance data and threshold over-limit alarms; it supports heartbeat signal detection to ensure the online status of the monitored server, and determines that the monitored server is offline when no heartbeat signal is received for several consecutive times.

[0015] This invention is an optimized design for intelligent operation and maintenance of rail transit, supporting unified monitoring in multi-operating system environments and adapting to complex server deployment scenarios in rail transit systems.

[0016] This invention collects performance data in real time to ensure the continuity of critical operations such as train scheduling and signal control. Through a heartbeat detection mechanism, it can quickly detect server failures and reduce the impact on operations.

[0017] This invention features high performance and low resource consumption. It implements hardware monitoring based on the oshi library, with CPU utilization below 2% and memory consumption less than 50MB. The multi-threaded asynchronous processing mechanism avoids additional burden on server performance.

[0018] This invention offers flexible configuration and scalability, supporting dynamic adjustment of data collection intervals, heartbeat frequencies, and alarm rules to adapt to different operational and maintenance needs.

[0019] This invention provides a RESTful API interface, which facilitates integration with existing intelligent operation and maintenance platforms for rail transit.

[0020] This invention provides a single data acquisition software that can meet the needs of intelligent operation and maintenance of rail transit for server performance monitoring and online detection. It features high real-time performance, strong scalability, and easy integration. It is convenient to use, saves labor costs, and improves operation and maintenance supervision efficiency and system reliability. Attached Figure Description

[0021] Figure 1 The system architecture diagram for implementing this invention;

[0022] Figure 2 This is a flowchart of the performance monitoring module of the present invention;

[0023] Figure 3 This is a flowchart of the data transmission module of the present invention;

[0024] Figure 4 This is a flowchart of the heartbeat module of the present invention. Detailed Implementation

[0025] The present invention will be further described below with reference to the accompanying drawings: Figure 1 The overall architecture of the system described in this invention is illustrated. A Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method is implemented based on a monitored server and an intelligent operation and maintenance server. The monitored server is equipped with acquisition software consisting of a heartbeat module, a data sending module, and a performance monitoring module. This software periodically collects CPU, memory, and disk performance indicators of the monitored server, generates performance data, and sends it to the intelligent operation and maintenance server. The intelligent operation and maintenance server is equipped with intelligent operation and maintenance service software consisting of a data receiving module and a logic processing module. This software receives and parses the heartbeat data and performance data from the monitored server. It periodically sends heartbeat signals to the monitored server to keep it online.

[0026] Reference Figure 2This demonstrates the workflow of the performance monitoring module. First, system information is initialized by obtaining the system information object `OSRuntimeInfo` (object properties are custom-defined in this invention) through the encapsulated `SystemInfoUtil` utility class. This step lays the foundation for subsequent hardware information collection. Various hardware-related data are collected: CPU utilization is obtained using the `osRuntimeInfo.getCpuUsage()` method; the total system memory is obtained using the `osRuntimeInfo.getTotalMemory()` method; and the used memory is obtained using the `osRuntimeInfo.getUsedMemory()` method. Other hardware information, such as disk and network information, is also collected in the same manner. Data encapsulation and processing: the collected CPU, memory, disk, and network information is encapsulated into `Performance` objects (object properties are custom-defined in this invention). Each `Performance` object contains information such as data name, title, unit, type, and value. The encapsulated data is stored in `performanceList`, ready to be sent to the intelligent operation and maintenance server.

[0027] The SystemInfo object is initialized through a custom utility class SystemInfoUtil, and hardware information, including CPU, memory, disk, and network, is obtained through the SystemInfo object.

[0028] Reference Figure 3 This demonstrates the workflow of the data sending module. First, a custom HTTP utility class is encapsulated. This class integrates functions such as sending and receiving HTTP requests, exception handling, and supports both GET and POST request methods. Next, line, subsystem, equipment information, and target address information are read from the configuration file using YAML and the `@Value` tag. Then, a scheduled task is created to send the encapsulated object to the target address via the utility class. Finally, the data sending module creates scheduled tasks based on the time intervals or trigger conditions set in the configuration file. These scheduled tasks periodically retrieve the encapsulated data objects from memory and send this data to the specified target address using the previously encapsulated HTTP utility class. Performance parameter data is encapsulated as a `ComPerf` object and sent to the rail transit intelligent operation and maintenance platform via an HTTP POST request.

[0029] Reference Figure 4The document demonstrates the workflow of the heartbeat module. Running independently, the heartbeat module periodically sends HTTP POST requests as heartbeat signals to the intelligent operations and maintenance (O&M) server. These heartbeat signals confirm the system's liveness and ensure the intelligent O&M server can promptly detect the system's operational status. Upon receiving a heartbeat signal, the intelligent O&M server verifies and processes it; if the heartbeat signal is normal, the system assumes the sending end is operating normally. Upon receiving a heartbeat signal, the intelligent O&M system refreshes the time-to-live (TTL) of relevant data, ensuring that cached data does not expire due to timeout, thus maintaining data real-time performance and validity. The caching service stores system performance data and other critical information. Through the caching mechanism, the system can reduce frequent database accesses and improve data retrieval efficiency.

[0030] Cache Expiration: If no heartbeat signal or data update is received within a certain period of time, the data in the cache service will expire. Expired data will be marked as invalid and removed from the cache.

[0031] The intelligent operations and maintenance system triggers alarms: When cached data expires or a heartbeat signal is not received for an extended period, the intelligent operations and maintenance system will trigger an alarm mechanism. The alarm information will notify the administrator or relevant responsible personnel so that timely measures can be taken to address potential system problems.

[0032] The heartbeat data is encapsulated into a key-value pair collection Map, and HTTP POST requests are periodically sent to the intelligent operations and maintenance server as heartbeat signals. The intelligent operations and maintenance server determines the online status of the monitored server based on the received heartbeat signals.

[0033] Configuration Management Module:

[0034] Users can dynamically adjust parameters through external configuration files. They can set parameters such as the line number to which the sending device belongs, the subsystem number to which the sending device belongs, the device number to which the sending device belongs, and the HTTP request address.

[0035] Example 1 illustrates the practical application of this method in a real-world project: a performance monitoring and heartbeat detection program for a monitored server in a rail transit BS architecture project. This project requires performance monitoring and heartbeat detection of the monitored server. Introducing this method resolves issues such as poor compatibility, insufficient real-time performance, and the lack of a heartbeat mechanism.

[0036] The first step is to implement timed task scheduling in the heartbeat module using the @Scheduled(fixedRate = 10000) annotation, which means that the sendHeartbeat() method will be executed every 10 seconds;

[0037] In the method body, first create a Map.<String, String> The request body object map of type [type] is used to store the core identification information of the currently monitored server (such as line number, subsystem number, device number, etc.) in the map as key-value pairs to identify the monitored server from which the heartbeat originates.

[0038] Next, construct the target request URL, which is the complete heartbeat interface path concatenated from the target address desUrl of the intelligent operation and maintenance server, i.e.: http: / / {desUrl} / ims / heartbeat / devUpdate

[0039] Finally, the encapsulated HttpUtil.doPost(url, map) method is called to send the heartbeat data to the intelligent operation and maintenance server via an HTTP POST request;

[0040] After receiving heartbeat data, the intelligent operation and maintenance server can determine the specific device from which the heartbeat originates based on lineNum, subsystemNum, and deviceNum, and update the online status of that device accordingly.

[0041] The second step is the performance monitoring module, which is the core performance acquisition function of the Java-based intelligent operation and maintenance server performance monitoring system. It is used to collect the operating status information of the monitored server, such as CPU, memory, disk and network, in real time, and encapsulate it into a performance data object ComPerf and return it.

[0042] Its workflow is as follows: First, a ComPerf object res is created and basic attributes such as line number, subsystem number, and device number are set for it to identify the monitored server from which the data comes. Then, the custom utility class SystemInfoUtil.getOSRuntimeInfo() is called to obtain the current system's runtime information object OSRuntimeInfo, which encapsulates low-level performance parameters such as CPU, memory, and disk.

[0043] Next, the program constructs a performance data list called `performanceList`, which collects and encapsulates various performance metrics in sequence:

[0044] CPU information acquisition: The monitored server obtains data such as CPU utilization and base frequency from runtime information, calculates CPU utilization and creates a Performance object, sets the data name, unit, type and value and then adds it to the performance list;

[0045] Memory information collection: Calculate the total system memory, used memory, and available memory in bytes to obtain memory utilization. Encapsulate the three types of indicators into Performance objects and add them to a list.

[0046] Disk information collection: Traverse each disk partition in the system (via the DisksInfo list), collect disk usage, total capacity and available capacity in sequence, assign a number to each disk, and store the data in the performance list in the form of a Performance object;

[0047] Network information collection: Obtain the network interface list NetworkIFs through the SystemInfo of the OSHI library, filter out the active network interface, extract the number of bytes received and sent (i.e. network traffic), and encapsulate it into a Performance object with a port number.

[0048] After all performance metrics have been collected, the program sets a unified collection timestamp lastTime for each Performance data item to ensure data time consistency. Finally, the complete performance data collection performanceList is assigned to the result object res.

[0049] Overall, this method achieves automated collection, standardized encapsulation, and time synchronization of key operating indicators of the monitored server, providing basic data support for subsequent performance reporting, status analysis, and alarm judgment of the intelligent operation and maintenance system, and has high real-time performance and scalability.

[0050] The third step is the data sending module, which defines a utility class named HttpUtil. This class is used in Java programs to send POST requests to specified monitored servers via the HTTP protocol. HttpUtil is used to implement HTTP communication functionality in the Java-based intelligent operations and maintenance system. It is primarily responsible for sending JSON-formatted data requests to the intelligent operations and maintenance server. The core method, doPost(String url, Object targetObj), works as follows: First, the program creates a closable HTTP client object using HttpClients.createDefault() to execute network requests. Then, it constructs an HttpPost request instance pointing to the target address and sets the request header information. Content-Type is specified as "application / json" to indicate that the request body is in JSON format, and Accept is specified as "application / json" to indicate that the client expects to receive a JSON-formatted response. Next, the program determines the type of the input parameter targetObj: if the object is a string, it is sent directly as the request body; if it is a regular Java object, it is serialized into a JSON string using JSON.toJSONString(targetObj) and encapsulated as a StringEntity using UTF-8 encoding and set in the request body. Subsequently, the client executes the POST request and retrieves the response, recording the response status code and content. The entire request process is logged, with the system outputting detailed request URLs, response status codes, and returned content for easy maintenance, debugging, and problem tracing. When exceptions occur (such as network timeouts or encoding errors), the program captures the exceptions and records error logs to ensure stable system operation. This utility class can be widely used in modules such as performance monitoring data reporting and heartbeat signal transmission to achieve highly reliable data interaction between the client and the intelligent maintenance server.

[0051] The fourth step is the data receiving module, which uses the front controller component in Spring to receive data from the data sending module. This is the interface method in the intelligent operation and maintenance server used to receive performance reporting data. The mapping path is / update, and it is called via HTTP POST. This interface is marked with the @ApiOperation("Communication Protocol Performance Reporting") annotation, which means it is used to receive performance monitoring data packets from the monitored server.

[0052] When the monitored server periodically reports performance data, the request body includes a BaseUpdateDTO. <comperformanceadddto>The method first obtains the source IP address of the reporting request through request.getRemoteAddr() to determine the source of the data. Then, it extracts the performance data list dataList from the dto. If the data is not empty, it retrieves the first performance data comPerformanceAddDTO and parses the line number lineNum and subsystem number subsystemNum.

[0053] Subsequently, by calling subsystemService.getByNumCache(lineNum, subsystemNum), the configuration information of the corresponding subsystem is obtained from the cache or database, the abbreviation information is extracted, and combined to generate a unique identifier key value, which is used to distinguish the performance data source of different subsystems;

[0054] Finally, the method passes the received dto object to the comPerformanceService.update(dto) method for business processing and data storage. After execution, it determines whether the processing was successful based on the return result of update(). If successful, it returns CommonResult.success(); otherwise, it returns CommonResult.failed().

[0055] This step enables the unified reception and business distribution of performance data from monitored servers, ensuring that performance monitoring data can be accurately identified, classified, and stored by the intelligent operation and maintenance platform, providing basic data support for subsequent performance analysis and health status assessment.

[0056] The fifth step, the logic processing module, is the core business logic implementation for receiving and processing performance data. It is used to identify metrics, analyze alarms, and store performance monitoring data from the monitored server. Its workflow is as follows:

[0057] First, the method extracts the number of data rows (rows) and the performance data list (dataList) from the parameter dto, and retrieves the first performance report data dto1. From this data, it parses out the line number (lineNum) and the subsystem number (subsystemNum), and then calls subsystemService.getByNumCache(lineNum, subsystemNum) to obtain the corresponding Subsystem object in order to get the line ID and subsystem ID to which the subsystem belongs, and sets them in MybatisPlusConfiguration for use as context identifiers for subsequent database operations.

[0058] Next, the method initializes the performance data list `performanceDataList` and extracts the set of all device IDs `deviceNums` from the reported data. It then uses `deviceService.getMapByNums(lineId, subsystemId, deviceNums)` to retrieve the device mapping table `mapDevices`, allowing for quick location of the corresponding device object in the database based on the device ID. Simultaneously, it calls `getMapTargets(lineId, subsystemId)` to retrieve the performance metric mapping table `mapTargets` configured in the system, and uses `getMapTrendWarningRules` to retrieve expert rules and warning rules respectively, for subsequent performance trend and anomaly analysis.

[0059] Then, the method iterates through the dataList:

[0060] For each reported ComPerformanceAddDTO data entry, first look up the corresponding Device object in mapDevices based on the device ID. If the device does not exist, skip the processing. If it exists, iterate through its internal performance metric list performanceList and read the performance metric object one by one.

[0061] The system searches for the corresponding metric configuration Target in mapTargets based on the metric's title. If no corresponding item is found, it skips the search. Once found, the system calls the generateAlarm() method to determine whether the metric has triggered an alarm rule and the generateWarning() method to determine whether a warning rule has been triggered, thereby realizing intelligent alarm and trend warning functions.

[0062] After each performance metric data is validated and the rules are judged, the method calls InitPerformanceData() to convert it into a PerformanceData object, which contains information such as device ID, metric ID, performance value, and collection time, and adds it to performanceDataList;

[0063] After all performance data processing is complete, the method uses a Stream to deduplicate the `performanceDataList`, obtaining a unique dataset `uniqueList`, and then calls `performanceDataService.saveBatchToDoris(uniqueList)` to write it in batches to the Doris database for subsequent big data analysis and visualization. If the performance data list is empty, it returns `false` to indicate that the data import failed.

[0064] Finally, regardless of whether the processing is successful or not, the method will call MybatisPlusConfiguration.clearSubsystemId() in the finally block to clear the subsystem ID in the thread context and prevent data corruption in subsequent requests;

[0065] Overall, this method implements a complete performance data processing flow, ensuring that performance monitoring data can be accurately parsed, intelligently analyzed, and efficiently stored, providing data support for system operation and maintenance monitoring and health assessment.< / comperformanceadddto>

Claims

1.A Java-based intelligent operation and maintenance server performance monitoring and heartbeat detection method, characterized in that, The steps are as follows: The first step is to implement timed task scheduling in the heartbeat module using the @Scheduled(fixedRate = 10000) annotation, which means that the sendHeartbeat() method will be executed every 10 seconds; In the method body, first create a Map.<String, String> The system generates a request body object map and stores the core identification information of the currently monitored server in key-value pairs in the map to identify the monitored server from which the heartbeat originates. Next, it constructs the target request address URL, which is the complete heartbeat interface path concatenated from the target address desUrl of the intelligent operation and maintenance server, i.e.: http: / / {desUrl} / ims / heartbeat / devUpdate. Finally, it calls the encapsulated HttpUtil.doPost(url, map) method to send the heartbeat data to the intelligent operation and maintenance server in the form of an HTTP POST request. After receiving heartbeat data, the intelligent operation and maintenance server determines the specific device from which the heartbeat originates based on lineNum, subsystemNum, and deviceNum, and updates the online status of that device accordingly. The second step, the performance monitoring module, first creates a ComPerf object `res` and sets its basic attributes such as line number, subsystem number, and device number. Then, it calls the custom utility class `SystemInfoUtil.getOSRuntimeInfo()` to obtain the current system's runtime information object `OSRuntimeInfo`, which encapsulates the underlying performance parameters of CPU, memory, and disk. Next, the program constructs a performance data list `performanceList`, sequentially collecting and encapsulating various performance metrics: CPU information collection: The monitored server obtains CPU utilization and base frequency data from the runtime information, calculates the CPU utilization, creates a `Performance` object, sets the data name, unit, type, and value, and adds it to the performance list; Memory information collection: Calculates the total system memory, used memory, and available memory bytes to obtain the memory utilization, and encapsulates the three metrics as `Performance` objects and adds them to the list; Disk information collection: Traverses each disk partition in the system, sequentially collecting disk utilization, total capacity, and available capacity, assigning a number to each disk, and storing the data in the performance list as `Performance` objects; Network information collection: Utilizes the `SystemInfo` function from the OSHI library... The program retrieves the NetworkIFs list of network interfaces, filters out active network interface cards, extracts their received and transmitted byte counts, and encapsulates these into a Performance object with a port number. After all performance metrics are collected, the program sets a unified collection timestamp lastTime for each Performance data item. Finally, the complete performance data set performanceList is assigned to the result object res. The third step is the data sending module. The program first creates a closable HTTP client object using HttpClients.createDefault() to execute network requests. Then, an HttpPost request instance pointing to the target address is constructed, and the request header information is set. Content-Type is specified as "application / json" to indicate that the request body is in JSON data format, and Accept is specified as "application / json" to indicate that the client expects to receive a JSON-formatted response. Next, the program determines the type of the input parameter targetObj: if the response content is a string, it is sent directly as the request body; if it is a regular Java object, it is serialized into a JSON string using JSON.toJSONString(targetObj), encapsulated in UTF-8 encoding as a StringEntity, and set into the request body. Subsequently, the client executes the HttpPost request and obtains the response result, recording the response status code and response content. The entire request process is logged, outputting detailed request URLs, response status codes, and returned content. When an exception occurs, the program catches the exception and records the error log. The fourth step is the data receiving module. First, it obtains the source IP address of the reporting request using `request.getRemoteAddr()` to determine the data source. Next, it extracts the performance data list `performanceList` from the DTO. If the data is not empty, it retrieves the first performance data entry `comPerformanceAddDTO` and parses the line number `lineNum` and subsystem number `subsystemNum`. Then, it retrieves the corresponding subsystem configuration information `Subsystem` from the cache or database by calling `subsystemService.getByNumCache(lineNum, subsystemNum)`, extracts its abbreviation information, and combines it to generate a unique identifier key. Finally, the method passes the received DTO object to the `comPerformanceService.update(dto)` method for business processing and data storage. After execution, it determines whether the processing was successful based on the return result of `update()`. If successful, it returns `CommonResult.success()`; otherwise, it returns `CommonResult.failed()`. The fifth step is the logic processing module, whose workflow is as follows: First, the method extracts the number of data rows (rows) and the performance data list (performanceList) from the parameter dto, and retrieves the first performance report data dto1. From this data, it parses out the line number (lineNum) and subsystem number (subsystemNum), and then calls subsystemService.getByNumCache(lineNum, subsystemNum) to obtain the corresponding Subsystem object, in order to obtain the line ID and subsystem ID to which the subsystem belongs, and sets them in MybatisPlusConfiguration for subsequent database operation context identification. Next, the method initializes the performance data list performanceList and extracts the set of all device IDs (deviceNums) from the reported data. It then uses deviceService.getMapByNums(lineId, subsystemId, deviceNums) to obtain the device mapping table mapDevices, so as to quickly locate the corresponding device object in the database based on the device ID. Simultaneously, it calls getMapTargets(lineId, subsystemId). Obtain the performance metric mapping table mapTargets configured in the system, and obtain expert rules and warning rules respectively through getMapTrendWarningRules for subsequent performance trend and anomaly analysis; Then, the method iterates through the dataList: For each reported ComPerformanceAddDTO data, it first searches for the corresponding Device object in mapDevices based on the device number. If the device does not exist, the processing is skipped. If it exists, it iterates through the performance data list performanceList, reading the performance metric objects one by one. The system searches for the corresponding metric configuration Target in mapTargets based on the metric's title. If no corresponding item is found, it is skipped. Once found, the system calls the generateAlarm() method to determine if the metric triggers an alarm rule and calls the generateWarning() method to determine if a warning rule is triggered, thus realizing intelligent alarm and trend warning functions. After each performance metric data is validated and the rule is determined, the method calls InitPerformanceData() to convert it into a PerformanceData object, containing the device ID, metric ID, performance value, and collection time information, and adds it to performanceDataList. After all performance data is processed, the method uses a Stream to deduplicate performanceDataList, obtaining a unique dataset uniqueList, and calls performanceDataService.saveBatchToDoris(uniqueList) to write it to Doris in batches. If the performance data list is empty, the database returns false to indicate that the data insertion failed. Finally, regardless of whether the processing is successful or not, the method will call MybatisPlusConfiguration.clearSubsystemId() in the finally block to clear the subsystem ID in the thread context, preventing data corruption in subsequent requests.

Images