An abnormal log analysis method and device

Abstract

This application provides an anomaly log analysis method and apparatus, relating to the field of software analysis technology. The method includes: acquiring an Android device log information set, the log information set including multiple raw log messages; performing format standardization processing on each raw log message to obtain a first log set including multiple log messages with uniform format; filtering and obtaining a second log set based on the first log set, the second log set not including redundant log messages in the first log set, and including missing fields of log messages in the first log set; classifying the multiple log messages in the second log set to obtain a third log set; organizing each log message in the third log set according to time sequence and category label to generate multiple log message sequences; sending the multiple log message sequences to a local server; and obtaining an anomaly log report and corresponding repair suggestions based on the multiple log message sequences.

Description

Technical Field

[0001] This application relates to the field of software analysis technology, and more specifically, to an anomaly log analysis method and apparatus. Background Technology

[0002] With the rapid development of mobile terminal applications, the Android system generates massive and diverse log data during operation. These logs often contain system anomalies, error messages, and operational status, serving as crucial information for R&D teams to troubleshoot and maintain the system. However, most existing log analysis methods employ traditional approaches based on rule matching and template recognition, triggering alarms or outputting analysis results according to rules. For data containing large amounts of noise and unstructured information, a single rule matching method often leads to misjudgments or missed detections, reducing the accuracy of anomaly detection. Furthermore, analyzing large volumes of data can result in slow response times or even system crashes.

[0003] Furthermore, some commercial log analysis tools rely on cloud processing, posing a risk of privacy leaks during data transmission and storage, which is unsuitable for application environments with high data security requirements. Therefore, traditional log analysis methods have significant shortcomings in adaptability, real-time performance, accuracy, and data security. There is an urgent need for an intelligent log analysis method that can run efficiently locally and possesses deep learning capabilities to improve the overall efficiency and reliability of anomaly detection and maintenance on Android devices. Summary of the Invention

[0004] This application provides an anomaly log analysis method and apparatus, which can realize an intelligent log analysis method that runs efficiently locally and has deep learning capabilities, so as to improve the overall efficiency and reliability of Android system anomaly detection and maintenance.

[0005] Firstly, an anomaly log analysis method is provided, applied to Android devices, comprising: acquiring a log information set of the Android device, the log information set including multiple raw log messages; standardizing the format of each raw log message to obtain a first log set including multiple log messages with uniform format; filtering and obtaining a second log set based on the first log set, the second log set excluding redundant log messages in the first log set and including missing fields of log messages in the first log set; labeling each log message with a category tag based on the content of each log message in the second log set, classifying the multiple log messages in the second log set according to the category tags to obtain a third log set; organizing the third log set according to the time sequence information and category tags of each log message in the third log set to generate multiple log information sequences; sending the multiple log information sequences to a local server, the local server including a first model, and obtaining an anomaly log report corresponding to the Android device and repair suggestions corresponding to the anomaly log report based on the multiple log information sequences and the first model.

[0006] By employing the aforementioned anomaly log analysis method, massive log information sets acquired from Android devices can be processed, unifying the format of log information from different sources. This ensures that logs from different sources can be stored according to the same data structure, enabling subsequent processing steps to efficiently parse the core components of each log (timestamp, level, source, content), improving parsing and storage efficiency. Cleaning the unified formatted log information reduces the number of log messages that need to be parsed, ensuring data integrity while increasing data value density and reducing computational load. Categorizing the cleaned log information allows for priority determination of analysis by level, helps in identifying the level of problem occurrence by source, and aids in subsequent modeling by anomaly pattern. The analysis can quickly identify specific fault types. By labeling log data with category tags, rich contextual information is built for subsequent anomaly analysis. Grouping and sorting the categorized log information can ensure the temporal consistency of the logs, reconstruct the time flow of anomaly occurrences, and effectively isolate mutual interference between logs from different modules. At the same time, grouping and sorting by anomaly category helps to analyze whether similar crashes occur in multiple applications, thereby supporting deeper anomaly pattern analysis. The preprocessed log information is input into an AI pre-trained model deployed on a local server for analysis, ultimately obtaining an anomaly log report corresponding to the Android device and corresponding repair suggestions, improving the overall efficiency and security reliability of Android device anomaly detection and maintenance.

[0007] In conjunction with the first aspect, obtaining the second log set based on the first log set includes: filtering invalid log information and deduplicating multiple duplicate log messages with the same content, retaining only one duplicate message; invalid log information includes: debug information logs, heartbeat logs, keep-alive signal logs, blank lines, and noisy log data containing garbled characters. By cleaning and removing log information without analytical value from the collected log information, the number of log messages that need to be parsed can be reduced, ensuring data integrity while increasing data value density, reducing computational load, and improving the overall efficiency of Android device anomaly detection and maintenance.

[0008] In conjunction with the first aspect, log information includes timestamps, log levels, log sources, and log content. Timestamps indicate when the log information occurred, log levels indicate the importance and severity of the log information, log sources indicate the origin of the log information, and log content indicates the operational information of the corresponding source module. Missing fields in the first log set include at least one of the following: missing log content, missing timestamps, and missing log levels. Correcting missing fields can ensure data integrity while increasing data value density and improving the accuracy of anomaly log analysis.

[0009] In conjunction with the first aspect, the category labels include at least one of the following: log level labels, log source labels, and log anomaly pattern labels. Labeling each log message with a category label based on its content in the second log set includes: identifying the category information in each log message according to a first rule and labeling it with a category label. The first rule includes multiple first log fields corresponding to the log level, multiple second log fields corresponding to the log source, and multiple third log fields corresponding to the log anomaly pattern. Classifying by level helps determine the priority of analysis; classifying by source helps determine the level of the problem; classifying by anomaly pattern helps subsequent model analysis quickly identify specific fault types. By labeling log data with category labels, rich contextual information is built for subsequent anomaly analysis, improving the overall efficiency and reliability of anomaly log analysis.

[0010] In conjunction with the first aspect, log level labels include at least one of INFO, WARNING, ERROR, and FATAL; log source labels include at least one of application logs, system logs, and kernel logs; and log exception mode labels include at least one of crash logs, ANR logs, and memory leak logs.

[0011] In conjunction with the first aspect, the third log set is organized based on the time sequence information and category tags of each log message. This includes: sorting multiple log messages in the third log set according to their timestamps to obtain a first log message sequence arranged chronologically; generating multiple second log message sequences based on the log source tags of each log message in the first log message sequence, with each second log message containing the same log source tag and arranged chronologically; and generating multiple log message sequences based on the log exception pattern tags of each log message in each second log message sequence, with each log message containing the same log exception pattern tag and arranged chronologically. Grouping and sorting the categorized log messages ensures the consistency of log timing, reconstructs the timeline of exception occurrences, and effectively isolates interference between logs from different modules. Furthermore, grouping and sorting by exception category helps analyze whether similar crashes occur in multiple applications, thus supporting deeper anomaly pattern analysis and improving the overall efficiency and reliability of Android device anomaly detection and maintenance.

[0012] Combining the first aspect, based on multiple log information sequences and a first model, obtaining an anomaly log report corresponding to an Android device includes: sending multiple log information sequences to the first model to obtain high-dimensional feature vectors that characterize the root cause of the anomaly; the first model obtaining an anomaly correlation graph based on the high-dimensional feature vectors to show the triggering reasons of the anomaly logs; and generating an anomaly log report based on the anomaly correlation graph. The anomaly log report includes multiple anomaly log messages representing Android device anomalies from multiple log information sequences and the triggering factors corresponding to each of the multiple anomaly log messages. By using an AI model to process the preprocessed log information to construct an anomaly correlation graph, anomaly log messages and corresponding triggering factors are obtained, thereby generating an anomaly log report. This presents engineers with a clear understanding of the anomaly type and triggering reasons, facilitating rapid anomaly location and repair.

[0013] Combining the first aspect, based on multiple log information sequences and the first model, the corresponding repair suggestions for the abnormal log reports are obtained as follows: Repair suggestions are obtained based on the second rule, a preset knowledge base, and the abnormal log report itself. The second rule includes information on the type of abnormal log and the corresponding triggering factors. The knowledge base includes fault information of the Android device and corresponding repair solutions. By matching the anomalies analyzed by the AI ​​model with the preset knowledge base, repair suggestions corresponding to the anomaly information can be quickly obtained. This not only points out the root cause of the Android device failure but also provides staff with multiple alternative solutions, helping them to quickly locate and resolve the problem.

[0014] Based on the first aspect, an anomaly information analysis report is generated according to the anomaly log report and remediation suggestions. This report includes at least one of the following: the frequency of occurrence, the distribution of anomaly patterns, and the trend of anomaly patterns. An alarm is issued based on the third rule and the anomaly information analysis report. The third rule includes frequency information of the anomaly patterns, used to filter anomaly log information whose frequency exceeds a threshold. Through real-time log analysis, an alarm mechanism is triggered when the system detects a critical fault or continuous anomaly events. By pre-setting alarm triggering rules, an alarm can be issued to developers when the anomaly frequency exceeds the standard, a key anomaly indicator reaches the warning threshold, or root cause analysis shows a serious fault. This provides a fault information summary and links to related reports, helping engineers quickly locate the problem and carry out emergency handling.

[0015] In a second aspect, a test case generation apparatus is provided, comprising: a processor and a memory, the memory for storing computer programs, and the processor for calling and running the computer programs stored in the memory to execute the test case generation method provided in the first aspect. Attached Figure Description

[0016] Figure 1 This is a schematic block diagram of an abnormal log analysis method provided in an embodiment of this application.

[0017] Figure 2 This is a schematic block diagram of anomaly log reasoning analysis in a first model provided in an embodiment of this application.

[0018] Figure 3 This is a schematic diagram of an anomaly log analysis device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0020] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one, two, or more than two. The term “and / or” is used to describe the relationship between related objects, indicating that three relationships may exist; for example, A and / or B can indicate: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character “ / ” generally indicates that the preceding and following related objects are in an “or” relationship. “At least one of the following” or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can be represented as: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single or multiple.

[0021] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. Furthermore, in embodiments of this application, words such as "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0022] In the embodiments of this application, "corresponding" and "corresponding" can sometimes be used interchangeably. It should be noted that when the distinction is not emphasized, their intended meanings are consistent.

[0023] The business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0024] For ease of description, the concepts involved in the embodiments of this application will be explained below.

[0025] 1. Log

[0026] Logs, also known as log data or log information, are mechanisms that record the code execution process in detail. For example, they record events or messages that occur during the operation of a system or application. High-quality log data helps developers quickly locate the location and cause of faults, and thus quickly fix them.

[0027] The following sections describe logs from the perspectives of their purpose, type, and content.

[0028] The purposes of logs may include, but are not limited to:

[0029] 1) Monitoring: Tracking the status and operation of a system or application;

[0030] 2) Debugging: Helps developers identify and resolve problems;

[0031] 3) Auditing: Record user activity for security audits or compliance checks;

[0032] 4) Prediction: Predict future system behavior or performance issues by analyzing log data.

[0033] Log types can include, but are not limited to:

[0034] 1) System Log: Records events from the operating system or underlying hardware;

[0035] 2) Application Logs: Record events and states within the application;

[0036] 3) Security Log: Records security-related events, such as login attempts and permission changes;

[0037] 4) Access Log: Records user access to resources.

[0038] The log content may include, but is not limited to:

[0039] 1) Timestamp: Records the time when an event occurred;

[0040] 2) Event Description: Describe the specific details of the event;

[0041] 3) Log source: Indicates the source of the event (e.g., which user, which application, which server, etc.);

[0042] 4) Log levels: These typically include DEBUG, INFO, WARNING, ERROR, and FATAL.

[0043] 2. Log statement

[0044] A logging statement, also known as logging code, is a line of code in the source code used to record information about program execution. By writing and inserting logging statements into the source code, corresponding log data can be generated during program runtime. This log data is then collected, stored, and analyzed to support various system management and development tasks.

[0045] For example, a logging statement typically consists of two parts: the log level and the log message. The log level defines the severity and priority of the event being logged. Common log levels include DEBUG (debugging information, usually used only during development), INFO (general information, used to record normal program runtime information), WARNING (warning message, indicating a potential problem that won't cause program interruption), ERROR (error message, indicating an error has occurred during program runtime), and FATAL (fatal error, indicating the program can no longer continue running). The log message typically records information such as the occurrence of a system event, abnormal system states, and key variable values. This information helps developers understand the program's operation and promptly identify and resolve problems.

[0046] 3. Long Short-Term Memory (LSTM) Network

[0047] Long Short-Term Memory (LSTM) networks are a variant of Recurrent Neural Networks (RNNs) specifically designed to address long-term dependencies in sequential data. When processing Android system anomaly log filtering tasks, traditional static text analysis methods are ineffective due to the significant time-series nature of the log data and the fact that anomaly determination often depends on a complete logical chain of context. This application utilizes the unique gating structure of LSTM (including forget gates, input gates, and output gates) to effectively filter key information and remember historical states from long-sequence log data streams. Through the LSTM network layers, the system can automatically extract the implicit temporal logical features in the logs and transform unstructured text information into anomaly feature vectors containing contextual relationships. This process significantly improves the model's accuracy in identifying complex, intermittent Android anomalies, ensuring that the feature vectors truly reflect the dynamic process of anomaly occurrence.

[0048] 4. Attention Mechanism

[0049] In this application, an attention mechanism is used to address the information focus problem in long-sequence Android logs. Since Android anomaly logs often contain a large amount of system noise unrelated to the anomaly, directly processing the original sequence can easily lead to feature ambiguity. The attention mechanism dynamically adjusts the model's focus on log data at different times through a probability-weighted approach. It can identify the temporal relationships and logical dependencies within the data, automatically highlight key log segments containing anomaly patterns, and suppress interference from irrelevant information. By applying the attention mechanism to the log feature extraction layer, the anomaly feature vector constructed in this invention can more accurately represent the essential characteristics of anomaly events, ensuring that subsequent filtering models can make judgments based on the most crucial contextual information, rather than being misled by redundant data.

[0050] 5. Debug Info Logs

[0051] Debug logs refer to log information inserted by developers during the software development and testing phase to track program execution flow, verify variable states, or locate logical errors. These logs are typically marked at the DEBUG or VERBOSE level and are characterized by large data volumes, fine granularity, and the inclusion of a significant amount of temporary information unrelated to system operation monitoring. In anomaly analysis scenarios, unless deep debugging of a specific module is being performed, these logs usually do not contain key characteristics indicating system crashes or service interruptions; therefore, they are considered redundant data and removed in this application.

[0052] 6. Heartbeat Logs

[0053] Heartbeat logs refer to periodic status acknowledgments sent at fixed time intervals by system services, network modules, or application processes to confirm connection validity or service liveness. The content of these logs is typically highly repetitive and singular (e.g., containing only identifiers like "ping" or "alive"), and their primary function is to demonstrate that system components are running. Because they are generated frequently and in large quantities during normal operation and do not carry valid information about state changes or abnormal triggers, they contribute very little to capturing temporal anomalies and are therefore considered redundant logs with no practical value and are removed in this application.

[0054] 7. Keep-alive Logs

[0055] Keep-alive signal logs refer to the maintenance log information generated by the Android system or applications to maintain long-lived connections, prevent processes from being reclaimed by the system, or prevent devices from entering a sleep state. Similar to heartbeat logs, keep-alive signal logs are mainly used to maintain specific system states (such as WakeLock holding records and Socket connection maintenance records). They typically appear as high-frequency, repetitive records of routine operations. When constructing anomaly feature vectors, a large number of keep-alive logs dilute the weight of key anomaly information; therefore, redundant logs considered to have no practical value are removed in this application.

[0056] 8. Noise Log Data

[0057] Noisy log data refers to data fragments generated during log collection or transmission that lack a complete semantic structure or cannot be recognized by standard parsers. Specifically, this includes, but is not limited to: garbled characters, unreadable characters due to encoding mismatches (such as mixing UTF-8 and GBK); invalid characters and blank lines, blank lines without any text content, or records containing only non-printable characters such as tabs and newlines. Such data not only fails to provide semantic information but may also interfere with subsequent word segmentation and entity recognition processes, affecting the accuracy of the analysis results. Therefore, it must be cleaned up during the preprocessing stage.

[0058] 9. Root Cause

[0059] In this application, the root cause refers to the fundamental triggering factor or logical origin that causes the Android system to generate abnormal logs or fault phenomena, which is different from the surface symptoms or error locations presented in the logs of abnormal events.

[0060] 10. Anomaly Association Graph

[0061] In the application, the anomaly correlation graph refers to a directed graph data structure or visualization model constructed based on the output of the causal relationship analysis algorithm. It maps each detected abnormal event and influencing factor as a node, and maps the temporal dependence and logical causal relationship between them as connecting edges, thus clearly marking the complete propagation path of the fault from the fundamental triggering factor (i.e. the root cause of the anomaly) to the subsequent manifestations. It aims to present the full picture of the fault and key nodes in a structured way, and help R&D personnel quickly understand the abnormal logic and locate the problem.

[0062] With the rapid development of mobile terminal applications, the Android system generates massive and diverse log data during operation. These logs often contain system anomalies, error messages, and operational status, serving as crucial information for R&D teams to troubleshoot and maintain the system. However, most existing log analysis methods employ traditional approaches based on rule matching and template recognition, triggering alarms or outputting analysis results according to rules.

[0063] While the methods described above are effective for processing simple, standardized logs, they have significant limitations when dealing with complex business logic, dynamic changes, and multi-layered nesting. First, log data contains a large amount of noise and unstructured information, making it difficult for a single rule-based matching method to fully utilize contextual semantics. This can easily lead to false positives and false negatives in anomaly detection, thus reducing detection accuracy. Second, as the log volume continues to increase, traditional algorithms tend to reach bottlenecks in terms of computational complexity and processing efficiency, often resulting in analysis delays or even system crashes, making it difficult to meet the real-time requirements of large-scale log scenarios. Furthermore, some commercial log analysis tools rely on cloud processing, posing a risk of privacy leaks during data transmission and storage, which is unsuitable for application environments with high data security requirements.

[0064] More importantly, existing technologies generally lack automated root cause analysis capabilities. They can only roughly locate the position of anomalies, but cannot accurately analyze the underlying causes or automatically generate effective remediation suggestions, still relying heavily on manual intervention and experience-based judgment. Therefore, traditional log analysis methods have significant shortcomings in adaptability, real-time performance, accuracy, and data security. There is an urgent need for an intelligent log analysis method that can run efficiently locally and possesses deep learning capabilities to improve the overall efficiency and reliability of anomaly detection and maintenance in Android systems.

[0065] In view of this, embodiments of this application provide an anomaly log analysis method and apparatus. This method can run efficiently locally and has deep learning capabilities to improve the overall efficiency and security reliability of anomaly detection and maintenance in the Android system.

[0066] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0067] Figure 1 A schematic block diagram of an anomaly log analysis method is shown. Figure 1 As shown, the anomaly log analysis method 100 includes the following steps.

[0068] S110 obtains a set of log information from an Android device. The set of log information includes multiple raw log messages. Each raw log message is processed to standardize its format to obtain a first set of log messages containing multiple log messages with uniform format.

[0069] This process retrieves the current log information set from an Android device. Specifically, for example, a log collection module can be embedded in the Android device to capture system logs and exception information in real time. The retrieved log information set includes a large amount of raw log information. The different sources of this raw log information lead to variations in format. The core components of each raw log message are parsed, such as: timestamp (the time the log occurred, standardized to a unified time format (e.g., ISO 8601 or Unix timestamp); log level (INFO, WARNING, ERROR, FATAL, etc.) for easier subsequent classification and analysis; log source (recording which process, thread, or module the log originated from); and other log content (specific log messages, including exception stack traces, error messages, warnings, etc.). Through regular expression parsing, JSON format conversion, and text structuring, the log format of different raw log information is unified, ensuring that logs from different sources can be stored using the same data structure. This allows subsequent processing steps to efficiently parse the core components of each log message (timestamp, level, source, content), improving parsing and storage efficiency and obtaining a unified first log set.

[0070] S120 obtains a second log set by filtering the first log set. The second log set does not include redundant log information in the first log set, and the second log set includes missing fields of log information in the first log set.

[0071] The first log set contains a massive amount of log information. Real-time parsing of such a large volume of logs would increase the computational load and could potentially cause crashes. Therefore, pre-screening of the first log set is necessary. This screening includes correcting log information with missing fields. Specifically, during the formatted parsing of log information, if any anomalies such as missing timestamps, missing log levels, or incorrect field formats are detected, an anomaly data correction process is triggered. For log information with missing timestamps, the most recent log information with a valid timestamp is searched from the log sequence containing that log, and that timestamp is added to the timestamp field of the current log to ensure the temporal continuity of the log sequence. For log information with missing log levels, in some examples, the log content is matched based on a preset mapping relationship between keywords and log levels. When the content contains exception indicator fields such as "Exception," "Crash," or "ANR," the level field of that log information is automatically corrected to ERROR or FATAL.

[0072] In other examples, when preset rules cannot determine the level, a pre-trained log level prediction model can be invoked. The log content is converted into a feature vector and input into the model, which then outputs the probability distribution of each candidate level. The level with the highest probability is selected as the correction result. This anomaly correction method, which combines rules and machine learning, can automatically complete missing fields without human intervention, improving the completeness of log data and the accuracy of subsequent anomaly analysis.

[0073] The log filtering process also includes the automatic identification and deletion of redundant log information. Specifically, for log information that only reflects Android device heartbeat detection, keep-alive detection, or debugging information, the system pre-maintains a set of rules corresponding to keywords such as "heartbeat" and "keep-alive" as well as the names of monitoring keep-alive modules. During the log cleaning process, the source module, log level, and log content of each log information are compared. When a log information is detected that matches the above rules and does not contain anomaly indication fields, the log information is marked as a useless log and removed from the log set to be analyzed.

[0074] For noisy data, after removing whitespace characters, the system will directly delete the log line if it is empty or contains only non-printable characters; if the proportion of non-printable characters or garbled characters in the log line exceeds a preset threshold, or if the line does not conform to the predefined log structure format and is not part of the exception stack information, the line will also be regarded as noisy data and discarded.

[0075] For duplicate logs, the system constructs deduplication keys based on the log source, log level, and log content, and calculates the corresponding hash value to identify duplicate logs. When a new log message's hash value already exists in the deduplication hash table, the log message is not stored again; instead, only the occurrence count corresponding to that hash value is accumulated. Optionally, the system can also standardize and replace variable fields such as numeric IDs and request identifiers in the log content, and perform similarity comparisons based on the standardized template strings. Log messages with identical templates or similarity exceeding a preset threshold are merged and stored. Through the above identification and cleaning of redundant logs, the log data size can be significantly reduced, and the interference of invalid noise on subsequent anomaly analysis and model training can be reduced. The first log set is cleaned in this way to obtain the second log set.

[0076] S130 marks each log message with a category label based on the content of each log message in the second log set, and classifies multiple log messages in the second log set according to the category labels to obtain the third log set.

[0077] After completing the log formatting and cleaning in S110 and S120 above, each log message in the obtained second log set is categorized so that each log message is associated with at least one category label for subsequent anomaly detection and context analysis. The log categorization includes at least classification by log level, classification by log source, and classification by anomaly pattern. Each log message in the second log set is labeled with a category label, which includes at least one of the following: log level label, log source label, and log anomaly pattern label.

[0078] In some examples, after completing log formatting and exception data correction, the system first parses the log level field from each log message according to the first rule, standardizes the parsed level string into predefined levels such as INFO, WARNING, ERROR, and FATAL, and writes the level into the "level_tag" field in the log structure. Optionally, different levels of log messages are stored in their corresponding log sets. Subsequently, the system reads the source fields of the log messages (e.g., log tag, process identifier, package name, or system facility field) and, based on the pre-defined source mapping rule table in the first rule, classifies the log messages into application logs, system logs, or kernel logs, writing the source category into the "source_tag" field. Furthermore, the system uses the pre-defined exception pattern library in the first rule to perform pattern matching on the log content. When the log content contains exception indicator keywords such as "FATAL EXCEPTION," "ANR in," or "OutOfMemoryError," or matches a pre-defined stack trace regular expression template, the log message is classified into the corresponding exception category, such as a crash log, ANR log, or memory leak log.

[0079] In some examples, when the first rule cannot uniquely determine the anomaly pattern category of log information, the system can also call an anomaly pattern classification model trained based on historical labeled data to perform multi-class prediction on the feature vector of the log content, and select the anomaly category with the highest confidence as the anomaly pattern label for that log information based on the predicted probability. Through the above log classification process, each log message carries one or more category labels, providing structured contextual information for subsequent context-based anomaly detection, causal relationship analysis, and root cause localization.

[0080] After classification, a third log set is obtained, in which each log message includes at least one category label. Log level labels include at least one of INFO, WARNING, ERROR, and FATAL; log source labels include at least one of application logs, system logs, and kernel logs; log exception mode labels include at least one of crash logs, ANR logs, and memory leak logs.

[0081] S140 organizes the third log set according to the time sequence information and category label of each log message in the third log set, and generates multiple log message sequences.

[0082] After completing S110 log formatting, S120 cleaning, and S130 classification, the system groups and sorts the log information to construct a structured log sequence that can be used for anomaly detection, time series analysis, and causal inference.

[0083] Based on the timestamp, log source tag, and log exception mode tag contained in each log message in the third log set, a configurable sorting and grouping strategy is used to organize and aggregate the log data at multiple levels, enabling subsequent analysis stages to perform fine-grained correlation analysis on the logs according to module, time, and exception type.

[0084] In some examples, the timestamp field in the log information is first extracted. A quicksort algorithm or other stable sorting algorithm is then used to globally sort all log information in ascending or descending order according to the time included in the timestamps, thus restoring the true timeline of the logs and obtaining a first log information sequence. Based on this, the system reads fields indicating the log source, such as package name, process ID, thread ID, or log source tag, and adds log information with the same module identifier to the same module log set according to preset module identification rules, achieving grouping by source module and obtaining multiple second log information sequences. Within each module log set, the system further groups the logs according to the log anomaly mode tag obtained in S130, classifying them by anomaly mode category. For example, log information belonging to the CRASH category is grouped into a crash log subset, log information belonging to the ANR category is grouped into a no-response log subset, and log information belonging to the OOM category is grouped into a memory leak log subset. After completing the above grouping, each subgroup is locally sorted by timestamp to ensure the internal timeline continuity of each subgroup, generating multiple log information sequences. Through the above multi-dimensional grouping and sorting structured processing, subsequent anomaly analysis can quickly identify log sets belonging to the same application, the same module, or the same anomaly type, providing a well-organized contextual basis for subsequent anomaly pattern detection, root cause analysis, and anomaly link inference.

[0085] S150 sends multiple log information sequences to a local server, which includes a first model. Based on the multiple log information sequences and the first model, it obtains an abnormal log report corresponding to the Android device and a repair suggestion corresponding to the abnormal log report.

[0086] The preprocessed log information sequences from S140 are sent to a local server including the first model. These preprocessed log information sequences are then input into the first model for inference and analysis to obtain an anomaly log report corresponding to the Android device and corresponding repair suggestions. The anomaly log report includes multiple anomaly log messages from the log information sequences representing Android device anomalies and the root cause of each anomaly log message.

[0087] In this context, a local server refers to the primary model used for deploying anomaly log analysis and performing inference analysis on preprocessed log information from Android devices. This local server can be a physical server, virtual machine server, computing node in a private cloud cluster, or edge computing device deployed in a controlled local area network environment, all within an enterprise or institutional data center. As long as the server is within an internal network environment controlled by the log data owner, rather than a third-party public cloud platform, it can be considered a local server; no further restrictions are imposed here. By using a local server for model deployment and log analysis, the upload of anomaly log data to external commercial cloud platforms is avoided, reducing the risks associated with data transmission over the public internet and third-party storage, thereby enhancing data security and privacy protection during the log analysis process.

[0088] The first model is a pre-trained AI analysis model, which can be a machine learning model or a deep learning model for anomaly log analysis, including but not limited to: Long Short-Term Memory (LSTM) network models based on word vector representation and sequence modeling, Bidirectional Recurrent Neural Network (Bi-RNN) models, Convolutional Neural Network (CNN) text classification models, attention mechanism models, Transformer models, BERT-like pre-trained models, GPT-like large language models, Graph Neural Network (GNN) models, hybrid models combining rule bases, or log analysis models obtained by transfer learning, incremental learning, or domain fine-tuning based on these models. The first model can be deployed on local servers, private cloud computing nodes, virtual machine servers, or edge computing devices to perform anomaly detection, anomaly classification, causal chain analysis, and repair suggestion generation on the multiple pre-processed log information sequences. The specific type and structure of the first model can be flexibly selected according to the actual application scenario, and no further limitations are imposed here.

[0089] The following is combined with Figure 2 A detailed description is given of the input of multiple preprocessed log information sequences into the system. Figure 2 It shows the Figure 1 The diagram illustrates the preprocessed sequences of log information obtained in the first model for anomaly log inference analysis. (See attached diagram.) Figure 2 As shown, the anomaly log reasoning analysis 200 in the first model includes the following steps.

[0090] The S210 first model acquires multiple preprocessed log information sequences, performs feature extraction and data encoding on the multiple log information sequences, and obtains a high-dimensional feature vector that can characterize the root cause of the anomaly.

[0091] After inputting preprocessed log sequence information into the anomaly log analysis model, the first model performs feature extraction and data encoding operations to generate high-dimensional feature vectors for anomaly identification and root cause localization. Specifically, the first model first segments the preprocessed log text, breaking down continuous log content into multiple basic units, including keywords, error codes, class names, method names, file paths, and other semantic units important for anomaly diagnosis. Based on the segmentation, the first model uses a pre-trained named entity recognition model or preset rules to perform entity recognition on specific identifiers in the log, locating and labeling key entities such as class names, method names, thread names, anomaly names, and stack entries from the log text, thereby enhancing the model's ability to understand the log structure and semantics.

[0092] Subsequently, the first model inputs the log word sequence, after word segmentation and entity recognition, into the embedding layer. Using pre-trained word vectors (such as Word2Vec, GloVe, etc.) or locally trained embedding matrices, it maps discrete text symbols to a continuous vector space to construct a semantic representation of the log word sequence. Each word corresponds to a vector representation, and all vectors are combined in the original order of the log text to form a vector sequence representing that log text.

[0093] Next, the first model inputs the vector sequence into a Long Short-Term Memory (LSTM) network. Leveraging LSTM's sequence modeling capabilities, it captures temporal dependencies and contextual relationships across lines and fields in the log text. During the processing of the word vector sequence, LSTM updates its internal hidden state at each time step, thereby extracting local semantic features and global semantic structure information. This enables the model to identify hidden anomaly triggering chains and potential behavioral patterns within the log content.

[0094] In some embodiments, the first model further introduces a force attention mechanism based on the LSTM output to enhance the importance of log segments related to anomaly occurrence, anomaly propagation, or key semantic nodes. Specifically, the first model calculates attention weights for the hidden states of the LSTM at each time step and performs a weighted summation of the hidden states according to the weights, thereby obtaining a weighted feature representation that highlights the core semantics of the abnormal behavior. The attention mechanism enables the model to automatically focus on the most critical parts of the log text for anomaly diagnosis, such as anomaly stack locations, error trigger points, latency accumulation points, and thread blocking sources, thereby improving the accuracy of subsequent anomaly identification and root cause analysis.

[0095] The first model integrates the weighted features calculated by the LSTM hidden state and the attention mechanism to generate a high-dimensional anomaly feature vector corresponding to the log entry. This anomaly feature vector contains semantic information, contextual structure, temporal dependencies, and key anomaly patterns of the log content, serving as a unified input representation for the model to perform anomaly detection, anomaly classification, anomaly link inference, and root cause localization. Subsequent anomaly identification, causal relationship analysis, or remediation suggestion generation modules can all perform inference analysis based on this high-dimensional feature vector, thereby achieving intelligent identification and processing of anomaly logs.

[0096] In this context, the hidden state refers to the internal state vector output by the LSTM or other sequence model at each time step. This vector stores the model's memory of the historical input sequences and their semantic features. The hidden state is continuously updated as the input sequence is traversed, comprehensively reflecting the local and global temporal semantic information of the log text, and is used to generate the final high-dimensional feature vector representing the root causes of anomalies.

[0097] S220 performs causal relationship analysis based on high-dimensional feature vectors to obtain root cause analysis results, and constructs anomaly correlation maps based on the root cause analysis results.

[0098] After obtaining the high-dimensional feature vector corresponding to each log message in the preprocessed log message sequences in S210, causal relationship analysis is performed on the feature vector sequence to identify the triggering links between abnormal events and construct an anomaly correlation graph. Specifically, the first model first integrates the high-dimensional feature vectors of each log message according to the log's time order, module, and contextual relevance based on the temporal information and contextual features obtained in the feature extraction stage, forming a continuous feature sequence for causal analysis. During the integration process, the first model not only considers the semantic features of a single log message but also combines the correlation between adjacent log messages in terms of time, module, and anomaly category to construct a contextual structure reflecting the evolution of the first model's operating state.

[0099] Subsequently, the first model applies a causal relationship analysis algorithm to the aforementioned contextual feature sequences to infer potential causal dependencies between logs. Causal relationship analysis algorithms can include attention-score-based causal contribution analysis, feature similarity-based event aggregation algorithms, time-series-based causal inference algorithms (e.g., Granger causal analysis), or graph-model-based causal chain extraction algorithms. During the analysis, the first model calculates the causal association strength between each log feature vector, representing the degree of influence of one log event on another in the anomaly propagation chain; when a log event has a high causal contribution in multiple anomaly chains, the first model marks that log event as a possible root cause node.

[0100] After completing the causal chain inference, the first model constructs an anomaly correlation graph based on the inferred causal relationships. Specifically, the first model represents the event corresponding to each anomaly log as a node in the graph, and establishes directed connections between nodes based on the dependencies between logs obtained from causal relationship analysis; pointing from the triggering event to the affected event, it reflects the anomaly propagation path. In addition, the first model can also assign weights to the edges in the graph according to their causal contribution, which is used to represent the strength of the influence between different anomaly events. The generated anomaly correlation graph can intuitively display the hierarchical structure and propagation relationship of anomaly events, clearly pointing out the root cause event that triggers the anomaly, the critical path that leads to the spread of the anomaly, and the final abnormal symptoms, which facilitates the overall understanding and rapid localization of the first model's failures by R&D personnel.

[0101] S230 generates an anomaly log report based on the anomaly correlation graph, and generates repair suggestions corresponding to the anomaly log report based on the anomaly log report, the preset knowledge base, and the second rule.

[0102] After constructing the anomaly correlation graph in S220, anomaly log reports representing Android device anomalies are generated based on this graph. Specifically, each node in the anomaly correlation graph represents an anomaly log record, and the node includes information such as the log timestamp, log source module, log anomaly mode, and anomaly high-dimensional feature vector. The directed edges between nodes in the graph represent the causal relationships between anomaly events. The direction of the directed edges points from the upstream event that triggered the anomaly to the downstream event that was affected, and the edge weights characterize the strength of the causal influence.

[0103] First, root cause nodes are identified in the anomaly correlation graph. Root cause nodes can be determined using one or a combination of the following rules: for example, nodes with an out-degree greater than a preset threshold and a small in-degree, nodes located at the beginning of multiple anomaly links, and nodes with high causal contribution scores can all be marked as candidate root cause nodes; candidate root cause nodes can be sorted according to causal contribution, anomaly severity, or the importance of the module to which the node belongs, and nodes that meet preset conditions are selected as anomaly root cause nodes.

[0104] Secondly, for each identified root cause node, a traversal is performed along the directed edges in the anomaly association graph to find all downstream anomaly nodes reachable from the root cause node. The set of the root cause node and its reachable downstream anomaly nodes is defined as an anomaly event cluster. For each anomaly event cluster, the anomaly log information corresponding to all nodes in the cluster can be extracted, including but not limited to: log identifier, timestamp, log source tag, log anomaly pattern tag, log level tag, and corresponding high-dimensional feature vector, thereby obtaining multiple sets of anomaly log information associated with a certain root cause.

[0105] Furthermore, for each cluster of anomalous events, corresponding anomalous entries are constructed to form a structured anomalous log report. Specifically, the anomalous log information corresponding to the root cause node can be used as the root cause description of the anomalous entry, and the anomalous log information corresponding to the downstream anomalous nodes reachable from the root cause node can be used as the list of affected logs. Optionally, anomalous propagation path information extracted from the anomalous association graph can be attached, for example, displaying the anomalous chain in the form of "root cause event - intermediate propagation event - final manifestation event." This facilitates developers' quick understanding of the scope of the anomalous impact and its evolution process.

[0106] An anomaly log report is generated by summarizing the anomaly entries generated for each root cause node. The anomaly log report can include at least multiple anomaly entries, each corresponding to a set of anomaly log information and a description of the anomaly root cause associated with that set of anomaly log information. The report may further include remediation suggestions for each anomaly root cause, a list of potentially affected functional modules, and the frequency of anomaly occurrences. The generated anomaly log report can be displayed through a user interface or provided to terminal devices via a pre-defined application programming interface (API) to assist R&D or operations personnel in fault location and repair. This invention does not impose excessive limitations on the specific construction method of the anomaly association graph, the identification rules of root cause nodes, or the display format of anomaly entries.

[0107] Finally, the generated anomaly log reports are matched against the second rule and the preset knowledge base to obtain specific remediation suggestions for each anomaly in the log reports, including code modifications, configuration adjustments, or system optimization solutions. These remediation suggestions not only pinpoint the root cause of the fault but also provide developers with multiple alternative solutions to help them quickly locate and resolve the problem. The second rule includes information on various types of anomaly logs and the corresponding root cause information. The preset knowledge base includes past Android device failure cases, remediation solutions, and expert experience.

[0108] Furthermore, an anomaly analysis report can be generated based on the anomaly log reports and corresponding remediation suggestions. This report includes the anomaly classification, frequency of occurrence, root cause description, anomaly pattern distribution and occurrence trend for each anomaly pattern, and remediation suggestions. In some examples, an API interface is designed for developers to query report details. This interface includes report retrieval, filtering, sorting, and pagination functions, supporting queries based on multiple dimensions such as time and anomaly type.

[0109] The API returns a data structure containing detailed report data, such as anomaly classification, frequency of occurrence, root cause description, and remediation suggestions. This ensures real-time response to queries, provides developers with the latest anomaly analysis information, and employs authentication and access control during API calls to guarantee the security and reliability of data access.

[0110] In some embodiments, a feedback information collection unit can also be set up on a local server or Android device. This unit can be located in the display interface of the anomaly log analysis report, the API return result interface, or the operation and maintenance management backend, and is used to receive feedback and evaluation from R&D personnel or system maintenance personnel. Feedback content may include: evaluation of the accuracy of the anomaly determination; feedback on the correctness of the root cause localization results; subjective evaluation of the effectiveness of the repair suggestions; actual fault handling results (e.g., repair success / failure); supplementary manual annotation information (e.g., correct anomaly classification or root cause type), etc., without further limitations. Feedback information can be stored in the system's feedback data storage area for use during subsequent training.

[0111] In some examples, the above feedback information is compared with the generated anomaly log report, including but not limited to: whether the anomaly type matches; whether the root cause judgment is consistent; whether the remediation suggestions are effective; and whether the anomaly link inference is consistent with the actual situation. Through comparison, "correction samples" can be generated for training, forming a training dataset that can be used for model fine-tuning.

[0112] In some examples, the first model used for anomaly log analysis is continuously optimized based on the training samples compared above. This optimization can be achieved through methods including, but not limited to: incremental learning; online fine-tuning; continuous learning; and parameter updates using lightweight adaptation layers (such as LoRA layers). No further restrictions are placed on this approach. The model update process can be performed periodically or based on trigger conditions (such as when a preset amount of feedback data is received).

[0113] By continuously updating model parameters, the model can adapt to new anomaly patterns and changes in Android device versions, thereby improving the accuracy of anomaly detection and root cause localization.

[0114] In some embodiments, an alarm module can also be configured to proactively notify relevant personnel and issue an alarm when a critical anomaly or high-risk event is detected, so that timely handling can be carried out. This unit is used to identify potentially serious fault events and trigger an alarm when the warning conditions in the third rule are met. Warning conditions may include: the frequency of occurrence of abnormal logs exceeds a set threshold; multiple ERROR or FATAL logs occur in the same module within a short period of time; root cause analysis shows a high-risk fault type (such as memory overflow, system critical thread blocking, etc.); continuous abnormal links indicate that the system may be about to crash, and no further limitations are imposed here.

[0115] When an anomaly is determined to meet the warning conditions, the alarm triggering unit initiates the alarm process, encapsulating the alarm event into a structured data packet, including but not limited to: an anomaly event summary; affected modules; anomaly level; preliminary root cause judgment; associated anomaly links; and access links to the anomaly log analysis report. No further restrictions are imposed here.

[0116] The packaged alarm event data packet and alarm information will be pushed to designated personnel or alarm platforms. Push methods may include: SMS notification; email notification; instant messaging tools; internal alarm systems or operation and maintenance monitoring platforms, without further restrictions. The notification content may include an anomaly summary, severity, root cause inference results, and a link to view the full analysis report, so that engineers can quickly locate the problem and take emergency measures.

[0117] In some embodiments, a method for training and deploying a first model for anomaly log analysis on Android devices is provided. This process can be completed on a local server to ensure that log data is not leaked and to meet the requirements of real-time inference.

[0118] First, historical log data of Android devices is collected from the local server. The log data includes logs from normal operation as well as error or warning logs generated by abnormal operation.

[0119] The collected raw log data undergoes the aforementioned log preprocessing steps (including formatting, cleaning, classification, and grouping), and is ultimately converted into structured, standardized log entries, providing a unified and consistent data input format for subsequent training sample construction.

[0120] To train the anomaly detection and root cause analysis model, historical log data needs to be labeled. The labeling process can employ manual labeling, semi-automatic labeling, or rule-based assisted labeling methods; no specific limitations are imposed here. Each log entry can be labeled with the following information: whether it is an anomaly log; the anomaly category (e.g., crash, ANR, memory leak, etc.); and the anomaly root cause label (e.g., null pointer exception, array out-of-bounds error, thread blocking, etc.). This labeling generates training samples with supervisory signals, which can then be used for training the supervised learning model.

[0121] To avoid training bias caused by insufficient abnormal samples, statistical resampling of both normal and abnormal samples is necessary to achieve a relatively balanced distribution of the two types of samples. Subsequently, the log text undergoes word segmentation, entity recognition, and contextual semantic parsing, and the text content is converted into vector form through an embedding layer. For log sequences containing temporal relationships, sequence features can be further extracted, ultimately generating a set of feature vectors that can be input into the model for training.

[0122] Based on the characteristics of the log data, supervised learning models suitable for text features and time-series features can be selected, including but not limited to, ensemble learning models such as deep neural networks (DNN), recurrent neural networks (RNN), long short-term memory networks (LSTM), Transformer models, decision trees, or random forests, etc., without further restrictions here.

[0123] The model's training objectives include: anomaly log identification (classification task) and anomaly root cause prediction (multi-label task or sequence prediction task). Pre-constructed training samples are input into the model, and through multiple rounds of iterative training, the model learns the anomaly patterns and root cause features within the log content. In each training iteration, the model parameters are updated via backpropagation, enabling the model to achieve higher identification accuracy on the validation set. After training, the model can simultaneously output two types of results: anomaly determination for each log entry (whether it is anomaly, anomaly type) and root cause analysis results for the anomaly logs.

[0124] During model training, cross-validation is employed to divide the training data into multiple subsets, which are used alternately as the training and validation sets to reduce the impact of data partitioning bias on model performance. To prevent the model from learning noise from the training samples, the following regularization techniques can be used: for example, L1 / L2 regularization to limit the size of model parameters; Dropout to randomly discard some neuron connections; and early stopping to stop training when the validation set performance no longer improves. Hyperparameters such as learning rate, batch size, network depth, and number of hidden units are adjusted using grid search, random search, or cross-validation-based tuning methods to achieve optimal training results.

[0125] The trained model is saved as a parameter file or a weight file. A model loading module can be deployed on the local server to load model parameters and perform inference during inference. Local deployment ensures that log data is processed within the internal network, improving data security and avoiding transmission over the external network.

[0126] By building an efficient API interface, the preprocessed log feature vectors can be sent to the model inference module to quickly infer new log data and return anomaly identification and root cause analysis results, meeting real-time requirements.

[0127] After the model is deployed, the monitoring module can record the model's inference performance in the real environment, collect error samples, misjudged samples, or manually corrected samples, and use them for subsequent incremental training or model updates to ensure that the analysis system maintains high accuracy and robustness over a long period of time.

[0128] This application also provides an anomaly log analysis device. Figure 3The diagram shows an abnormal log analysis device 300 provided in an embodiment of this application. The abnormal log analysis device 300 may include a memory 310 and a processor 320.

[0129] Memory 310 is used to store computer programs.

[0130] Processor 320 is used to call and run computer programs stored in memory 310 to execute: the exception log analysis method provided in the above embodiments.

[0131] This application also provides a computer-readable storage medium for storing computer programs.

[0132] Optionally, the computer-readable storage medium can be applied to the method for generating test cases of the application in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0133] This application also provides a computer program product, including computer program instructions.

[0134] Optionally, the computer program product can be applied to the method for generating test cases for the application in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0135] This application also provides a computer program.

[0136] Optionally, the computer program can be applied to the method for generating test cases for the application in the embodiments of this application. When the computer program is run on a computer, it causes the computer to execute the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0137] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.

[0138] It should be understood that the specific examples in this document are only intended to help those skilled in the art better understand the embodiments of this application, and are not intended to limit the scope of the embodiments of this application.

[0139] It should also be understood that the various implementation methods described in this specification can be implemented individually or in combination, and the embodiments of this application are not limited in this respect.

[0140] Unless otherwise stated, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. Furthermore, the terms “first,” “second,” etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0141] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods 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 apparatuses or units may be electrical, mechanical, or other forms.

[0142] 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.

[0143] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0144] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0145] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An anomaly log analysis method, characterized in that, Applicable to Android devices, including: Obtain the log information set of the Android device, the log information set including multiple original log information, and perform format standardization processing on each original log information to obtain a first log set including multiple log information with uniform format; A second log set is obtained by filtering the first log set. The second log set does not include redundant log information in the first log set, and the second log set includes missing fields of the log information in the first log set. Each log message in the second log set is labeled with a category tag based on its content. Multiple log messages in the second log set are then categorized based on the category tags to obtain a third log set. The third log set is organized according to the time sequence information and category label of each log message in the third log set to generate multiple log message sequences, and the log messages in each log message sequence are arranged in chronological order; The multiple log information sequences are sent to a local server, the local server including a first model, and based on the multiple log information sequences and the first model, an abnormal log report corresponding to the Android device and a repair suggestion corresponding to the abnormal log report are obtained; The step of obtaining the abnormal log report corresponding to the Android device based on the plurality of log information sequences and the first model includes: Send the multiple log information sequences to the first model to obtain a high-dimensional feature vector that can characterize the root cause of the anomaly; Based on the high-dimensional feature vector, causal relationship analysis is performed to obtain the root cause analysis results; An anomaly correlation graph is constructed based on the root cause analysis results. The anomaly correlation graph is used to show the causal logical path between the anomaly log and the anomaly root cause. The anomaly log report is generated based on the anomaly correlation graph. The anomaly log report includes multiple anomaly log information from the multiple log information sequences that represent anomalies of the Android device and an anomaly root cause corresponding to each anomaly log information. The anomaly correlation graph uses the anomaly log information as nodes and establishes connections based on the causal dependencies between the anomaly log information. The repair suggestions correspond to each anomaly log information in the anomaly log report.

2. The method according to claim 1, characterized in that, The step of obtaining the second log set by filtering the first log set includes: Filter invalid log messages and perform deduplication on multiple duplicate log messages with the same content, retaining only one of the duplicate log messages; The invalid log information includes: debug information logs, heartbeat logs, keep-alive signal logs, blank lines, and noisy log data containing garbled characters.

3. The method according to claim 1, characterized in that, The log information includes timestamp, log level, log source, and log content; The timestamp is used to indicate the time when the log information occurred, the log level is used to indicate the importance and severity of the log information, the log source is used to indicate the source of the log information, and the log content is used to indicate the module operation information of the source corresponding to the log information; The missing fields of the log information in the first log set include at least one of the following: missing fields of the log content, missing timestamps, and missing log levels.

4. The method according to claim 1, characterized in that, The category labels include at least one of the following: log level label, log source label, and log anomaly mode label; The step of labeling each log message with a category tag based on the content of each log message in the second log set includes: identifying the category information in each log message according to a first rule and labeling the category tag, wherein the first rule includes multiple first log field information corresponding to the log level, multiple second log field information corresponding to the log source, and multiple third log field information corresponding to the log anomaly mode.

5. The method according to claim 4, characterized in that, The log level labels include at least one of: INFO, WARNING, ERROR, and FATAL; The log source tags include at least one of: application logs, system logs, and kernel logs; The log exception mode labels include at least one of the following: crash log, ANR log, and memory leak log.

6. The method according to claim 4, characterized in that, The step of organizing the third log set according to the time sequence information and category label of each log message in the third log set includes: Based on the timestamp of each log message in the third log set, the multiple log messages in the third log set are sorted and arranged in chronological order according to the timestamps to obtain a first log message sequence in the third log set where each log message is arranged by time. Based on the log source tag of each log message in the first log message sequence, multiple second log message sequences are generated, wherein the log source tags of the log messages in each second log message sequence are the same and arranged in chronological order; The plurality of log information sequences are generated based on the log anomaly pattern label of each log information in each of the second log information sequences, wherein the log anomaly pattern labels of the log information in each log information sequence are the same and arranged in chronological order.

7. The method according to claim 1, characterized in that, The step of obtaining repair suggestions corresponding to the abnormal log report based on the multiple log information sequences and the first model includes: The repair suggestions corresponding to the anomaly log report are obtained based on the second rule, the preset knowledge base, and the anomaly log report. The second rule includes the type information of the anomaly log and the triggering factor information corresponding to the anomaly log. The knowledge base includes fault information of the Android device and corresponding repair solutions.

8. The method according to claim 1, characterized in that, Based on the anomaly log report and the remediation suggestions, an anomaly information analysis report is generated, which includes at least one of the occurrence frequency of each anomaly pattern, the distribution of the anomaly pattern, and the occurrence trend of the anomaly pattern. An alarm is issued based on the third rule and the anomaly information analysis report. The third rule includes frequency information of the anomaly pattern, which is used to filter anomaly log information whose occurrence frequency exceeds a threshold.

9. An anomaly log analysis device, characterized in that, The anomaly log analysis device includes a processor and a memory, wherein the memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute the anomaly log analysis method as described in any one of claims 1-8.

Images