A log collection method, device, server, storage medium and system

Abstract

The application provides a log collection method and device, a server, a storage medium and a system. The method is applied to a heterogeneous network device system and includes the following steps: receiving a first log data packet of a first device; receiving a second log data packet of a second device sent by the first device; receiving a third log data packet sent by a station control system server; generating structured log data according to the first log data packet, the second log data packet and the third log data packet, and storing the structured log data into a log database; performing log correlation query in the log database, and locating a target device with a fault and corresponding fault information according to a query result. The technical solution can realize full-link correlation analysis of log data by relying on a log system server, shorten troubleshooting time and improve problem processing efficiency.

Description

Technical Field

[0001] This application relates to the field of industrial automation technology, and in particular to a log collection method, device, server, storage medium and system. Background Technology

[0002] In complex industrial automation systems, there is often a heterogeneous network device system composed of various devices. Such systems may include devices running different operating systems and communication protocols. For example, in a heterogeneous network device system of a photovoltaic power station, multiple string photovoltaic inverters are connected to a sub-array controller via a physical communication power line carrier PLC or a serial bus RS485 link. The sub-array controller communicates with the plant-level station control system via fiber optic Ethernet. The project site contains heterogeneous network power line carrier, RS485, fiber optic, and Ethernet.

[0003] When a system malfunctions, operations and maintenance (O&M) personnel need to check the operational logs of each device to locate the problem. However, due to the heterogeneity of devices and the diversity of protocols, the formats, storage methods, and access interfaces of log data vary, making log collection difficult. Furthermore, the scattered and unstructured log data makes cross-device business request tracing and fault correlation analysis extremely complex. Currently, O&M personnel typically need to manually log into each device to view the logs and then perform correlation analysis based on experience. This method is inefficient, error-prone, and makes it difficult to quickly and accurately locate the root cause of the fault. Summary of the Invention

[0004] This application provides a log collection method, device, server, storage medium, and system to solve the problem that when a heterogeneous network device system experiences a device failure, logs from each device need to be collected manually, and the source of the failure needs to be analyzed manually, resulting in low efficiency in problem handling.

[0005] Firstly, a log collection method is provided, applied to a heterogeneous network device system, the heterogeneous network device system including at least one first device acting as a gateway proxy; at least two second devices communicating with the first device via a first communication protocol; a station control system server communicating with the first device via a second communication protocol; and a log system server communicating with the first device and the station control system server via the second communication protocol. The method is executed by the log system server, including: receiving a first log data packet from the first device; receiving a second log data packet from the second device sent by the first device; receiving a third log data packet sent by the station control system server; generating structured log data based on the first log data packet, the second log data packet, and the third log data packet, and storing the structured log data in a log database; performing log association queries in the log database, and locating the target device with a fault and its corresponding fault information based on the query results.

[0006] In heterogeneous network device systems, by setting up a log system server as a central node, log data packets from different sources are collected uniformly and processed into structured log data, which is then stored in a unified log database. Correlation queries on the log data within this centralized database allow for accurate location of faulty devices and fault information without manual intervention. This effectively solves the problem of scattered and inconsistent log data formats in heterogeneous network device systems. Furthermore, the log system server enables end-to-end correlation analysis of log data, shortening troubleshooting time and improving problem-solving efficiency.

[0007] In conjunction with the first aspect, in one possible implementation, the station control system server is pre-installed with a log collection plugin, which is used to convert the initial log data packet of the station control system server according to a preset log specification format to generate the third log data packet.

[0008] Installing a log collection plugin in the station control system service eliminates the need to modify the core business code of the station control system server. Log collection is achieved through a plug-in approach, which reduces system complexity and coupling, improves deployment convenience and security, and ensures that log data from the station control system server conforms to a unified standard, laying a solid foundation for subsequent correlation analysis and structured storage.

[0009] In conjunction with the first aspect, in one possible implementation, the step of performing log association queries in the log database and locating the target device with a fault and the corresponding fault information based on the query results includes: horizontally filtering the structured log data in the log database according to log type and time range to obtain similar log records from different devices within the same time period; vertically associating the structured log data in the log database according to the transaction tracking identifier assigned to the business request to reconstruct the processing link of the business request as it flows through different devices; and comparing and analyzing the results of the horizontal filtering and the results of the vertical association to locate the target device with a fault in the processing link and the corresponding fault information.

[0010] When performing correlation queries on the log database, combining the results of horizontal and vertical analysis can effectively ensure the comprehensiveness of the correlation analysis. Horizontal analysis can discover some systemic and common problems (such as network-wide jitter at a certain moment), while vertical analysis can track and locate the business processing flow and pinpoint the root cause of individual business failures, effectively ensuring the efficiency and accuracy of problem handling by the log system server.

[0011] In conjunction with the first aspect, in one possible implementation, the first device is configured to collect initial log data packets from the second device by extending the first communication protocol, and after conversion according to the preset log specification format, generate the second log data packets and send them to the log system server.

[0012] In conjunction with the first aspect, in one possible implementation, the first communication protocol includes an asynchronous serial communication protocol; the first device is configured to collect initial log data packets from the second device by extending the first communication protocol, and after conversion according to the preset log specification format, generate the second log data packet and send it to the log system server. Specifically, the first device is configured to initiate a log collection request to the second device using an extended asynchronous serial communication protocol function code, the extended asynchronous serial communication protocol function code being used to instruct the second device to return the initial log data packet of the second device; after receiving the initial log data packet of the second device, the first device parses and reassembles the initial log data packet of the second device according to the preset log specification format, generates the second log data packet, and sends it to the log system server.

[0013] By extending the first communication protocol, traditional underlying devices (i.e., the second device) that originally did not support standard log output can also have their log data collected and uploaded in a standardized manner through protocol extension.

[0014] In conjunction with the first aspect, in one possible implementation, before performing a log correlation query in the log database and locating the target device with the fault and the corresponding fault information based on the query results, the method further includes:

[0015] The system receives a query request, which is triggered by the human-computer interaction interface provided by the log system server, including a web query interface; after performing a log association query in the log database and locating the target device with the fault and the corresponding fault information based on the query results, the system further includes: returning the target device with the fault and the corresponding fault information to the human-computer interaction interface.

[0016] Users can access the log system server anytime, anywhere via a browser without installing a dedicated client, which improves the ease of use and accessibility of the log system server.

[0017] Secondly, a log query device is provided, which is installed in a log system server in a heterogeneous network device system. The heterogeneous network device system includes at least one first device acting as a gateway proxy; at least two second devices communicating with the first device via a first communication protocol; a station control system server communicating with the first device via a second communication protocol; and the log system server communicating with the first device and the station control system server via the second communication protocol. The log query device includes: a receiving module for receiving a first log data packet from the first device, receiving a second log data packet from the second device sent by the first device, and receiving a third log data packet sent by the station control system server; a generating module for generating structured log data based on the first log data packet, the second log data packet, and the third log data packet, and storing the structured log data in a log database; and a positioning module for performing log association queries in the log database and locating the target device with a fault and its corresponding fault information based on the query results.

[0018] Thirdly, a log system server is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the first aspect.

[0019] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method as described in the first aspect.

[0020] Fifthly, a heterogeneous network device system is provided, the heterogeneous network device system comprising: at least one first device acting as a gateway proxy; at least two second devices communicating with the first device via a first communication protocol; a station control system server communicating with the first device via a second communication protocol; and a log system server communicating with the first device and the station control system server via the second communication protocol; wherein the log system server is used to perform the steps of the method as described in the first aspect.

[0021] This application can achieve the following technical effects: In a heterogeneous network device system, by setting up a log system server as a central node, log data packets from different devices in the system are collected uniformly, and the log data packets from different sources are processed into structured log data and stored in a unified log database. The log data can be correlated and queried in the unified log database, and the faulty device and fault information can be accurately located without relying on manual intervention. This effectively solves the problem of scattered and inconsistent log data in heterogeneous network device systems, and the log system server can be used to realize full-link correlation analysis of log data, shortening the fault diagnosis time and improving the efficiency of problem handling. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the architecture of an existing heterogeneous network device system.

[0023] Figure 2 This is a schematic diagram of the architecture of an existing heterogeneous network equipment system for a photovoltaic power station.

[0024] Figure 3 This application provides a schematic diagram of the architecture of a heterogeneous network device system.

[0025] Figure 4 A schematic diagram of the architecture of a heterogeneous network equipment system for a photovoltaic power station is provided in the embodiments of this application;

[0026] Figure 5 A flowchart illustrating a log collection method provided in an embodiment of this application;

[0027] Figure 6 A flowchart illustrating another log collection method provided in an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of the structure of a log collection device provided in an embodiment of this application;

[0029] Figure 8 This is a schematic diagram of the structure of a log system server provided in an embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0031] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed differently from the module division in the device or the order in the flowchart. Moreover, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0032] This application is applicable to industrial automation scenarios, particularly in heterogeneous network device systems where faulty devices need to be located and identified. To better understand this application, an existing heterogeneous network device system is described below; please refer to [link to relevant documentation]. Figure 1 This is a schematic diagram of the structure of an existing heterogeneous network device system. For example... Figure 1 The heterogeneous network device system shown includes: a station control system server, and at least one device 1, which maintains communication connections with at least two devices 2. The station control system server communicates with device 1 using communication protocol A, and device 2 communicates with device 1 using communication protocol B.

[0033] In such heterogeneous network device systems, maintenance personnel face the following challenges in the event of a failure: First, due to the heterogeneity of the devices and the diversity of protocols, the log data generated by different devices varies in format, storage method, and access interface, making unified log collection and parsing extremely difficult. Second, a complete business request (such as power regulation in a photovoltaic power station) often requires the collaboration of multiple devices. When a failure occurs, maintenance personnel need to manually log in to each device, collect scattered and unstructured logs, and perform cross-device correlation analysis based on experience. This method is inefficient, prone to errors, and makes it difficult to quickly and accurately locate the root cause of the failure. Furthermore, this method of relying on manual troubleshooting is also difficult to meet the real-time requirements of fault response in industrial automation scenarios.

[0034] by Figure 2Taking the heterogeneous network equipment system of the photovoltaic power station shown as an example, this system typically includes a hybrid architecture where string inverters are connected to sub-array controllers via power line carrier (PLC) or RS485 bus, and the sub-array controllers then communicate with the station control system server via fiber optic Ethernet. In such field integration projects, once a communication or service anomaly occurs, existing fault location methods usually expose three major pain points:

[0035] Firstly, there's the issue of single-device logs: When equipment malfunctions or experiences abnormal operation, analyzing single-device logs primarily involves inserting a USB drive into a single inverter device or connecting a mobile phone via Bluetooth to the inverter's Bluetooth channel to obtain the device's log files. However, when a sub-array controller experiences operational abnormalities or equipment malfunctions, querying the sub-array controller's logs requires not only querying the logs of one sub-array controller but also querying the logs of each inverter device connected to that sub-array controller. Therefore, a method is urgently needed to batch obtain logs from multiple devices.

[0036] Secondly, there is the issue of log analysis: After manually obtaining logs from multiple devices, it is necessary to verify the time information of upstream and downstream logs to determine at which stage the problem occurred. Manually reviewing logs is time-consuming and labor-intensive.

[0037] Thirdly, there is the issue of timeliness: logs are only checked and analyzed after a problem or malfunction occurs, which affects the efficiency of on-site equipment in resolving the issue. It is necessary to quickly locate the problem and provide early warnings.

[0038] In view of this, this application provides a log collection method, apparatus, server, storage medium and system, which aims to improve the log collection efficiency and correlation analysis capability when a heterogeneous network device system experiences a device failure, so as to quickly locate the faulty device and efficiently resolve the current fault.

[0039] Please see Figure 3 This is a schematic diagram of a heterogeneous network device system provided in an embodiment of this application. Figure 3 As shown, the heterogeneous network device system 10 may include, but is not limited to: a station control system server 101, a log system server 102, at least one first device 103, and at least two second devices 104.

[0040] The station control system server 101 and the log system server 102 are communicatively connected, for example, through a second communication protocol for data transmission. The station control system server 101 can serve as the control core of the heterogeneous network device system 10, responsible for monitoring and managing the lower-level devices. The log system server 102 is dedicated to implementing the log collection method provided in this application embodiment, responsible for collecting, storing, and analyzing log data from various devices in the system.

[0041] In one embodiment, the log system server 102 and the station control system server 101 can be the same server. That is, the log system service is deployed on the station control system server 101, without the need to set up a separate server.

[0042] At least one first device 103 is communicatively connected to the log system server 102. The first device 103 may be a type of communication management unit and gateway device, which can generate operation logs and manage multiple second devices 104 connected to it.

[0043] At least two second devices 104 are communicatively connected to their corresponding first devices 103, for example, by transmitting data via a first communication protocol. The second devices 104 can be various heterogeneous terminal devices in the field, such as different types of sensors or actuators. Each second device 104 also generates its own status log and operation log during operation.

[0044] What needs further elaboration is that, Figure 3 The three-tier architecture (server layer, first device layer, second device layer) shown is merely an exemplary implementation, and the system architecture protected by this application is not limited thereto. In practical applications, the heterogeneous network device system 10 can be a tree or chain structure with more levels. For example, a third device (not shown in the figure) can be communicatively connected below the second device 104, and a fourth device (not shown in the figure) can be further connected below the third device, and so on. In other words, the first device 103 and the second device 104 are defined relative to their logical positions in the entire device hierarchy, where the "Nth device" can act as a parent node, managing one or more "N+1th devices" below it. Log collection requests and log data can be forwarded downwards and converged upwards along this device chain. Therefore, the scope of protection of this application covers such multi-level heterogeneous network device systems.

[0045] Through the above system architecture, the log system server 102 can efficiently and centrally acquire logs from different levels and types of devices.

[0046] It should be noted that, Figure 3 The number of devices shown is merely an example. In practical applications, the number of the first device 103 and the second device 104 can be expanded according to specific scenarios, and their connection topology may also differ. In one embodiment, the first communication protocol and the second communication protocol can be different communication protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), asynchronous serial communication protocol (e.g., Modbus), process fieldbus (PROFIBUS), Ethernet, etc.

[0047] In this embodiment, when the log system server 102 receives a log collection instruction (which may be triggered by the station control system server 101 or automatically generated by the log system server 102 at regular intervals), it collects logs from various devices in the system through a unified interface. The first device 103 collects its own log data and receives log data from the second device 104. Finally, the first device 103 reports its own log data and the log data of all the second devices 104 it manages to the log system server 102.

[0048] Log system server 102 acts as a central node, uniformly collecting log data packets from the system and processing log data packets from different sources into structured log data, which is then stored in a unified log database. The centralized database allows for correlation queries of log data, enabling accurate location of faulty devices and fault information without manual intervention. This effectively solves the problem of scattered and inconsistent log data formats in heterogeneous network device systems. Furthermore, the log system server enables end-to-end correlation analysis of log data, shortening troubleshooting time and improving problem-solving efficiency.

[0049] Please see Figure 4 This illustrates the architecture of a heterogeneous network device system in a specific embodiment of this application. Figure 4 This can be understood as... Figure 3 The general architecture shown is a specific instantiation in a particular application scenario (such as a photovoltaic power generation monitoring system). Figure 4 In the system shown: the station control system server 101 specifically represents the "station control layer system". The log system server 102 specifically represents an independent "log system service". The dashed lines in the diagram clearly indicate the flow of log data. The first device 103 specifically represents a "subarray controller". Each subarray controller acts as a regional management unit and gateway agent. The second device 104 specifically represents an "inverter". Each subarray controller manages multiple inverters under it.

[0050] In addition, the system also demonstrates "photovoltaic modules" as monitored terminal units connected to the inverter. According to the previous definition of multi-level, these "photovoltaic modules" correspond to the third device. They ultimately report log data to the log system service (log system server 102) through the inverter (second device 104) and the sub-array controller (first device 103).

[0051] Therefore, Figure 4The actual architecture is a four-layer structure: "station control layer system—subarray controller—inverter—photovoltaic module". As a feasible implementation, the log system service can be deployed on a separate physical server or virtual server, running as a system background service. This service is primarily responsible for the collection, storage, analysis, and querying of logs, and can provide a web interface, allowing maintenance personnel to access and query them using a browser, thereby simplifying client deployment.

[0052] In this implementation, the specific process of log collection and processing may include the following steps:

[0053] First, a unified upstream and downstream logging standard is defined. This standard defines several key fields that log data must include, including but not limited to: message number, gateway device number, device number, message type, message link stage number, message time, and message content. This standard provides a unified conversion standard for log data of different formats generated by different devices.

[0054] Secondly, non-intrusive log collection for the station control layer system is implemented. A dedicated log collection plugin is installed on the station control layer system server. This plugin periodically and automatically retrieves log files generated by the station control layer system server itself, parses and converts them into the log format specified above, and then uploads them to the log system service. This method does not require modification of the station control layer system server's own code, achieving non-intrusive log collection.

[0055] Secondly, hierarchical collection and proxy uploading of device-level logs are implemented. Subarray controllers periodically collect their own logs and upload them directly to the log system service according to a standardized format. For lower-level devices such as inverters, file reading functionality is added by extending heterogeneous network communication protocols (such as RS485 bus and power line communication). Using this function, the subarray controller actively collects log files from the inverters connected to it, parses them, and converts them into a standardized log format. Subsequently, the subarray controller, acting as a gateway proxy, uploads its own logs and the logs of the inverters it manages (which may also include logs from photovoltaic modules) to the log system service.

[0056] Finally, unified management, display, analysis, and querying of logs are implemented. The log system service processes logs collected in batches from various sources, transforming log data packets from different sources into structured log data and storing it in a unified log database. Within this centralized database, log data is correlated and queried to locate faulty devices and corresponding fault information. Maintenance personnel can use the web interface provided by the log system service to perform batch queries and filters on massive amounts of logs, thereby quickly locating faults.

[0057] Through the above implementation method, when the log system service initiates data collection, the log data is reported level by level along the path of "PV module -> inverter -> subarray controller -> log system service", and is integrated and formatted at each level. When a PV module or inverter in the system fails, the log system service can use standardized fields to perform correlation queries, quickly locate the root cause of the fault, and greatly improve the operation and maintenance efficiency in complex heterogeneous network equipment systems.

[0058] Based on the above system, this application embodiment also provides a log collection method applied to a log system server 102, which will be described in detail below with reference to the flowchart.

[0059] Please refer to the following: Figure 5 This is a flowchart illustrating a log collection method provided in an embodiment of this application. Figure 5 The log collection methods shown include:

[0060] S501, The log system server receives the first log data packet from the first device.

[0061] It should be noted that the first device refers to the device that acts as a gateway proxy in a heterogeneous network device system, such as... Figure 4 The first device is a subarray controller. It can manage lower-level devices (such as the second device) and maintain communication with the upper-level server.

[0062] It should also be noted that the first log data packet refers to a log data packet containing the operating information of the first device itself. For example, the log data may include: memory status, network operating status, service execution status, changes in the number of connected second devices, etc.

[0063] In one feasible implementation, the first log data packet is a log data packet converted from a preset log specification format, so as to ensure that the log system server can effectively interpret and analyze the first log data packet after receiving it.

[0064] The preset log format can be predefined by the log system server. As one possible implementation, the preset log format includes, but is not limited to, the definition of the following: message number, gateway device number, device number, message type, message link stage number, message time, and message content.

[0065] In one feasible implementation, the log system server can receive the first log data packet from the first device via a second communication protocol. This second communication protocol includes, but is not limited to, fiber optic Ethernet.

[0066] S502, The log system server receives the second log data packet from the second device sent by the first device.

[0067] It should be noted that the second device refers to the field terminal equipment managed by the first device, such as... Figure 4 The inverter in the system. This second device can perform specific tasks and generate operation logs. The second log data packet of this second device refers to the log data packet generated by the second device, the content of which reflects the specific operating status of the second device, such as voltage, current, power, fault codes, and service execution status. This second log data packet can be forwarded to the log system server by the first device.

[0068] In one feasible implementation, the second log data packet can be a log data packet generated by the first device after converting the initial log data packet of the second device through a preset log specification format, so as to ensure that the log system server can effectively interpret and analyze the second log data packet after receiving it.

[0069] In another feasible implementation, the first device can integrate or package the second log data packets collected from all the second devices with its own first log data packets, and then send them together to the log system server. The log system server receives the first log data packets and the second log data packets from all the second devices through a second communication protocol.

[0070] S503, the log system server receives the third log data packet sent by the station control system server.

[0071] It should be noted that the station control system server can be the control core of this heterogeneous network device system, responsible for global monitoring, data display, and issuing scheduling commands, such as... Figure 4 The station control layer system.

[0072] It should also be noted that the third log data packet refers to the operation log data generated by the station control system server, which may include user operation records, system-level alarms, business instructions sent to subordinate devices and their response results, etc.

[0073] As a feasible implementation, the station control layer system server can be equipped with a log collection plugin. This plugin can non-intrusively monitor the log data of the station control layer system server, periodically (e.g., every minute) extract newly added log content, format its initial log data packets into standardized data packets (i.e., third log data packets) according to a preset log specification format, and actively push them to the log system server. The log system server can receive these third log data packets through a second communication protocol.

[0074] S504. The log system server generates structured log data based on the first log data packet, the second log data packet, and the third log data packet, and stores the structured log data in the log database.

[0075] As a feasible implementation method, in order to make the storage and analysis of log data more convenient, the log system server can parse, clean and transform the received first log data packet, second log data packet and third log data packet, and unify them into a format that is easy for the log system server to query and analyze quickly, namely the structured log data, and then store it in the log database.

[0076] As a feasible implementation, given the large volume of logs generated by the devices, this structured log data can be stored and categorized by tags, with each tag representing a specific type of monitoring metric or event. For example, a log entry from a subarray controller regarding communication status can be structured as a record containing "tags": {"category": "communication", "status": "disconnected"}. This tag-based structure (such as temperature, communication, power) greatly facilitates subsequent aggregation queries and correlation analysis.

[0077] S505 The log system server performs log association queries in the log database and locates the target device with the fault and the corresponding fault information based on the query results.

[0078] It should be noted that the target device refers to the physical device or logical unit identified as the root cause of the fault after correlation analysis. For example... Figure 4 As shown, the target device can be a subarray controller, an inverter, etc. There can be one or more target devices.

[0079] It should also be noted that the fault information refers to the specific data extracted from the log database that describes the abnormal state of the target device. Its content includes, but is not limited to: device status code, abnormal timestamp, precise time of fault occurrence, abnormal performance index thresholds (such as current overload, abnormal DC side voltage, sudden drop in AC side power, etc.), abnormal environmental conditions (excessive internal temperature), and abnormal communication conditions (such as interruption of connection with the upper-level controller or lower-level device).

[0080] As a feasible implementation, the log system server can perform log correlation queries in the log database through periodic polling analysis and / or event-triggered analysis. Periodic polling analysis can involve configuring a scheduled task on the log system server to automatically execute a correlation query script at a predetermined period (e.g., once per hour) to perform a health scan of the logs of heterogeneous network device systems over a past period, aiming to proactively detect potential faults or performance degradation trends. Event-triggered analysis can occur when a heterogeneous network device system generates a clear fault alarm; this alarm event can automatically trigger the log system server to perform a targeted, real-time correlation query to quickly locate the root cause. Alternatively, the correlation query can be manually triggered by the user.

[0081] In one embodiment, a log correlation query is performed in the log database, and the target device with the fault and the corresponding fault information are located based on the query results, including:

[0082] S5051. Horizontally filter the structured log data in the log database according to log type and time range to obtain similar log records from different devices within the same time period.

[0083] For example, such as Figure 4 In the heterogeneous network device system shown, assuming an alarm for "abnormal power generation in the eastern section of the photovoltaic array" is received, the user can set a time window (e.g., 10 minutes before the alarm occurs) and filter all log records related to "power generation," "communication interruption," and "equipment failure" within that time period. Through horizontal comparison, independent events of multiple devices can be quickly correlated to the same timeline, forming a preliminary outline of the fault development.

[0084] S5052. Based on the transaction tracing identifier assigned to the business request, perform vertical correlation on the structured log data in the log database to reconstruct the processing link of the business request as it flows through different devices.

[0085] As a feasible implementation, the station control system server can assign a globally unique transaction tracking identifier to each important business request. This transaction tracking identifier is passed down the chain of command as the business request flows between devices. For example: Figure 4The station control layer system issues the command "Increase the power of subarray controller A to 100kW" and assigns a tracking transaction identifier (Tx12345) to this command. The station control layer system logs: "[Tx12345] Issued power increase command to subarray controller A". After receiving the command, subarray controller A logs: "[Tx12345] Received power increase command, started execution". Subarray controller A sends commands to inverter-01 and inverter-02, including Tx12345 in the command. Inverter-01 logs: "[Tx12345] Received power setting command, target power 50kW". Inverter-02 logs similarly. When troubleshooting the problem of "power adjustment command not taking effect", the log system server can query Tx12345 in the log database to completely reconstruct the complete execution path of this command from the station control layer to the subarray controller, and then to each inverter, accurately locating at which stage the delay or failure occurred.

[0086] S5053. By comparing and analyzing the results of horizontal screening and vertical correlation, the target device with the fault and the corresponding fault information in the processing link are located.

[0087] It should be noted that the log system server can cross-validate and comprehensively analyze the results of horizontal filtering and vertical correlation to pinpoint the faulty equipment and the cause of the fault.

[0088] For another example, combining the two examples above, suppose when querying Tx12345, it is found that inverter-01 has no relevant execution logs, but at the same time, horizontal filtering reveals that it has logs indicating "abnormal DC input voltage" during the command issuance period. Then it can be diagnosed that the root cause of the power regulation command not fully taking effect is not a command transmission problem (because the vertical link is intact), but rather a hardware or input anomaly in inverter-01 itself (revealed by the horizontal logs), causing it to be unable to execute the command. The fault location is precise down to the specific device and the specific fault information (abnormal input voltage).

[0089] As a feasible implementation, the log system server and the station control system server can be the same server. That is, a log system service module can be added to the station control system server to implement all the functions and steps of the log system server shown in this application.

[0090] As can be seen, through the embodiments of this application, a log system server is set up in a heterogeneous network device system. The log system server serves as a central node to uniformly collect log data packets from different devices in the system. Log data packets from different sources are processed into structured log data and stored in a unified log database. The log data can be correlated and queried in the unified log database. Without relying on manual intervention, faulty devices and fault information can be accurately located. This effectively solves the problem of scattered and inconsistent log data in heterogeneous network device systems. Furthermore, the log system server can be used to achieve full-link correlation analysis of log data, shortening fault diagnosis time and improving problem handling efficiency.

[0091] Please refer to the following: Figure 6 This is a flowchart illustrating another log query method provided in an embodiment of this application.

[0092] S601, The first device sends a first log data packet and the second device sends a second log data packet.

[0093] It should be noted that the first device can act as a gateway proxy, not only collecting its own log data packets but also collecting log data packets from the second device described below and performing preliminary processing. In essence, the first device plays a dual role as a data collection proxy and a protocol conversion gateway, shielding the network heterogeneity and protocol differences of the lower-layer second device, thus enabling batch collection of logs from the second device.

[0094] As a feasible implementation, the first device can send log collection commands to multiple connected second devices to achieve batch collection. After receiving the log collection command, the second device sends its own initial log data packet to the first device through the first communication protocol.

[0095] In one embodiment, the first device is configured to collect initial log data packets from the second device by extending the first communication protocol, and after converting them according to a preset log specification format, generate a second log data packet and send it to the log system server.

[0096] It should be noted that the extension of the first communication protocol described in this application may refer to the customization of new functions within the scope of function codes reserved or undefined in the standard communication protocol, so as to realize log collection operations not supported by the standard protocol.

[0097] In one embodiment, the first communication protocol includes an asynchronous serial communication protocol; the first device is configured to collect initial log data packets from the second device by extending the first communication protocol, and after converting them according to a preset log specification format, generate a second log data packet and send it to the log system server. Specifically, the first device is configured to initiate a log collection request to the second device using an extended asynchronous serial communication protocol function code, the extended asynchronous serial communication protocol function code being used to instruct the second device to return the initial log data packet of the second device; after receiving the initial log data packet of the second device, the first device parses and reassembles the initial log data packet of the second device according to the preset log specification format, generates a second log data packet, and sends it to the log system server.

[0098] For example, in such Figure 4 In the photovoltaic subarray shown, the first communication protocol can be an asynchronous serial communication protocol such as RTU based on the RS-485 physical layer. Figure 4 Taking the heterogeneous network device system shown as an example, the first device (subarray controller) can pre-configure the 0x14 function code field of the asynchronous serial communication protocol (RTU) to collect logs from the second device (inverter) connected to it. When it needs to collect log data packets from the second device (inverter), the first device (subarray controller) constructs an asynchronous serial communication protocol request frame, specifying the starting address and length of the log memory to be read. After receiving the request, the second device (inverter) recognizes the 0x14 function code as a log read instruction, and then packages the original log data of the specified memory area and returns it to the first device through an asynchronous serial communication protocol response frame. After receiving the response, the first device (subarray controller) extracts the original binary or text log. Subsequently, it parses and reassembles the log data packets of the second device (inverter) according to the preset log format specification, converting the initial log data packets of the second device (inverter) into second log data packets conforming to the preset log format specification. At the same time, the first device also converts its own log data packets into first log data packets according to the preset log format specification.

[0099] S602, The log system server receives the first log data packet from the first device.

[0100] S603, The log system server receives the second log data packet from the second device sent by the first device.

[0101] S604, The station control system server sends a third log data packet.

[0102] In one embodiment, the station control system server is pre-installed with a log collection plugin. The log collection plugin is used to convert the initial log data packets of the station control system server according to a preset log specification format and generate a third log data packet.

[0103] It should be noted that collecting log data from the station control system server via a log collection plugin has minimal impact on the server's existing operations, offering good maintainability and scalability. Furthermore, the plugin ensures that station control layer logs and device layer logs adhere to the same preset log format, achieving system-wide log standardization.

[0104] S605. The log system server receives the third log data packet sent by the station control system server.

[0105] S606. The log system server generates structured log data based on the first log data packet, the second log data packet, and the third log data packet, and stores the structured log data in the log database.

[0106] S607, the log system server receives query requests.

[0107] The query request is triggered by the human-computer interaction interface provided by the log system server, which includes a web query interface.

[0108] It should be noted that the human-computer interaction interface can be the touch screen of a terminal device (such as a mobile phone, computer, tablet, etc.), and the touch screen can display the WEB query interface provided by the log system.

[0109] As a feasible implementation method, the log system server can also periodically perform correlation queries on the logs.

[0110] For example, the query request can be a single-condition query request, or it can support combined queries, such as: "Query the logs of all error levels of device a in the last hour, and the transaction trace identifier is Req-12345".

[0111] S608 The log system server performs log association queries in the log database and locates the target device with the fault and the corresponding fault information based on the query results.

[0112] S609. The log system server returns the target device with the fault and the corresponding fault information through the human-machine interaction interface.

[0113] In this step, the log system server can finally present the query results on the human-computer interaction interface to help maintenance personnel to further handle the fault.

[0114] As a feasible implementation method, the log system server can display the target device with faults and the corresponding fault information in an intuitive form such as highlighting, charts or link diagrams. It can also provide further operations on the human-computer interaction interface, such as "mark as processed" and "generate diagnostic report", forming a closed loop of operation and maintenance.

[0115] As another feasible implementation, the log system server can also periodically correlate and query log data without requiring users to submit queries. If the log system server finds a faulty target device and corresponding fault information when performing log correlation queries in the log database, it can generate corresponding warning information and notify the operation and maintenance personnel through web page push, SMS push to the bound account, etc.

[0116] As can be seen, through the embodiments of this application, in a heterogeneous network device system, by reconstructing the first device (subarray controller) as a gateway proxy, it can automatically and in batches collect logs from its subordinate second devices by extending the first communication protocol (such as an asynchronous serial communication protocol), thus solving the problem of low efficiency in manual collection by a single machine. Simultaneously, a log collection plugin is deployed on the station control system server to ensure that its high-level business logs and device-level logs are output in a unified standard format, achieving the integration of heterogeneous network logs. Based on this, with the help of the human-computer interaction interface provided by the log system server, users can easily submit query requests. The log system server can quickly correlate the entire link logs, accurately locate faulty devices and their causes, and intuitively push the results to the user interface, realizing a transformation from "passive post-event troubleshooting" to "proactive and accurate diagnosis throughout the entire process" in operation and maintenance mode, greatly improving the operation and maintenance efficiency and system reliability of the heterogeneous network device system.

[0117] The method of this application has been described above; the apparatus of this application will be described below. Please refer to the following. Figure 7 This is a schematic diagram of the structure of a log collection device provided in an embodiment of this application, as shown below. Figure 7 As shown, the log collection device 70 is installed in the log system server of the aforementioned heterogeneous network device system. The heterogeneous network device system includes at least one first device acting as a gateway proxy; at least two second devices communicating with the first device via a first communication protocol; a station control system server communicating with the first device via a second communication protocol; and the log system server communicating with both the first device and the station control system server via the second communication protocol. The log collection device 70 includes:

[0118] The receiving module 701 is used to receive a first log data packet from the first device, a second log data packet from the second device sent by the first device, and a third log data packet sent by the station control system server.

[0119] The generation module 702 is used to generate structured log data based on the first log data packet, the second log data packet, and the third log data packet, and store the structured log data in the log database.

[0120] The positioning module 703 is used to perform log association queries in the log database and locate the target device with the fault and the corresponding fault information based on the query results.

[0121] It should be noted that the log collection device 70 described above can execute the log collection method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the log collection device 70 can be found in the log collection method provided in the embodiments of this application.

[0122] See Figure 8 , Figure 8 This is a schematic diagram of the structure of a log system server provided in an embodiment of this application. The log system server 80 includes a processor 801 and a memory 802. The memory 802 is connected to the processor 801, for example, via a bus.

[0123] Processor 801 is configured to support the corresponding functions in the method described in the above method embodiments. Processor 801 may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0124] Memory 802 is used to store program code, etc. Memory 802 may include volatile memory (VM), such as random access memory (RAM); memory 802 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 802 may also include combinations of the above types of memory.

[0125] The memory 802 is used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the log collection method in the embodiments of this application. The processor executes various functional applications and data processing of the log collection method by running the non-volatile software programs, instructions, and modules stored in the memory, thereby realizing the functions of the log collection method provided in the above method embodiments.

[0126] The memory 802 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function. The data storage area may store data created based on the use of the log acquisition device. In some embodiments, the memory may include memory remotely located relative to the processor, which can be connected to the log acquisition device via a network. Examples of such networks include, but are not limited to, the Industrial Internet, the Internet, local area networks, mobile communication networks, and combinations thereof.

[0127] The one or more modules are stored in the memory. When executed by the one or more processors, they perform the log collection method in any of the above method embodiments. For example, they perform the method steps described in the above method embodiments to realize the functions of the modules described in the above device embodiments.

[0128] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in the foregoing embodiments.

[0129] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0130] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A log collection method, characterized in that, The method is applied to a heterogeneous network device system, which includes at least one first device acting as a gateway proxy. At least two second devices are connected to the first device via a first communication protocol; The station control system server communicates with the first device via a second communication protocol; The log system server communicates with the first device and the station control system server via the second communication protocol; The method is executed by the log system server and includes: Receive the first log data packet from the first device; Receive the second log data packet from the second device sent by the first device; Receive the third log data packet sent by the station control system server; Structured log data is generated based on the first log data packet, the second log data packet, and the third log data packet, and the structured log data is stored in the log database; Perform log association queries in the log database, and locate the target device with the fault and the corresponding fault information based on the query results.

2. The method as described in claim 1, characterized in that, The station control system server is pre-installed with a log collection plugin, which is used to convert the initial log data packets of the station control system server according to a preset log specification format to generate the third log data packet.

3. The method as described in claim 1, characterized in that, The step of performing log correlation queries in the log database and locating the target device with the fault and the corresponding fault information based on the query results includes: The structured log data in the log database is horizontally filtered according to log type and time range to obtain similar log records from different devices within the same time period. Based on the transaction tracking identifier assigned to the business request, the structured log data in the log database is vertically correlated to reconstruct the processing link of the business request as it flows through different devices; By comparing and analyzing the results of horizontal screening with the results of vertical correlation, the target device with a fault in the processing link and the corresponding fault information are located.

4. The method as described in claim 2, characterized in that, The first device is configured to collect the initial log data packets of the second device by extending the first communication protocol, and after converting them according to the preset log specification format, generate the second log data packets and send them to the log system server.

5. The method as described in claim 4, characterized in that, The first communication protocol includes an asynchronous serial communication protocol; the first device is configured to collect initial log data packets from the second device by extending the first communication protocol, and after conversion according to the preset log specification format, generate the second log data packets and send them to the log system server, specifically: The first device is configured to initiate a log collection request to the second device using an extended asynchronous serial communication protocol function code, wherein the extended asynchronous serial communication protocol function code is used to instruct the second device to return the second device's initial log data packet; After receiving the initial log data packet from the second device, the first device parses and reassembles the initial log data packet from the second device according to the preset log specification format, and generates the second log data packet, which is then sent to the log system server.

6. The method as described in claim 1, characterized in that, Before performing log correlation queries in the log database and locating the faulty target device and corresponding fault information based on the query results, the method further includes: Receive a query request, which is triggered by the human-computer interaction interface provided by the log system server, and the human-computer interaction interface includes a web query interface; After performing a log correlation query in the log database and locating the target device with the fault and its corresponding fault information based on the query results, the process further includes: The human-computer interaction interface returns the target device with the fault and the corresponding fault information.

7. A log query device, characterized in that, The log query device is installed on the log system server in the heterogeneous network device system; the heterogeneous network device system includes at least one first device acting as a gateway proxy; At least two second devices are connected to the first device via a first communication protocol; The station control system server communicates with the first device via a second communication protocol; The log system server is connected to the first device and the station control system server via the second communication protocol; the log query device includes: The receiving module is used to receive a first log data packet from the first device, a second log data packet from the second device sent by the first device, and a third log data packet sent by the station control system server. The generation module is used to generate structured log data based on the first log data packet, the second log data packet, and the third log data packet, and to store the structured log data in the log database; The location module is used to perform log association queries in the log database and locate the target device with the fault and the corresponding fault information based on the query results.

8. A log system server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method as described in any one of claims 1 to 6.

10. A heterogeneous network device system, characterized in that, The heterogeneous network device system includes: At least one first device acting as a gateway proxy; At least two second devices communicate with the first device via a first communication protocol; The station control system server communicates with the first device via a second communication protocol; The log system server communicates with the first device and the station control system server via the second communication protocol; The log system server is used to perform the steps of the method as described in any one of claims 1 to 6.

Images