A map production anomaly positioning and processing method, system, medium and device

Abstract

This application discloses a method, system, medium, and device for locating and handling map production anomalies, belonging to the field of map production technology. The method includes: collecting log information during the map production process through a log collection module; analyzing the log information through a log analysis module and determining a corresponding first anomaly solution in a rule base based on the analysis results; if no first anomaly solution exists in the rule base, a corresponding second anomaly solution is added based on the anomaly, and a relationship is established between the second anomaly solution and the anomaly, updating the rule base; and handling the anomaly during the map production process according to the first or second anomaly solution. By analyzing the log information during the map production process, accurate location of anomalies in map production is achieved, and corresponding anomaly solutions are found in the rule base based on the analysis results, enabling automatic anomaly handling.

Description

Technical Field

[0001] This application relates to the field of map production technology, and in particular to a method, system, medium and equipment for locating and processing map production anomalies. Background Technology

[0002] Complete or high-precision maps are required for vehicle operation and autonomous driving to guide the vehicle's journey. During map production and updates, processing anomalies often occur. Failure to quickly locate and resolve these anomalies significantly impacts map production and update efficiency. Furthermore, the lack of standardized handling rules and the reliance on manual problem-solving after anomaly identification also greatly hinders map production efficiency. Summary of the Invention

[0003] To address the problem of low map production efficiency caused by the inability to quickly locate and automatically handle anomalies during map production, this application proposes a method, system, medium, and device for locating and handling map production anomalies.

[0004] Firstly, this application proposes a method for locating and handling map production anomalies, comprising: collecting log information during the map production process through a log collection module; analyzing the log information through a log analysis module, and determining a corresponding first anomaly solution in a rule base based on the analysis results; if no first anomaly solution exists in the rule base, adding a corresponding second anomaly solution based on the anomaly, establishing a relationship between the second anomaly solution and the anomaly, and updating the rule base; and handling the anomaly during the map production process based on the first or second anomaly solution.

[0005] Optionally, the log information can be analyzed through the log analysis module, including: identifying abnormal keywords in the log information and filtering out abnormal logs; segmenting and extracting the content in the abnormal logs so that only strings exist in the abnormal logs, and separating adjacent strings with specific symbols; matching the segmented abnormal logs with the abnormal logs already stored in the database to obtain the matching results, which are then used as the analysis results.

[0006] Optionally, the segmented abnormal logs are matched with existing logs in the database to obtain matching results, including: comparing the strings in the abnormal logs with the strings in the existing abnormal logs to obtain a first matching degree; if the first matching degree is less than a first preset threshold, the string edit distance between the strings in the abnormal logs and the strings in the existing abnormal logs is calculated and used as a second matching degree; if the second matching degree is less than a second preset threshold, the probability that the order of occurrence of the erroneous strings in the abnormal logs conforms to the order rule is calculated and used as a third matching degree, where the erroneous string is the string that causes the existing abnormal log to be an abnormal log, and the order rule is the order in which the erroneous string appears in the existing abnormal logs. If the first matching degree is not less than the first preset threshold, the second matching degree is not less than the second preset threshold, or the third matching degree is not less than the third preset threshold, then the abnormal log matches the existing abnormal logs, and the solution corresponding to the existing abnormal logs in the rule base is used as the first abnormal solution.

[0007] Optionally, the log analysis module can be used to analyze log information, including: aggregating abnormal logs based on server address, and aggregating abnormal logs with the same server address together to obtain the first type of abnormal logs; aggregating the first type of abnormal logs based on service name, and aggregating abnormal logs with the same service name together to obtain the second type of abnormal logs; and aggregating the second type of abnormal logs based on abnormal content, and aggregating abnormal logs with the same abnormal content together to obtain the third type of abnormal logs.

[0008] Optionally, it also includes: collecting indicator information during the map production process through the indicator collection module; the indicator analysis module analyzing the task indicator information based on the log analysis information provided by the log analysis module, transmitting the analysis results to the log analysis module, and retrieving corresponding solutions from the rule base to handle indicator anomalies.

[0009] Optionally, the rule base establishment process includes: establishing initial exception handling rules based on existing historical exception log information; adding corresponding exception handling rules based on new exception logs, and recording the usage frequency and effectiveness of exception handling rules; establishing the association between logs and metrics in the rule base, the association between different services, and coding them to obtain the rule base.

[0010] Secondly, this application proposes a map production anomaly location and processing system, comprising: a log collection module, which collects log information during the map production process; a log analysis module, which analyzes the log information and determines a corresponding first anomaly solution in the rule base based on the analysis results; and a fault analysis and self-healing module, which, if there is no first anomaly solution in the rule base, adds a corresponding second anomaly solution based on the anomaly, establishes a relationship between the second anomaly solution and the anomaly, updates the rule base, and processes the anomaly during the map production process based on the first or second anomaly solution.

[0011] Thirdly, this application provides a computer-readable storage medium storing computer-executable instructions, which are executed by a processor to implement the map production anomaly location and processing method in Scheme 1.

[0012] Fourthly, this application provides a computer device, including a processor and a memory, wherein the memory stores computer execution instructions, and the processor executes the computer execution instructions to implement the map production anomaly location and processing method in Scheme 1.

[0013] Fifthly, this application provides a computer program product, including a computer program, which is executed by a processor to implement the map production anomaly location and processing method in Scheme 1.

[0014] The map production anomaly location and handling method, system, medium and equipment of this application analyze log information in the map production process to accurately locate anomalies in map production, and find corresponding anomaly solutions in the rule base based on the analysis results to achieve automatic anomaly handling and improve map production efficiency. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description exemplarily illustrate some embodiments of this application.

[0016] Figure 1 A schematic diagram illustrating one embodiment of the map production anomaly location and processing method of this application is shown;

[0017] Figure 2 An example of the exception log word segmentation and extraction process of this application is shown;

[0018] Figure 3 A schematic diagram of a structural example of the rule base of this application is shown;

[0019] Figure 4A schematic diagram illustrating an example of the exception log processing procedure of this application is shown;

[0020] Figure 5 A schematic diagram of one embodiment of the map production anomaly location and processing system of this application is shown.

[0021] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0022] The preferred embodiments of this application will now be described in detail with reference to the accompanying drawings, so that the advantages and features of this application can be more easily understood by those skilled in the art, thereby providing a clearer and more definite definition of the scope of protection of this application.

[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0024] Complete or high-precision maps are required for vehicle operation and autonomous driving to guide the vehicle's journey. During map production and updates, processing anomalies often occur. Failure to quickly locate and resolve these anomalies significantly impacts map production and update efficiency. Furthermore, the lack of standardized handling rules and the reliance on manual problem-solving after anomaly identification also greatly hinders map production efficiency.

[0025] To address the aforementioned issues, this application proposes a method, system, medium, and device for locating and handling map production anomalies. The method includes: collecting log information during the map production process through a log collection module; analyzing the log information through a log analysis module and determining a corresponding first anomaly solution in a rule base based on the analysis results; if no first anomaly solution exists in the rule base, adding a corresponding second anomaly solution based on the anomaly, establishing a relationship between the second anomaly solution and the anomaly, and updating the rule base; and handling the anomaly during the map production process based on either the first or second anomaly solution.

[0026] This application's method for locating and handling map production anomalies involves collecting and analyzing log information during the map production process to identify anomalies. The discovered anomaly logs are then matched against existing anomaly logs in a rule base. If a match is found, the solution corresponding to the existing anomaly log is directly applied to resolve the newly discovered anomaly. If no match is found, the newly discovered anomaly is handled manually or automatically to determine a new solution. The newly discovered anomaly log and its corresponding solution are then stored in the rule base, which is subsequently updated. When a similar anomaly occurs again, the solution can be directly invoked from the rule base to resolve the anomaly. Furthermore, when locating map production anomalies, a comprehensive analysis combining log information and indicator information enables rapid anomaly localization and rapid anomaly processing via the rule base, ensuring map production efficiency.

[0027] The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail below with specific embodiments. The specific embodiments described below can be combined with each other to form new embodiments. The same or similar ideas or processes described in one embodiment may not be repeated in other embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0028] Figure 1 A schematic diagram of one embodiment of the map production anomaly location and processing method of this application is shown.

[0029] exist Figure 1 In the embodiment shown, the map production anomaly location and processing method of this application includes process S101, which collects log information during the map production process through a log collection module.

[0030] In this implementation, in order to locate anomalies that occur during the map production process as early as possible, a log collection module is used to collect log information generated during the map production process, and then perform subsequent log analysis to quickly locate the anomalies.

[0031] Specifically, the log collection module can automatically collect logs using Filebeat, ELK, Kafka, and Python modules. Filebeat is specifically designed to collect and write system logs to disk. In map production scenarios, multiple services and middleware are involved, spanning multiple servers (e.g., 42 services and middleware, totaling 100 servers). To simplify deployment, the paramiko package in Python is used for automated deployment and runtime verification of the Filebeat collection tool, ensuring the integrity and correctness of the collection client. Logstash is an open-source data collection engine with real-time pipeline capabilities. The Logstash module receives log information from Filebeat, formats it, and writes it to the downstream Kafka processing tool. Kafka is a commonly used high-concurrency message processing middleware used to cache log messages. To ensure message order, this method establishes a log topic for each service, with each topic having only one log partition. By selecting Kafka for processing, real-time message delivery is guaranteed. By consuming data through Kafka, the program only needs to retrieve exception logs and does not process other logs, which greatly reduces latency and achieves almost real-time analysis and processing.

[0032] exist Figure 1 In the embodiment shown, the map production anomaly location and handling method of this application includes process S102, which analyzes log information through a log analysis module and determines the corresponding first anomaly solution in the rule base based on the analysis results.

[0033] In this implementation, the collected log information is analyzed by a log analysis module to identify abnormal logs. Then, the abnormal logs are compared with existing abnormal logs. If a newly appearing abnormal log is similar to an existing abnormal log, the first abnormal solution corresponding to the existing abnormal log is extracted from the rule base to handle the abnormality corresponding to the newly appearing abnormal log.

[0034] Optionally, the log information can be analyzed through the log analysis module, including: identifying abnormal keywords in the log information and filtering out abnormal logs; segmenting and extracting the content in the abnormal logs so that only strings exist in the abnormal logs, and separating adjacent strings with specific symbols; matching the segmented abnormal logs with the abnormal logs already stored in the database to obtain the matching results, which are then used as the analysis results.

[0035] In this optional embodiment, the map production system generates hundreds of thousands of logs during the map production process. Therefore, abnormal keywords in the collected log information are identified first. If an abnormal keyword is found in a log, the log is identified as an abnormal log and requires subsequent abnormal processing.

[0036] Specifically, exception logs can be categorized into business exception logs and middleware exception logs. Middleware exception logs are exception information returned by Kafka tools during service interaction, printed to the service's `error.log` file. Filebeat collects logs from `error.log` and writes them to Kafka. The log analysis module analyzes the log information in Kafka and identifies the exception keyword "exception," thus confirming the log entry as an exception. It's worth noting that exception keywords can be appropriately set based on different map production processes or tasks to effectively and quickly filter out exception logs for subsequent exception resolution.

[0037] In this optional embodiment, after filtering out the abnormal logs, the content in the abnormal logs needs to be segmented into words so that the abnormal logs are individual strings. By extracting and ignoring some numbers, special symbols and punctuation marks in the abnormal logs, only English strings are kept, and multiple English strings are separated by specific symbols.

[0038] Specifically, to ensure uniformity in the format of English strings in exception logs, all English strings can be converted to the same writing format, such as converting them to lowercase, and multiple English strings can be separated by specific symbols such as commas.

[0039] Specifically, Figure 2 An example of the exception log word segmentation and extraction process of this application is shown.

[0040] like Figure 2 (a) shows the exception log before processing. Figure 2 (b) shows the exception logs after word segmentation and extraction. Figure 2 As shown in the example, the exception log after word segmentation and extraction only retains English strings, all of which are lowercase, and each English string is separated by a comma.

[0041] In this optional embodiment, after segmenting and extracting the abnormal logs, the segmented abnormal logs are matched with the abnormal logs already stored in the database to obtain the corresponding matching results, and the matching results are used as the analysis results.

[0042] Optionally, the segmented exception logs are matched with existing logs in the database to obtain matching results, including: comparing the strings in the exception logs with the strings in the existing exception logs to obtain a first matching degree; if the first matching degree is less than a first preset threshold, the string edit distance between the strings in the exception logs and the strings in the existing exception logs is calculated and used as the second matching degree; if the second matching degree is less than a second preset threshold, the probability that the order of occurrence of the error strings in the exception logs conforms to the order rule is calculated and used as the third matching degree, where the error string is the string that causes the existing exception log to be an exception log, and the order rule is the order in which the error string appears in the existing exception logs. If the first matching degree is not less than the first preset threshold, the second matching degree is not less than the second preset threshold, or the third matching degree is not less than the third preset threshold, then the exception log matches the existing exception logs, and the solution corresponding to the existing exception logs in the rule base is used as the first exception solution.

[0043] In this optional embodiment, when matching the exception log with the existing exception log, this application performs multiple matches in descending order of matching degree. Specifically, it first performs a direct comparison between the strings in the exception log and the strings in the existing exception log, that is, a direct comparison between strings, to obtain the first matching degree.

[0044] Specifically, the direct comparison between the strings in the exception log and the strings in existing exception logs is to determine whether there is an existing exception log in the database that is exactly the same as the current exception log. When there is an existing exception log that is exactly the same as the current exception log, the first matching degree is 100%, so the first preset threshold can be set to 100%.

[0045] In this optional embodiment, if there is no existing exception log in the database that is consistent with the current exception log security, a second matching is performed between the current exception log and the existing exception log, that is, the string edit distance between the strings in the current exception log and the existing exception log is calculated, where the string edit distance represents a string metric of the degree of difference between the two strings.

[0046] Specifically, the second preset threshold can be set to 90%. When the string edit distance between the exception log and the existing exception log is greater than 90%, the exception log is considered to match the existing exception log.

[0047] In this optional embodiment, if no log in the existing exception logs satisfies the condition that the string edit distance is not less than the second preset threshold, a third matching process is performed between the current exception log and the existing exception logs. During this third matching process, the order of the error strings in the existing exception logs is first determined. Then, the probability that the order of the same error strings conforms to the order rule is calculated in the current exception log. If the probability is not less than the preset third threshold, the current exception log is considered to match the existing exception log. Here, the error string is the string that caused the existing exception log to be an exception log, and the order rule is the order in which the error strings appear in the existing exception logs.

[0048] Specifically, the third preset threshold can be set to 80%. It should be noted that the settings of the first, second, and third preset thresholds can be reasonably selected and appropriately adjusted according to the actual judgment requirements. This application does not limit the specific values.

[0049] By repeatedly matching the exception logs with the existing daily logs in the database, an accurate match between the exception logs and the existing exception logs can be achieved, thereby enabling effective resolution of exceptions.

[0050] In this optional embodiment, after calculating the matching degree between the exception log and the existing logs, if the first matching degree is not less than a first preset threshold, or the second matching degree is not less than a second preset threshold, or the third matching degree is not less than a third preset threshold, then the exception log matches the existing exception logs. The solution corresponding to the existing exception log is then used as the first exception solution to automatically handle the emerging exception.

[0051] exist Figure 1 In the embodiment shown, the map production anomaly location and processing method of this application includes process S103: if there is no first anomaly solution corresponding to the anomaly in the rule base, then a corresponding second anomaly solution is added according to the anomaly, and the relationship between the second anomaly solution and the anomaly is established, and the rule base is updated.

[0052] In this implementation, because new anomalies will inevitably occur during map production, there may be situations where the filtered anomaly logs do not match the existing anomaly logs in the database. In such cases, special handling is required for the anomaly, and a corresponding second anomaly solution needs to be added. For example, the anomaly can be manually handled to obtain the corresponding second anomaly solution. Furthermore, the second anomaly solution and the corresponding anomaly log are stored and the rule base is updated. When a similar anomaly occurs again, by matching it with the anomaly log, the solution can be directly retrieved from the rule base to resolve the anomaly.

[0053] exist Figure 1 In the embodiments shown, the map production anomaly location and handling method of this application includes process S104, which handles the anomalies in the map production process according to a first anomaly solution or a second anomaly solution.

[0054] In this implementation, anomalies are located using log information, and then corresponding anomaly solutions and related anomaly handling are extracted from the rule base, enabling rapid location and handling of anomalies during map production.

[0055] Optionally, the log analysis module can be used to analyze log information, including: aggregating abnormal logs based on server address, and aggregating abnormal logs with the same server address together to obtain the first type of abnormal logs; aggregating the first type of abnormal logs based on service name, and aggregating abnormal logs with the same service name together to obtain the second type of abnormal logs; and aggregating the second type of abnormal logs based on abnormal content, and aggregating abnormal logs with the same abnormal content together to obtain the third type of abnormal logs.

[0056] In this optional embodiment, to facilitate unified management of exception logs, exception logs with the same server address are aggregated based on the server address. This aims to extract similar exceptions caused by host machine configuration and operational failures, resulting in the first type of exception logs. A second aggregation is then performed based on the service name corresponding to the exception logs. This aggregation is also based directly on tags, aiming to group exceptions from similar services together for easier subsequent analysis, resulting in the second type of exception logs. Finally, a final aggregation is performed based on the exception content, resulting in the third type of exception logs. The aggregated results can be written to a rule table for storage, where each record has a unique ID number.

[0057] Optionally, the map production anomaly location and handling method of this application further includes: collecting indicator information during the map production process through the indicator collection module; the indicator analysis module analyzing the task indicator information based on the log analysis information provided by the log analysis module, transmitting the analysis results to the log analysis module, and retrieving the corresponding solution from the rule base to handle the indicator anomaly.

[0058] In this optional embodiment, in the process of anomaly location and handling, in addition to collecting and processing log information, indicator information is also collected and analyzed. By combining log information and indicator information, rapid anomaly location and handling are achieved. Obtaining and analyzing anomaly logs aims to discover anomalies in business operations. Then, based on the anomaly information, relevant monitoring modules are retrieved to capture indicators, achieving a combination of anomaly information and indicators. For example, if the anomaly log information indicates a memory anomaly, then based on the analysis results of the anomaly log, the memory monitoring module is retrieved to obtain memory usage information for the corresponding time period, thereby locating the specific memory anomaly. By combining anomaly information and indicator information, rapid anomaly location is achieved. Other anomaly analyses during business execution follow the same principle, including hardware usage such as CPU and disk usage, and service calls, all using the above method for comprehensive analysis. Because log acquisition and analysis, and the acquisition of other indicators, are generally designed as independent modules, uniformly triggered by the log analysis module, the above principle of combining anomaly logs with indicator analysis can be applied to other anomaly analysis instances.

[0059] Specifically, during the metric information collection process, metric collection modules, such as Prometheus, a monitoring software specifically designed for cloud computing, are used to aggregate, process, define collection rules, and define alarm rules for metrics. It has its own dedicated time-series database (TSDB) for storing monitoring data, and can retrieve and store monitoring metrics via pull / push methods. Simultaneously, Prometheus provides a web interface for viewing data, targets, and performing ProMQL queries. It collects various types of monitoring metrics through official and open-source exporters. The metrics primarily used in this application are microservice-related performance metrics such as microservice CPU, memory, and disk usage; Nginx request volume; and Kafka tool lag.

[0060] Specifically, the following statement is a common service runtime error detected by the system: OutOfMemoryError: javaheap space. The error can be quickly identified as a Java Virtual Machine (JVM) heap memory overflow from the collected log information. The causes of this type of error are usually of two types: first, the relevant startup parameters were not configured during the JVM startup process; second, insufficient memory was allocated to the JVM.

[0061] After the log analysis module captures this type of error, it triggers the metrics analysis module. Based on the time point, IP address, and service name provided by the log analysis module, the metrics analysis module proactively retrieves the service's current configuration and memory usage. If it's a Linux server, it queries Zabbix for memory usage information for the relevant time period; if it's a microservice, it queries Prometheus for the relevant time period. This achieves a combined analysis of log and metrics information. The retrieved memory information is added to the log analysis module. After obtaining information from the metrics analysis module, the log analysis module will either issue an alert or retrieve existing solutions from the rule base to resolve the anomaly.

[0062] Optionally, the rule base establishment process includes: establishing initial exception handling rules based on existing historical exception log information; adding corresponding exception handling rules based on new exception logs, and recording the usage frequency and effectiveness of exception handling rules; establishing the association between logs and metrics in the rule base, the association between different services, and coding them to obtain the rule base.

[0063] Specifically, when establishing the rule base, historical experience, including past anomaly information, is first reviewed to formulate initial rule items. Each rule item is identified by a unique ID and also includes fields such as frequency and hit rate to continuously verify the usability and practicality of the rule items during operation. This facilitates further optimization of the existing rules. During system operation, rule items have the ability to be automatically generated. For newly added rule items, after initial analysis of the corresponding code, manual integration is performed. The purpose of integration is mainly to correlate logs with metrics and relationships between different processing services, to formulate complex rule templates, and to codify them. The information in the rule base is recorded and stored to provide intelligent anomaly decision-making models for different map production businesses. During system operation, the rule base continuously learns and improves itself, providing accurate solutions for anomalies.

[0064] Specifically, Figure 3 A schematic diagram of a structural example of the rule base of this application is shown.

[0065] like Figure 3 As shown, the rule base is divided into a log rule base and a metric rule base. The log rule base is further divided into a business log rule base and a middleware rule base, storing rules by service name, logs before and after splitting, whether an alarm is triggered, and log category. The metric rule base stores Linux anomaly metrics, Kubernetes anomaly metrics, and middleware anomaly metrics in the system. When an anomaly log is generated, the query module of the relevant middleware is triggered, and the module checks the existing monitoring system to see if there are any anomalies in the monitoring data for the relevant time period. Examples of different types of system logs are given below:

[0066] First, the Linux system encountered an error. The retrieved keyword "too many open files" indicates that the Linux system has reached its maximum number of open file handles and cannot open any more files. This error log corresponds to the Linux system query module, which pushes the error message after retrieving the current ulimit information. The database provides suggestions for handling such common errors, stating "Confirm whether ulimit needs to be increased or confirm whether the service is opening too many files."

[0067] Secondly, there's the issue of Kubernetes (k8s) exceptions. The system log entry for "pod pending" indicates a pod in the k8s system that cannot be scheduled. This exception log corresponds to the k8s exception location module. If it's a kubelet exception, the automatic handling code will restart the kubelet container. If it's a node exception, it will display messages like "Insufficient disk space" or "Insufficient compute resources" depending on the error type.

[0068] Finally, a middleware exception was found in the PostgreSQL database log: "can not connect ***6379". 6379 is the default port for PostgreSQL database services; this error indicates the service cannot connect to the database. This exception log corresponds to the middleware query module. If the PostgreSQL database is found to have shut down abnormally, an attempt will be made to restore it via code. If restoration fails, the message "Database failed to start, please check the startup log!" will be displayed.

[0069] Specifically, Figure 4 A schematic diagram of an example of the exception log processing procedure of this application is shown.

[0070] like Figure 4As shown, the abnormal logs obtained from the log information filtering process undergo word segmentation and extraction to facilitate subsequent matching with existing abnormal logs stored in the database. Through aggregation, the abnormal logs are categorized for effective management. During the matching process, multiple matches are performed between the abnormal log and existing abnormal logs; the ID matching process essentially determines the similarity between newly appearing abnormal logs and existing abnormal logs. The calculated matching result is compared with a corresponding preset threshold. If the result is not less than the preset threshold, the match is successful, and the corresponding solution for the newly appearing abnormal log is retrieved from the rule base to handle the problem, with the retrieval frequency increasing accordingly. If the matching result is less than the preset threshold, the match cannot be completed, meaning the current abnormality is a new one. An alarm is triggered, and a solution needs to be generated manually or automatically and coded. This requires establishing relationship rules between the abnormality and the service, and between the abnormality and the newly determined solution, in the rule base. Manual intervention here can also be used when complex problems arise, such as when three or more services experience anomalies within five minutes. Experience suggests that multiple service anomalies often indicate widespread system malfunctions, requiring immediate manual intervention. This intervention prevents production delays, and the solution is then added to the rule base. After processing the anomaly logs, both the complete log content and the segmented log content are written to the database for storage. The segmented log content will be used as the stored anomaly log for subsequent log matching. Finally, the determined solution is used to handle the anomalies. For example... Figure 4 As shown, the process then determines whether to output a self-healing rule. If the newly appearing exception log matches a stored exception log and the location of the exception is clearly identified, the exception corresponding to the newly appearing daily log can be resolved using the stored solutions. In this case, a self-healing rule can be output for automatic exception handling and automatic repair. If the specific cause of the newly appearing exception cannot be determined after exception cause analysis, automatic repair cannot be performed. In this case, it is necessary to add other related indicator rules. By pulling other monitoring information, a comprehensive judgment of the exception cause is made. By using the pulled other information as relevant related indicator rules, the cause of the exception is further determined, accelerating the location of the exception cause and enabling rapid resolution.

[0071] This application's method for locating and handling map production anomalies involves collecting and analyzing log information during the map production process to identify anomalies. The discovered anomaly logs are then matched against existing anomaly logs in a rule base. If a match is found, the solution corresponding to the existing anomaly log is directly applied to resolve the newly discovered anomaly. If no match is found, the anomaly is handled according to standard procedures, and the anomaly log and its corresponding solution are stored in the rule base, which is then updated. When a similar anomaly occurs again, the solution can be directly invoked from the rule base to resolve the anomaly. Furthermore, when locating map production anomalies, a comprehensive analysis combining log information and indicator information enables rapid anomaly localization and rapid anomaly processing via the rule base, ensuring map production efficiency.

[0072] Figure 5 A schematic diagram of one embodiment of the map production anomaly location and processing system of this application is shown.

[0073] like Figure 5 As shown, the map production anomaly location and processing system of this application includes: a log collection module 501, which collects log information during the map production process; a log analysis module 502, which analyzes the log information and determines the corresponding first anomaly solution in the rule base based on the analysis results; and a fault analysis and self-healing module 503, which, if there is no first anomaly solution corresponding to the anomaly in the rule base, adds a corresponding second anomaly solution based on the anomaly, establishes the relationship between the second anomaly solution and the anomaly, updates the rule base, and processes the anomaly during the map production process based on the first anomaly solution or the second anomaly solution.

[0074] Optionally, in the log analysis module, abnormal keywords in the log information are identified and filtered to obtain abnormal logs; the content in the abnormal logs is segmented and extracted to ensure that only strings exist in the abnormal logs, and adjacent strings are separated by specific symbols; the segmented abnormal logs are matched with the abnormal logs already stored in the database to obtain the matching results, which are used as the analysis results.

[0075] Optionally, in the log analysis module, the first matching degree between a single string in the exception log and a string in the existing exception log is calculated sequentially. If the first matching degree is less than a first preset threshold, the string edit distance between the string in the exception log and the string in the existing exception log is calculated and used as the second matching degree. If the second matching degree is less than a second preset threshold, the probability that the order of occurrence of the error string in the exception log conforms to the order rule is calculated and used as the third matching degree. The error string is the string that causes the existing exception log to be an exception log, and the order rule is the order in which the error string appears in the existing exception log. If the first matching degree is not less than the first preset threshold, the second matching degree is not less than the second preset threshold, or the third matching degree is not less than the third preset threshold, then the exception log matches the existing exception log, and the solution corresponding to the existing exception log in the rule base is used as the first exception handling solution.

[0076] Optionally, in the log analysis module, exception logs are aggregated based on server address, and exception logs with the same server address are aggregated together to obtain the first type of exception logs; the first type of exception logs are aggregated based on service name, and exception logs with the same service name are aggregated together to obtain the second type of exception logs; the second type of exception logs are aggregated based on exception content, and exception logs with the same exception content are aggregated together to obtain the third type of exception logs.

[0077] Optionally, it also includes collecting indicator information during the map production process through the indicator collection module; the indicator analysis module analyzes the task indicator information based on the log analysis information provided by the log analysis module, transmits the analysis results to the log analysis module, and retrieves the corresponding processing solutions from the rule base to handle indicator anomalies.

[0078] Optionally, the rule base establishment process includes: establishing initial exception handling rules based on existing historical exception log information; adding corresponding exception handling rules based on new exception logs, and recording the usage frequency and effectiveness of exception handling rules; establishing the association between logs and metrics in the rule base, the association between different services, and coding them to obtain the rule base.

[0079] This application's map production anomaly location and handling system collects and analyzes log information during the map production process, filtering out anomaly logs corresponding to anomalies. The system matches discovered anomaly logs with existing anomaly logs in a rule base. If a match is found, the existing solution is used to resolve the newly discovered anomaly. If no match is found, the anomaly is handled according to standard procedures, and the anomaly log and its corresponding solution are stored in the rule base, which is then updated. When a similar anomaly occurs again, the solution can be directly invoked from the rule base to resolve the anomaly. Furthermore, when locating map production anomalies, a comprehensive analysis combining log information and indicator information enables rapid anomaly location and rapid anomaly processing via the rule base, ensuring map production efficiency.

[0080] In one embodiment of this application, a computer-readable storage medium stores computer instructions, wherein the computer instructions are operated to perform the map production anomaly location and processing method described in any embodiment. The storage medium may be located directly in hardware, in a software module executed by a processor, or in a combination of both.

[0081] Software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in this art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium.

[0082] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general-purpose processor can be a microprocessor, but alternatively, it can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration. Alternatively, the storage medium can be integrated with the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in the user terminal. Alternatively, the processor and storage medium can reside as discrete components in the user terminal.

[0083] In one specific embodiment of this application, a computer device includes a processor and a memory, the memory storing computer instructions, wherein the processor operates the computer instructions to execute the map production anomaly location and processing method described in any embodiment.

[0084] In one specific embodiment of this application, a computer program product includes a computer program, wherein the computer program is executed by a processor to implement the map production anomaly location and processing method described in any embodiment.

[0085] In the embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A method for locating and handling map production anomalies, characterized in that, include: The log collection module collects log information during the map production process. The log collection module automatically collects logs through the Filebeat processing submodule, the ELK processing submodule, the Kafka processing submodule, and the Python submodule. The log information is analyzed by the log analysis module, and the corresponding first anomaly solution is determined in the rule base based on the analysis results. If the rule base does not contain a first exception solution corresponding to the exception, then a corresponding second exception solution is added based on the exception, and a relationship is established between the second exception solution and the exception, and the rule base is updated. The anomalies in the map production process are handled according to either the first anomaly solution or the second anomaly solution. Specifically, a first matching degree is obtained by comparing the string in the exception log with the string in the existing exception log. If the first matching degree is less than a first preset threshold, the string edit distance between the string in the exception log and the string in the existing exception log is calculated and used as the second matching degree. If the second matching degree is less than a second preset threshold, the probability that the order of occurrence of the erroneous string in the exception log conforms to the order rule is calculated and used as the third matching degree. The erroneous string is the string that causes the existing exception log to be an exception log, and the order rule is the order in which the erroneous string appears in the existing exception log. If the first matching degree is not less than the first preset threshold, the second matching degree is not less than the second preset threshold, or the third matching degree is not less than the third preset threshold, then the exception log matches the existing exception log, and the solution corresponding to the existing exception log in the rule base is used as the first exception solution.

2. The map production anomaly location and processing method according to claim 1, characterized in that, The analysis of the log information by the log analysis module includes: The abnormal keywords in the log information are identified by the log analysis module, and abnormal logs are obtained by filtering them. The content in the exception log is segmented and extracted to ensure that the exception log contains only strings, and adjacent strings are separated by specific symbols; The segmented abnormal logs are matched with the existing abnormal logs in the database to obtain the matching results, which are then used as the analysis results.

3. The map production anomaly location and processing method according to claim 2, characterized in that, The step of analyzing the log information through the log analysis module also includes: The exception logs are aggregated according to the server address. The exception logs with the same server address are aggregated together to obtain the first type of exception logs. The first type of exception logs are aggregated according to the service name, and the exception logs with the same service name are aggregated together to obtain the second type of exception logs. The second type of abnormal logs are aggregated based on the abnormal content. The abnormal logs with the same abnormal content are then aggregated together to obtain the third type of abnormal logs.

4. The map production anomaly location and processing method according to claim 1, characterized in that, Also includes: The indicator collection module collects indicator information during the map production process; The indicator analysis module analyzes the indicator information based on the log analysis information provided by the log analysis module, transmits the analysis results to the log analysis module, and retrieves the corresponding solutions from the rule base to handle indicator anomalies.

5. The map production anomaly location and processing method according to claim 1, characterized in that, The process of establishing the rule base includes: Establish initial exception handling rules based on existing historical exception log information; Based on the new exception log, add corresponding exception handling rules, and record the frequency and effectiveness of the use of the exception handling rules; Establish the association between logs and metrics in the rule base, as well as the association between different services, and then codify them to obtain the rule base.

6. A map production anomaly location and processing system, characterized in that, include: The log collection module collects log information during the map production process. The log collection module automatically collects logs through the Filebeat processing submodule, the ELK processing submodule, the Kafka processing submodule, and the Python submodule. The log analysis module analyzes the log information and determines the corresponding first anomaly solution in the rule base based on the analysis results. The fault analysis and self-healing module, if the first fault solution corresponding to the fault does not exist in the rule base, adds a corresponding second fault solution according to the fault, establishes a relationship between the second fault solution and the fault, updates the rule base, and processes the fault in the map production process according to the first fault solution or the second fault solution. Specifically, a first matching degree is obtained by comparing the string in the exception log with the string in the existing exception log. If the first matching degree is less than a first preset threshold, the string edit distance between the string in the exception log and the string in the existing exception log is calculated and used as the second matching degree. If the second matching degree is less than a second preset threshold, the probability that the order of occurrence of the erroneous string in the exception log conforms to the order rule is calculated and used as the third matching degree. The erroneous string is the string that causes the existing exception log to be an exception log, and the order rule is the order in which the erroneous string appears in the existing exception log. If the first matching degree is not less than the first preset threshold, the second matching degree is not less than the second preset threshold, or the third matching degree is not less than the third preset threshold, then the exception log matches the existing exception log, and the solution corresponding to the existing exception log in the rule base is used as the first exception solution.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the map production anomaly location and processing method as described in any one of claims 1-5.

8. A computer device, characterized in that, It includes a processor and a memory, the memory storing computer execution instructions, wherein the processor executes the computer execution instructions to implement the map production anomaly location and processing method as described in any one of claims 1-5.

9. A computer program product, characterized in that, It includes a computer program, which is executed by a processor to implement the map production anomaly location and processing method as described in any one of claims 1-5.

Images