Fault log information processing method and electronic equipment

Abstract

The invention discloses a fault log information processing method and electronic equipment, system logs can be processed in real time by collecting log information from multiple nodes in real time, and key log information is screened out from a large number of logs according to preset filtering conditions (such as log levels and preset keywords). The key logs related to faults or abnormity can be quickly found, information overload is reduced, and then the log management efficiency of the system in the operation process is improved. According to the fault category corresponding to each piece of key log information, the fault category label is added for the key log information, so that subsequent quick positioning of related logs is facilitated, the key log information is stored in the target database in the preset data format, and the query efficiency of the log information is higher due to the uniform storage format. The system responds to the log information viewing instruction of the user, determines the to-be-viewed log information from the target database, and displays the result on the user query interface, so that maintenance personnel can quickly view and analyze the log.

Description

Technical Field

[0001] The present application relates to the technical field of unmanned driving software log monitoring and fault diagnosis, and in particular to a fault log information processing method and electronic equipment. Background Art

[0002] Currently, ROS2 (Robot Operating System 2) is widely adopted as the middleware framework for distributed module communication in areas such as autonomous driving systems, intelligent robots, and unmanned industrial control. During operation, each functional node in these systems (such as perception, positioning, path planning, and control) continuously outputs status information and operation logs. In particular, when encountering module anomalies, sensor timeouts, memory leaks, network outages, and other issues, the system automatically outputs relevant error, warning, and information logs through the / rosout topic. These operation logs are crucial for subsequent troubleshooting, security backtracking, and stability improvements.

[0003] In related technologies, ROS2 logs are saved offline in log files or output to the terminal. Developers need to manually collect log files and later perform troubleshooting through text search tools, text editors, visual analysis tools, etc. However, this offline log analysis method cannot process system logs in real time, resulting in low efficiency in the management of fault log information during the operation of ROS2. In addition, the current ROS2 prints all levels of log information by default, but on resource-constrained platforms (such as vehicle-mounted edge terminals), a large amount of log information will take up storage space and bandwidth, and maintenance personnel will not be able to quickly find key logs related to faults or anomalies in a large amount of log information. In summary, the current robot operating system has low efficiency in the management of fault log information during operation.

[0004] Therefore, how to improve the log management efficiency of the robot operating system during operation is an urgent problem that needs to be solved. Summary of the Invention

[0005] The present application provides a fault log information processing method and electronic device to at least solve the problem in the related art of how to improve the log management efficiency of a robot operating system during operation.

[0006] This application provides a method for processing fault log information, the method comprising: Collect multiple log information from multiple nodes in real time; Filtering the plurality of log information based on preset filtering rules to obtain a plurality of key log information; the preset filtering rules include: filtering based on a preset log level, and / or filtering based on preset keywords; According to the fault category corresponding to each key log information, add the corresponding fault category label to each key log information; The plurality of key log information are stored in a target database in a preset data format; the preset data format includes: log record timestamp, log level, log source node, log content and fault category label; In response to a log information viewing instruction input by a user, the log information to be viewed is determined from the target database according to the viewing conditions carried in the log information viewing instruction, and the log information to be viewed is displayed on the user query interface.

[0007] The present application also provides a fault log information processing device, comprising: Real-time collection module, used to collect multiple log information from multiple nodes in real time; An information screening module, configured to screen the plurality of log messages based on preset screening rules to obtain a plurality of key log messages; the preset screening rules include screening based on preset log levels and / or screening based on preset keywords; The fault classification module is used to add corresponding fault category labels to each key log information according to the fault category corresponding to each key log information; An information storage module is used to store the plurality of key log information in a target database in a preset data format; the preset data format includes: log record timestamp, log level, log source node, log content and fault category label; The information viewing module is used to respond to the log information viewing instruction input by the user, determine the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and display the log information to be viewed on the user query interface.

[0008] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned fault log information processing methods when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned fault log information processing methods are implemented.

[0010] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned fault log information processing methods when executed by a processor.

[0011] Through this application, the ROS2 system can collect log information from multiple nodes in real time, ensuring that the operating status of all nodes is recorded in a timely manner. Through real-time monitoring, system logs can be processed in real time. Key log information can be filtered out from a large number of logs based on preset filtering conditions (such as log level, preset keywords, etc.). This allows for the rapid identification of key logs related to faults or anomalies, reducing information overload and helping maintenance personnel quickly locate key issues, thereby improving the log management efficiency of the robot operating system during operation. Each key log information is labeled according to the corresponding fault category, facilitating the subsequent rapid location of related logs. Key log information is stored in a preset data format (including log record timestamp, log level, log source node, log content, and fault category label) in a target database. This unified storage format makes log information query conditions more specific and more efficient. Flexible and reasonable filtering rules can be preset based on actual needs to adapt to different monitoring scenarios, enabling targeted filtering of logs related to specific issues and improving the accuracy of fault diagnosis. The system responds to the user's log information viewing instruction, determines the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and displays the results on the user query interface, making it easy for maintenance personnel to quickly view and analyze the logs. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0013] Figure 1 A flowchart of a method for processing fault log information provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of a fault log information processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0014] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0015] It should be noted that, in the description of this application, the terms "include", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or electronic device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or electronic device. The terms "first", "second", etc. in this application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0016] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0017] Explanation of terms: ROS Node: In ROS (Robot Operating System), a node is a basic execution unit within the ROS system. It is an independent process responsible for performing a specific task. Nodes are a core concept in the ROS architecture, collaborating with each other through ROS communication mechanisms (such as topics, services, and actions) to complete complex robotic tasks. Each node is typically responsible for performing a specific task, such as sensor data acquisition (such as cameras and lidar), data processing (such as image recognition and path planning), control algorithms (such as motion control and robotic arm control), providing a user interface, or interacting with external systems. ROS2 supports high-frequency message communication between nodes, topic publish / subscribe mechanisms, service / action execution, parameter configuration, and system status logging.

[0018] Currently, ROS2 (Robot Operating System 2) is widely adopted as the middleware framework for distributed module communication in areas such as autonomous driving systems, intelligent robots, and unmanned industrial control. During operation, each functional node in these systems (such as perception, positioning, path planning, and control) continuously outputs status information and operation logs. In particular, when encountering module anomalies, sensor timeouts, memory leaks, network outages, and other issues, the system automatically outputs relevant error, warning, and information logs through the / rosout topic. These operation logs are crucial for subsequent troubleshooting, security backtracking, and stability improvements.

[0019] In related technologies, ROS2 logs are stored offline in log files or output to terminals. Developers need to manually collect log files and later perform troubleshooting using text search tools, text editors, and visual analysis tools. However, this offline log analysis method cannot process system logs in real time, resulting in inefficient management of ROS2 fault log information during operation. Furthermore, ROS2 currently prints all levels of log information by default. However, on resource-constrained platforms (such as in-vehicle edge terminals), the large amount of log information consumes storage space and bandwidth, making it difficult for maintenance personnel to quickly locate key logs related to faults or anomalies within the large amount of log information. Faced with complex faults, maintenance personnel are often forced to search for keywords based on experience. The lack of automatic fault classification makes it difficult to automatically attribute faults and quickly identify the fault category. Furthermore, traditional logs are stored in text format, containing free-form message content. This storage method has inconsistent fields, making it difficult for maintenance personnel to quickly review log content. In summary, the current robot operating system has inefficient management of fault log information during operation.

[0020] Based on the above problems, an embodiment of the present application provides a method for processing fault log information, and the method is described in detail in conjunction with the execution flow of the method for processing fault log information.

[0021] Reference Figure 1 As shown, the fault log information processing method provided by the embodiment of the present invention includes the following steps: S11. Collect multiple log information from multiple nodes in real time.

[0022] Among them, the node is the basic execution unit in ROS2, which is used to perform specific tasks, such as sensor data acquisition, data processing, motion control, path planning, positioning, control algorithms, etc.

[0023] Log information includes but is not limited to: log record timestamp, log level, log source node, and log content (message text).

[0024] Among them, the log level is divided into five levels according to severity, from low to high: DEBUG (debugging information, used to track program execution details), INFO (for general operation status prompts), WARN (for warnings of potential problems), ERROR (for recoverable errors), and FATAL (for serious errors that cause system crashes).

[0025] Specifically, the ROS2 system collects multiple log information from multiple nodes in real time, realizing real-time capture of running node logs.

[0026] In some embodiments, the above step S11 (collecting multiple log information from multiple nodes in real time) can be implemented as follows: Subscribe to the aggregation log topic; Through the aggregated log topic, multiple log information of multiple nodes can be obtained in real time.

[0027] Among them, topics are used for communication between nodes, and nodes exchange data by publishing or subscribing to topics.

[0028] The aggregate log topic is a topic in ROS2 that aggregates log information from all nodes. Subscribing to this topic allows you to retrieve logs from all nodes. The message type of the aggregate log topic is rosgraph_msgs / Log, which contains the log level (such as DEBUG, INFO, WARN, ERROR, FATAL), timestamp, node name, log content, etc.

[0029] Specifically, the aggregated log topic centrally manages logs in ROS, and through the aggregated log topic, multiple log information of multiple nodes can be obtained in real time.

[0030] For example, based on the ROS2 rclpy interface, a subscription node is built to continuously listen to aggregated log topics, receiving log information from all running nodes in real time in a non-blocking manner. rclpy is a Python client library for ROS2, used to interact with the ROS2 system in a Python environment. It provides functions such as creating nodes, publishing and subscribing to messages, calling services, and timers, allowing developers to write ROS2 nodes in Python. In non-blocking mode, after a program initiates an operation, it does not wait for the operation to complete, but returns immediately, allowing the program to continue executing other tasks. When the operation is completed, the program is notified of the completion through some mechanism (such as a callback function or event notification).

[0031] By subscribing to aggregated log topics, log information from all nodes is captured in real time, aggregated through a unified topic, and facilitated centralized management and monitoring. This not only avoids the need for each node to publish logs to multiple topics, reducing network bandwidth usage, but also enables real-time reception and processing of log information from multiple nodes, ensuring the timeliness and integrity of log data.

[0032] S12: Filter the multiple log information based on preset filtering rules to obtain multiple key log information.

[0033] The preset screening rules include: screening based on preset log levels, and / or screening based on preset keywords.

[0034] The log levels are ranked from low to high in order of severity: DEBUG (debugging), INFO (information), WARN (warning), ERROR (error), and FATAL (fatal). DEBUG is used to record detailed technical information and is usually used in the development and debugging stages. INFO is used to record important information during normal system operation, such as system startup, configuration loading, task completion, etc. These log messages are used to confirm the system operation status and usually do not contain error or exception information. WARN is used to indicate potential problems that may affect the normal operation of the system, but will not immediately cause system failure. These log messages require attention, but usually do not need to be processed immediately. ERROR is used to indicate serious problems that occur during system operation, which usually causes a certain function to not work properly, but the system as a whole can still operate. FATAL is used to indicate extremely serious problems that occur during system operation, which usually causes the system to crash or be unable to continue running. These log messages need to be processed immediately because they may affect the stability of the entire system.

[0035] Preset keywords can be set based on actual application scenarios. For example, preset keywords may include, but are not limited to, "timeout" and "segmentation fault." A segmentation fault is a runtime error in a computer program, typically occurring when the program attempts to access a memory area it does not have permission to access. It is a common cause of program crashes and typically indicates a serious bug.

[0036] Specifically, multiple log messages collected in real time are filtered according to the preset filtering rules to obtain multiple key log messages. Key log messages are log messages with a log level higher than or equal to a preset log level. Key log messages may also be log messages whose log content contains preset keywords. Key log messages may also be log messages with a log level higher than or equal to a preset log level and whose log content contains preset keywords.

[0037] Optionally, when the preset screening rule is screening based on a preset log level, the above step S12 (screening from the multiple log messages based on the preset screening rule to obtain multiple key log messages) can be implemented as follows: Determine whether the log level of the target log information is higher than or equal to the preset log level; If the log level of the target log information is higher than or equal to the preset log level, determining that the target log information is critical log information; If the log level of the target log information is lower than the preset log level, the target log information is determined to be non-critical log information.

[0038] Specifically, when the preset screening rule is to screen based on a preset log level, determine whether the log level of the target log information is higher than or equal to the preset log level; if the log level of the target log information is higher than or equal to the preset log level, determine that the target log information is critical log information; if the log level of the target log information is lower than the preset log level, determine that the target log information is non-critical log information.

[0039] For example, since the log levels are ranked from low to high in severity: DEBUG, INFO, WARN, ERROR, FATAL, in the embodiments of the present disclosure, the minimum collection log level can be set to WARN or ERROR, or other reasonable log levels. That is, one possible situation is that the critical log information is the log information with a log level higher than or equal to WARN, and another possible situation is that the critical log information is the log information with a log level higher than or equal to ERROR.

[0040] In a multi-node system, the volume of log information is enormous. Directly analyzing all logs is inefficient and prone to missing critical information. The disclosed embodiment uses preset log levels as screening criteria to quickly determine the importance of each log, identifying logs with a level higher than or equal to the preset level as critical log information, thereby significantly reducing the number of logs that require further processing.

[0041] Optionally, when the preset screening rule is screening based on preset keywords, the above step S12 (screening the multiple log information based on the preset screening rule to obtain multiple key log information) can be implemented as follows: Determine whether the log content of the target log information contains preset keywords; If the log content of the target log information contains the preset keyword, determining that the target log information is key log information; If the log content of the target log information does not include the preset keyword, it is determined that the target log information is non-critical log information.

[0042] Specifically, it is determined whether the log content of the target log information contains preset keywords. If the log content of the target log information contains the preset keywords, the target log information is determined to be key log information. If the log content of the target log information does not contain the preset keywords, the target log information is determined to be non-key log information.

[0043] For example, since the preset keywords may include but are not limited to: "timeout", "segmentation fault", etc., in the embodiment of the present disclosure, the key log information may be the log information whose log content contains the preset keyword "timeout", the key log information may also be the log information whose log content contains the preset keyword "segmentation fault", and the key log information may also be the log information containing other preset keywords.

[0044] Furthermore, the critical log information may be a log level higher than or equal to WARN, and the log content may include the preset keyword "timeout"; the critical log information may also be a log level higher than or equal to WARN, and the log content may include the preset keyword "timeout"; the critical log information may also be a log level higher than or equal to WARN, and the log content may include the preset keyword "segmentation fault", etc.

[0045] By pre-setting keywords, the system can automatically identify log messages containing these keywords and identify them as critical logs. This method can quickly locate logs related to specific issues, greatly reducing the number of logs that need further processing.

[0046] S13. Add corresponding fault category labels to each key log information according to the fault category corresponding to each key log information.

[0047] Specifically, we add fault category tags to each key log message based on the fault type it corresponds to. This classification and labeling method makes the log information more structured, facilitating subsequent query and analysis. During troubleshooting, operations and maintenance personnel can quickly locate relevant logs based on the fault category tags, reducing troubleshooting time.

[0048] S14: Storing the plurality of key log information in a target database in a preset data format.

[0049] The preset data format includes: log record timestamp, log level, log source node, log content and fault category label.

[0050] Specifically, multiple key log information is stored in the target database with five fields, namely: log record timestamp, log level, log source node, log content and fault category label.

[0051] In the embodiment of the present disclosure, by storing key log information in a preset data format in a target database and ensuring that each log information contains a log record timestamp, log level, log source node, log content, and fault category label, the consistency and standardization of key log information can be guaranteed, the system can effectively manage log information, improve monitoring efficiency and fault response capabilities, and optimize resource utilization.

[0052] S15 . In response to a log information viewing instruction input by the user, the log information to be viewed is determined from the target database according to the viewing conditions carried in the log information viewing instruction, and the log information to be viewed is displayed on the user query interface.

[0053] Specifically, in response to a log information viewing instruction input by a user, the log information to be viewed is determined from the target database according to the viewing conditions carried in the log information viewing instruction, and the log information to be viewed is displayed on the user query interface.

[0054] Optionally, the viewing conditions carried by the log information viewing instruction include: at least one query information of a target fault category label, a target log level, a target log record timestamp, a target keyword, and a target log source node.

[0055] By allowing users to include multiple query conditions (such as fault category tags, log levels, timestamps, keywords, log source nodes, etc.) in log information viewing commands, the system supports more flexible query methods. Users can combine these conditions according to actual needs to quickly locate the target log.

[0056] Specifically, in response to the log information viewing instruction input by the user, according to the viewing conditions carried by the log information viewing instruction, for example, at least one query information among the target fault category label, target log level, target log record timestamp, target keyword, and target log source node, the log information to be viewed is determined from the target database, and the log information to be viewed is displayed on the user query interface.

[0057] Exemplarily, based on the target log record timestamp, it is determined to display the 10 log information most recent to the current moment.

[0058] In some embodiments, the instruction query method of the log information viewing instruction includes: a command line query instruction or a control query instruction.

[0059] The above step S15 (in response to the log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a command line query instruction input by a user, determining log information to be viewed from the target database according to a viewing condition carried in the command line query instruction, and displaying the log information to be viewed on the user query interface in a first display manner; or; In response to a control query instruction input by a user, log information to be viewed is determined from the target database according to the viewing conditions carried by the command line query instruction, and the log information to be viewed is displayed on the user query interface in a second display mode.

[0060] The first log information viewing instruction is a command line query instruction input by the user. Accordingly, the first user query interface is a command line query interface.

[0061] Specifically, the ROS2 system receives a first log information viewing instruction input by the user through a command line, responds to the first log information viewing instruction, determines the log information to be viewed from the target database according to the conditions in the first log information viewing instruction, and displays the log information to be viewed on the first user query interface.

[0062] For example, the first log information viewing instruction may be "display the most recent 10 log information." In response to this first log information viewing instruction, the 10 log information with the most recent log record timestamps from the current time are determined as the log information to be viewed, and the log information to be viewed is displayed on the command line query interface. The system displays the retrieved log information in a specific format (such as a table or list) on the user query interface.

[0063] In the disclosed embodiments, an intuitive command line interface is provided, allowing users to conveniently enter query commands. Users can flexibly construct query commands to meet diverse query requirements. For example, users can query logs based on specific conditions (such as time range, log level, fault category, etc.), facilitating rapid problem location. Log information is displayed in structured text, making it easier for users to understand and analyze.

[0064] The second log information viewing instruction is a control query instruction input by the user. Correspondingly, the second user query interface is a graphical query interface.

[0065] Specifically, the ROS2 system receives a second log information viewing instruction input by the user through the control, responds to the second log information viewing instruction, determines the log information to be viewed from multiple key log information according to the conditions in the second log information viewing instruction, and displays the log information to be viewed on the second user query interface.

[0066] For example, the second log information viewing instruction may be "display memory-related log information." In response to this second log information viewing instruction, the system determines that memory-related log information among the multiple key log information items is the log information to be viewed, and displays the log information to be viewed on the graphical query interface. The system displays the retrieved log information on the user query interface in a specific format (e.g., a table, list, etc.).

[0067] In the disclosed embodiments, an intuitive graphical interface is provided, allowing users to conveniently enter query commands. Users can flexibly construct query commands to meet diverse query requirements. For example, users can query logs based on specific conditions (such as time range, log level, fault category, etc.), facilitating rapid problem location. The graphical interface displays log information, making it easier for users to understand and analyze.

[0068] In the disclosed embodiments, the ROS2 system can collect log information from multiple nodes in real time, ensuring that the operating status of all nodes is recorded promptly. Through real-time monitoring, abnormal behavior can be detected in advance and faults can be prevented. Key log information can be filtered from a large number of logs based on preset filtering conditions (such as log level and preset keywords). This allows for rapid identification of key logs related to faults or anomalies, reducing information overload and helping maintenance personnel quickly locate critical issues, thereby improving the efficiency of log management during the operation of the robot operating system. Each key log information is labeled according to the corresponding fault category, facilitating the subsequent rapid location of related logs. Key log information is stored in a target database in a preset data format (including log record timestamp, log level, log source node, log content, and fault category label). This unified storage format makes log query conditions more specific and more efficient. Flexible and reasonable filtering rules can be configured according to actual needs to adapt to different monitoring scenarios, enabling targeted filtering of logs related to specific issues and improving the accuracy of fault diagnosis. The system responds to the user's log information viewing instruction, determines the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and displays the results on the user query interface, making it easy for maintenance personnel to quickly view and analyze the logs.

[0069] In some embodiments, before executing the above step S13 , the method further includes: adding a corresponding fault category label to each key log information according to the fault category corresponding to each key log information.

[0070] Optionally, before performing the above steps (adding corresponding fault category labels to each key log message based on the fault category corresponding to each key log message), you can also perform the following steps: Each key log information is classified according to a preset classification rule to obtain a corresponding fault category of each key log information; the preset classification rule includes a plurality of fault category tags and a keyword set corresponding to each fault category tag.

[0071] Specifically, the configuration file defines multiple classification categories, each containing a set of classification keywords. The classification function accepts the log text and the configuration file as parameters and converts the log text to lowercase to facilitate case-insensitive matching. It then iterates over each category and classification keyword in the configuration file, using regular expressions to check whether the log text contains the classification keyword. If a matching classification keyword is found, the corresponding category is returned. If no classification keyword is matched, "uncategorized" is returned. "Uncategorized" is used to identify log information that does not match any of the preset classification tags.

[0072] Exemplarily, multiple categories include but are not limited to: memory, network, crash, sensor, among which the keywords included in the memory category may be: insufficient memory, heap memory related issues, dynamic memory allocation related issues, etc.; the keywords included in the network category may be: network timeout, network connection related issues, connection denied, etc.; the keywords included in the crash category may be: segmentation error, program crash, etc.; the keywords included in the sensor category may be: lidar sensor, camera sensor, inertial measurement unit sensor, etc.

[0073] In the disclosed embodiment, multiple key logs are assigned to corresponding categories according to the keyword matching rules in the configuration file. This method not only improves the efficiency of log management, but also facilitates subsequent visualization and screening.

[0074] Optionally, the above step S13 (in response to a log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a log information viewing instruction input by a user, key log information with a fault category label as a target fault category label among the plurality of key log information is determined as log information to be viewed, and the log information to be viewed is displayed on a user query interface.

[0075] The target fault category tag is a fault category tag corresponding to the fault category carried by the log information viewing instruction.

[0076] Specifically, in response to the log information viewing instruction input by the user, the key log information whose fault category label is the target fault category label among multiple key log information is determined as the log information to be viewed, the target fault category label is the fault category label corresponding to the fault category carried by the log information viewing instruction, and the log information to be viewed is displayed on the user query interface.

[0077] For example, assuming that the fault category label corresponding to the fault category carried by the log information viewing instruction is "network timeout", the key log information with the fault category label "network timeout" among multiple key log information will be determined as the log information to be viewed, and all key log information with the fault category label "network timeout" will be displayed on the user query interface.

[0078] In the disclosed embodiment, the ROS2 system filters out qualified logs from key log information based on the fault category label specified by the user, and can quickly locate log information related to a specific fault category, thereby reducing information overload.

[0079] Optionally, the above step S14 (storing the plurality of key log information in a preset data format in the target database) can be implemented as follows: The key log information corresponding to each fault category label is stored in each data table of the target database.

[0080] Specifically, the key log information corresponding to each fault category is stored in different data tables according to the fields: log record timestamp, log level, log source node, log content and fault category label.

[0081] In the disclosed embodiments, log information is stored in different data tables based on fault type. Each data table specifically stores log information for a specific fault type. Categorizing and storing log information by fault type facilitates management and querying. By storing data in separate tables, the amount of data in a single table is reduced, improving query speed. Each data table contains only data for a specific fault type, facilitating targeted analysis and statistics.

[0082] In some embodiments, the above step S13 (in response to a log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a log information viewing instruction input by a user, key log information in the target database whose log level is higher than or equal to the log level carried by the log information viewing instruction is determined as log information to be viewed, and the log information to be viewed is displayed on a user query interface.

[0083] Specifically, in response to the log information viewing instruction input by the user, key log information in the target database with a log level higher than or equal to the log level carried by the log information viewing instruction is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0084] For example, if the log level carried by the log information viewing instruction is ERROR, key log information with a log level higher than or equal to ERROR in the target database is determined as log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0085] In some embodiments, the above step S13 (in response to a log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a log information viewing instruction input by a user, key log information in the target database containing the keyword carried in the log information viewing instruction is determined as log information to be viewed, and the log information to be viewed is displayed on a user query interface.

[0086] Specifically, in response to the log information viewing instruction input by the user, key log information in the target database whose log content contains the keyword carried by the log information viewing instruction is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0087] For example, if the keyword carried in the log information viewing instruction is "timeout", the key log information containing "timeout" in the log content of the target database is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0088] In some embodiments, the preset screening rules further include: screening based on a preset collection frequency, and / or screening based on a whitelist of log source nodes.

[0089] Specifically, the preset filtering rules can be stored in a configuration file, and more reasonable filtering conditions can be set in the configuration file according to actual application requirements, for example, the log collection frequency of the log information is greater than or equal to the preset collection frequency, and / or, the log source node of the log information belongs to the log source node whitelist.

[0090] Because high-frequency logs may indicate abnormal behavior, such as frequent errors or warnings, filtering out log information with a collection frequency greater than or equal to the preset collection frequency helps to promptly identify and address issues. Through a whitelist mechanism, only logs from trusted nodes are processed, improving the reliability and security of log information. This avoids processing logs from irrelevant or untrusted nodes, reduces interference, improves the accuracy of log analysis, and focuses on important nodes, ensuring that log information from critical nodes receives priority processing.

[0091] Optionally, the above step S13 (in response to a log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a log information viewing instruction input by a user, key log information in the target database whose log collection frequency is greater than or equal to the log collection frequency carried by the log information viewing instruction is determined as log information to be viewed, and the log information to be viewed is displayed on a user query interface.

[0092] Specifically, in response to the log information viewing instruction input by the user, key log information in the target database whose log collection frequency is greater than or equal to the log collection frequency carried by the log information viewing instruction is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0093] For example, assuming that the log collection frequency carried in the log information viewing instruction is a first frequency, key log information in the target database whose log collection frequency is greater than or equal to the first frequency is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface. The log collection frequency in each key log information can be obtained based on the log record timestamp.

[0094] Optionally, the above step S13 (in response to a log information viewing instruction input by the user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface) can be implemented as follows: In response to a log information viewing instruction input by a user, key log information in the target database whose log source node is consistent with the log source node carried by the log information viewing instruction is determined as the log information to be viewed, and the log information to be viewed is displayed on a user query interface.

[0095] Among them, the log source node carried by the log information viewing instruction belongs to the log source node whitelist.

[0096] Specifically, in response to the log information viewing instruction input by the user, the key log information in the target database whose log source node is consistent with the log source node carried by the log information viewing instruction is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0097] For example, assuming that the nodes in the log source node whitelist include but are not limited to: sensor data acquisition, data processing, motion control, and path planning, and the log source node carried by the log information viewing instruction is sensor data acquisition, the key log information related to the log source node and sensor data acquisition in the target database is determined as the log information to be viewed, and the log information to be viewed is displayed on the user query interface.

[0098] The disclosed embodiments provide a fault log information processing method. The ROS2 system can collect log information from multiple nodes in real time, ensuring that the operating status of all nodes is recorded promptly. Through real-time monitoring, abnormal behavior can be detected in advance and prevented from occurring. Key log information can be filtered from a large number of logs based on preset filtering conditions (e.g., log level, preset keywords, etc.). This allows for rapid identification of key logs related to faults or anomalies, reducing information overload and helping maintenance personnel quickly locate critical issues, thereby improving the efficiency of log management during the operation of the robot operating system. Each key log information is labeled according to its corresponding fault category, facilitating subsequent rapid location of related logs. Key log information is stored in a target database in a preset data format (including log record timestamp, log level, log source node, log content, and fault category label). This unified storage format makes log information query conditions more specific and improves query efficiency. Flexible and reasonable filtering rules can be preset based on actual needs to adapt to different monitoring scenarios, enabling targeted filtering of logs related to specific issues and improving the accuracy of fault diagnosis. The system responds to the user's log information viewing instruction, determines the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and displays the results on the user query interface, making it easy for maintenance personnel to quickly view and analyze the logs.

[0099] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0100] Figure 2 This is a structural diagram of a fault log information processing device 200 provided by the present disclosure, as shown in FIG. Figure 2 As shown, the device of this embodiment includes: Real-time collection module 210, used to collect multiple log information of multiple nodes in real time; The information screening module 220 is configured to screen the plurality of log messages based on preset screening rules to obtain a plurality of key log messages; the preset screening rules include screening based on a preset log level and / or screening based on preset keywords; The fault classification module 230 is used to add a corresponding fault category label to each key log information according to the fault category corresponding to each key log information; The information storage module 240 is used to store the plurality of key log information in a target database in a preset data format; the preset data format includes: log record timestamp, log level, log source node, log content and fault category label; The information viewing module 250 is used to respond to the log information viewing instruction input by the user, determine the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and display the log information to be viewed on the user query interface.

[0101] As an optional implementation of the embodiment of the present disclosure, the real-time acquisition module 210 is specifically configured to: Subscribe to the aggregation log topic; Through the aggregated log topic, multiple log information of multiple nodes can be obtained in real time.

[0102] As an optional implementation of the embodiment of the present disclosure, when the preset screening rule is screening based on a preset log level, the information screening module 220 is specifically configured to: Determine whether the log level of the target log information is higher than or equal to the preset log level; If the log level of the target log information is higher than or equal to the preset log level, determining that the target log information is critical log information; If the log level of the target log information is lower than the preset log level, the target log information is determined to be non-critical log information.

[0103] As an optional implementation of the embodiment of the present disclosure, when the preset screening rule is screening based on preset keywords, the information screening module 220 is specifically configured to: Determine whether the log content of the target log information contains preset keywords; If the log content of the target log information contains the preset keyword, determining that the target log information is key log information; If the log content of the target log information does not include the preset keyword, it is determined that the target log information is non-critical log information.

[0104] As an optional implementation of the embodiment of the present disclosure, the preset screening rule also includes: screening based on a preset collection frequency, and / or screening based on a whitelist of log source nodes.

[0105] As an optional implementation of the embodiment of the present disclosure, the instruction query method of the log information viewing instruction includes: a command line query instruction or a control query instruction; the information viewing module 250 is specifically used to: In response to a command line query instruction input by a user, determining log information to be viewed from the target database according to a viewing condition carried in the command line query instruction, and displaying the log information to be viewed on the user query interface in a first display manner; or; In response to a control query instruction input by a user, log information to be viewed is determined from the target database according to the viewing conditions carried by the command line query instruction, and the log information to be viewed is displayed on the user query interface in a second display mode.

[0106] As an optional implementation of the embodiment of the present disclosure, the viewing conditions carried by the log information viewing instruction include: at least one query information of the target fault category label, target log level, target log record timestamp, target keyword, and target log source node.

[0107] As an optional implementation of the embodiment of the present disclosure, the device further includes: The fault category determination module is used to classify each key log information according to a preset classification rule and obtain the corresponding fault category of each key log information; the preset classification rule includes multiple fault category tags and a keyword set corresponding to each fault category tag.

[0108] As an optional implementation of the embodiment of the present disclosure, the information storage module 240 is specifically configured to: The key log information corresponding to each fault category label is stored in each data table of the target database.

[0109] For the description of the features in the embodiment corresponding to the fault log information processing device 200, please refer to the relevant description of the embodiment corresponding to the fault log information processing method, and will not be repeated here.

[0110] The fault log information processing device provided by the disclosed embodiments enables the ROS2 system to collect log information from multiple nodes in real time, ensuring that the operating status of all nodes is recorded promptly. Through real-time monitoring, abnormal behavior can be detected in advance and prevented from occurring. Key log information can be filtered from a large number of logs based on preset filtering conditions (such as log level and preset keywords). This allows for rapid identification of key logs related to faults or anomalies, reducing information overload and helping maintenance personnel quickly locate critical issues, thereby improving the log management efficiency of the robot operating system during operation. Each key log information is tagged with a fault category based on its corresponding fault category, facilitating the subsequent rapid location of related logs. Key log information is stored in a target database in a preset data format (including log record timestamp, log level, log source node, log content, and fault category tag). This unified storage format makes log information query conditions more specific and improves query efficiency. Flexible and reasonable filtering rules can be pre-set based on actual needs to adapt to different monitoring scenarios, enabling targeted filtering of logs related to specific issues and improving the accuracy of fault diagnosis. The system responds to the user's log information viewing instruction, determines the log information to be viewed from the target database according to the viewing conditions carried by the log information viewing instruction, and displays the results on the user query interface, making it easy for maintenance personnel to quickly view and analyze the logs.

[0111] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned fault log information processing method embodiments.

[0112] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned fault log information processing method embodiments when running.

[0113] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0114] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned fault log information processing method embodiments are implemented.

[0115] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned fault log information processing method embodiments are implemented.

[0116] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0117] The above is a detailed introduction to a fault log information processing method provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for processing fault log information, characterized in that: The method comprises: Collect multiple log information from multiple nodes in real time; Filtering the plurality of log information based on preset filtering rules to obtain a plurality of key log information; the preset filtering rules include: filtering based on a preset log level, and / or filtering based on preset keywords; According to the fault category corresponding to each key log information, add the corresponding fault category label to each key log information; The plurality of key log information are stored in a target database in a preset data format; the preset data format includes: log record timestamp, log level, log source node, log content and fault category label; In response to a log information viewing instruction input by a user, the log information to be viewed is determined from the target database according to the viewing conditions carried in the log information viewing instruction, and the log information to be viewed is displayed on the user query interface.

2. The method for processing fault log information according to claim 1, wherein: The real-time collection of log information of multiple nodes includes: Subscribe to the aggregation log topic; Through the aggregated log topic, multiple log information of multiple nodes can be obtained in real time.

3. The method for processing fault log information according to claim 1, wherein: When the preset screening rule is based on the preset log level, The filtering based on the preset filtering rules from the multiple log information to obtain multiple key log information includes: Determine whether the log level of the target log information is higher than or equal to the preset log level; If the log level of the target log information is higher than or equal to the preset log level, determining that the target log information is critical log information; If the log level of the target log information is lower than the preset log level, the target log information is determined to be non-critical log information.

4. The method for processing fault log information according to claim 1, wherein: When the preset screening rule is based on preset keywords, The filtering based on the preset filtering rules from the multiple log information to obtain multiple key log information includes: Determine whether the log content of the target log information contains preset keywords; If the log content of the target log information contains the preset keyword, determining that the target log information is key log information; If the log content of the target log information does not include the preset keyword, it is determined that the target log information is non-critical log information.

5. The method for processing fault log information according to claim 1, wherein: The preset screening rules also include: screening based on a preset collection frequency, and / or screening based on a whitelist of log source nodes.

6. The method for processing fault log information according to claim 1, characterized in that: The command query mode of the log information viewing command includes: command line query command or control query command; The step of responding to a log information viewing instruction input by a user, determining the log information to be viewed from the target database according to the viewing conditions carried in the log information viewing instruction, and displaying the log information to be viewed on the user query interface includes: In response to a command line query instruction input by a user, determining log information to be viewed from the target database according to a viewing condition carried in the command line query instruction, and displaying the log information to be viewed on the user query interface in a first display manner; or; In response to a control query instruction input by a user, log information to be viewed is determined from the target database according to the viewing conditions carried by the command line query instruction, and the log information to be viewed is displayed on the user query interface in a second display mode.

7. The method for processing fault log information according to claim 1, wherein: The viewing conditions carried by the log information viewing instruction include: at least one query information of a target fault category label, a target log level, a target log record timestamp, a target keyword, and a target log source node.

8. The method for processing fault log information according to claim 1, wherein: Before adding corresponding fault category labels to each key log information according to the fault category corresponding to each key log information, the method further includes: Each key log information is classified according to a preset classification rule to obtain a corresponding fault category of each key log information; the preset classification rule includes a plurality of fault category tags and a keyword set corresponding to each fault category tag.

9. The method for processing fault log information according to claim 8, characterized in that: The storing the plurality of key log information in a preset data format in a target database includes: The key log information corresponding to each fault category label is stored in each data table of the target database.

10. An electronic device, characterized in that: memory for storing computer programs; A processor, configured to implement the steps of the fault log information processing method according to any one of claims 1 to 9 when executing the computer program.

Images