Log management method and system, electronic equipment and storage medium
By obtaining and filtering problem identification files from local terminals and generating bills of lading content in combination with code base and external network information, the problems of incomplete logs and lack of standardized information in traditional log management are solved, the accuracy and efficiency of bug resolution are improved, and the system maintainability is enhanced.
Patent Information
- Application Number
- CN202411568874.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-05
- Publication Date
- 2025-03-21
AI Technical Summary
Traditional log management has problems such as incomplete logs, lack of standardized information and inconsistent formats, which leads to inefficiency in positioning and solving bugs, and interacting multiple times, reducing repair efficiency.
By obtaining the problem identification files generated by the local terminal, filtering and building a bill of lading problem set, searching the code base and external network to obtain relevant error information, and additional processing is carried out for specific types of problems, and finally generating and feedback the integrated bill of lading content.
Improve the accuracy and efficiency of bug resolution, and through the comprehensive utilization of multi-source data and the filtering and deduplication of information, the workload and bug resolution time are reduced, while enhancing the maintainability of the system.
Smart Images

Figure CN119668908A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a log management method, system, electronic device and storage medium. Background Art
[0002] Smart terminal devices are developing in an intelligent and diversified way, with rich applications and diverse customer needs. Rapid iteration of software and hardware has resulted in many bugs (program errors). In the traditional bug repair process, logs are crucial, including version release, test log capture, development location solution, test verification and other links. If there is a problem with the log, it needs to be re-operated and cycled until the problem is solved.
[0003] The problems with log management include: log integrity, which is prone to human error and incompleteness, lack of information and format specifications, different testers have different operations, and developers have difficulty interpreting. Developers rely on logs to locate and solve problems. Incomplete logs or lack of key information will hinder the progress of repairs, extend the cycle, and cause multiple interactions between the two parties, reducing the efficiency of repairs. Summary of the invention
[0004] The present application provides a log management method, system, electronic device and storage medium, the purpose of which is to efficiently solve bug problems.
[0005] In a first aspect, the present application provides a log management method, the log management method comprising:
[0006] Obtain the problem identification file generated by the local terminal;
[0007] Perform filtering operations on the obtained problem identification files to select the problems that require bills of lading to construct a bill of lading problem set;
[0008] Search for error modification content related to the bill of lading problem set in the preset code library and organize it into an error ticket; search for error information related to the bill of lading problem set on the external network and organize the valid information therein; perform additional processing on specific types of problems, and integrate the processing results with the error ticket and valid information to generate bill of lading content;
[0009] Feedback the integrated bill of lading content to the local terminal.
[0010] In a second aspect, the present application further provides a log management system, the log management system comprising:
[0011] An acquisition module is used to acquire a problem identification file generated by a local terminal;
[0012] The question module is used to perform filtering operations on the obtained question identification files, filter out the questions that need bill of lading, and build a bill of lading question set;
[0013] The bill of lading module is used to search for error correction content related to the bill of lading problem set in the preset code library and organize it into an error ticket; search for error information related to the bill of lading problem set in the external network and organize the valid information therein; perform additional processing on specific types of problems, and integrate the processing results with the error ticket and valid information to generate the bill of lading content;
[0014] The feedback module is used to feed back the integrated bill of lading content to the local terminal.
[0015] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, the steps of the log management method as described in any one of the first aspects are implemented.
[0016] In a fourth aspect, the present application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the steps of the log management method as described in any one of the first aspects are implemented.
[0017] The present application provides a log management method, system, electronic device and storage medium, which are intended to efficiently solve bug problems. The method first obtains a problem identification file from a local terminal. Next, the obtained problem identification file is filtered to construct a bill of lading problem set, screen out key issues, and avoid being disturbed by irrelevant information during subsequent analysis. Then, the preset code library is searched for error modification content related to the bill of lading problem set and organized into error tickets. At the same time, the external network is searched for related error information and the valid information therein is sorted out. Additional processing is performed for specific types of problems, and these results are integrated to generate the bill of lading content. Finally, the integrated bill of lading content is fed back to the local terminal to complete the entire bug solving process.
[0018] Therefore, the advantages of the present application in solving bugs include: in terms of improving accuracy, the comprehensive use of multi-source data, such as code base and external network information, can verify each other and avoid misjudgment, and the processing of specific problems can deeply explore the root causes; in terms of improving efficiency, filtering irrelevant information reduces workload, and multi-channel parallel processing tasks, such as simultaneous code base search, external network information acquisition and specific problem processing, can shorten the time to solve bugs; in terms of enhancing maintainability, the log management system is responsible for the entire bug handling process, which is conducive to subsequent system maintenance and optimization. BRIEF DESCRIPTION OF THE DRAWINGS
[0019] In order to more clearly illustrate the technical solutions in the present application or the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0020] Figure 1 It is a flow chart of the log management method provided by this application;
[0021] Figure 2 It is a structural block diagram of the log management system provided by this application;
[0022] Figure 3 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0023] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0024] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein.
[0025] The log management method provided in this application obtains the problem identification file from the local terminal through the log management system, filters and constructs the bill of lading problem set, searches the code base and external network to obtain error information, and processes specific problems, generates the bill of lading content and returns it to the local terminal. This method aims to efficiently solve bug problems, has a bill of lading function, can improve analysis accuracy and processing efficiency, and enhance system maintainability. This log management method is suitable for Android terminal products such as in-vehicle smart cockpits, learning machines, and smart screens, providing stable and efficient log management and bug solving support for these devices.
[0026] Combine the following Figure 1-Figure 3 The present application describes a log management method, system, electronic device and storage medium.
[0027] Please refer to Figure 1 , Figure 1A log management method, applied to a log management system, includes:
[0028] S110, obtaining a problem identification file generated by a local terminal.
[0029] Specifically, the log management system will obtain the problem identification file generated by the local terminal device (such as a mobile phone, tablet computer, etc.) from the local terminal device. The problem identification file contains various problem identification information encountered during the operation of the system. By obtaining the problem identification file, the log management system can collect data about the bugs existing on the device, providing a basis for subsequent problem analysis and resolution.
[0030] Exemplarily, the problem identification file includes one or more log types such as system log, kernel log, event log, exception log and specific type log; wherein the file name of the problem identification file includes the number of boot times, log type, time and version information, etc.
[0031] For example, exception logs include anr (application not responding) files and tombstone files (files used to record process crash information in the Android system), which help to discover abnormal situations in program operation. In addition, specific types of logs, such as CPU, memory, and IO (input / output) operation logs in performance testing, are used to evaluate system performance. The bootchart (a tool for analyzing the performance of the system startup process) log for boot optimization can assist in analyzing the optimization of the boot process. The Bluetooth log is for records related to the Bluetooth function. In order to facilitate developers to accurately locate problems, the problem identification file can use a file name such as "10_2024091911_0245017_anr_v1.1.zip", "10" indicates the number of boots, "2024091911_0245017" indicates time, "anr" indicates log type, and "v1.1" indicates version information. In this way, developers can quickly lock relevant logs and troubleshoot problems based on this information.
[0032] Exemplarily, step S110 includes:
[0033] S111, monitoring problems through the log management system. When a problem is detected, determining the time period in which the problem occurred and collecting log records, specifically including:
[0034] (1) Collecting exception logs, which are used to record exception information at the time when the problem occurs.
[0035] When a tombstone file is generated, the system will specifically collect exception logs. The exception log contains the exception information at the time the problem occurred, and records the direct relevant information of the problem at that time, such as error type, error code, etc., which helps to quickly locate the root cause of the problem.
[0036] (2) Collect kernel logs within a preset time interval before and after the problem occurs, where the kernel logs are used to record kernel-level events related to the problem.
[0037] For example, by collecting kernel logs within 1 minute before and after a problem occurs, you can obtain kernel-level operation and event information related to the problem. The kernel's allocation of hardware resources and process scheduling during this time period are very important for analyzing whether the problem is related to kernel operations.
[0038] (3) Collect event logs within a preset time interval before and after the problem occurs. The event logs are used to record relevant information of various events in the system.
[0039] By collecting event logs within a preset time before and after the problem occurs, you can understand the events that occurred in each component, application or service in the system during this time period. For example, the start or stop of a service, or the specific operation of an application, etc. This helps to analyze the possible influencing factors of the problem from the perspective of the overall system events.
[0040] (4) Collecting system logs within a preset time interval before and after the problem occurs, wherein the system logs are used to record the overall operating status information of the system.
[0041] By collecting system logs within a preset time before and after the problem occurs, you can get the overall operation status of the system during this time period, such as the usage of system resources (CPU, memory, etc.), system load, etc. This information can help determine whether the problem is caused by the poor overall operation of the system.
[0042] (5) Collect specific type logs related to the problem type, where the specific type logs can provide supplementary information for the specific problem.
[0043] Different types of problems require different supplementary information for analysis. For example, if it is a performance problem, you need to collect CPU, memory, IO and other information included in the performance test; if it is a file leakage problem, you need to collect file-related information, etc. Targeted collection of specific types of logs based on the type of problem can provide more comprehensive and targeted information for problem analysis.
[0044] S112, integrating all collected logs to generate a problem identification file.
[0045] After completing the collection of various logs, the log management system integrates all previously collected logs to generate a problem identification file. The problem identification file is an information package about the problem, which contains all information from abnormal logs to various related kernel, event, system logs and specific types of logs, so as to facilitate the subsequent unified analysis, processing and management of the problem.
[0046] S120, performing a filtering operation on the obtained problem identification file to filter out the problems that require bills of lading to construct a bill of lading problem set.
[0047] Since the problem identification file contains a large amount of various information, some of which may be irrelevant to the key problem to be solved, the log management system needs to perform filtering operations to select those problems that really need to submit a problem ticket (i.e., bill of lading) from the large amount of information, and then combine the screened problems together to build a special set, i.e., bill of lading problem set.
[0048] Exemplarily, step S120 includes:
[0049] S121, comparing the log information in the problem identification file with the log information of the previously filed documents in the log management system.
[0050] Specifically, the log information contained in the newly generated problem identification file, such as the time when the error occurred, the error type, and the related system status, should be comprehensively compared with the log information involved in the problem ticket (i.e., bill of lading) that has been submitted to the log management system before.
[0051] For example, the log information of the submitted application records the crash of an application due to memory leak in a specific version, including the memory usage at the time of the crash, related function calls, and other information. If the log information in the new problem identification file also has similar information about the crash of this application, it can be found through this comparison. This comparison helps to determine whether the new problem has been encountered and handled before, or whether it is related to the previous problem.
[0052] S122, filtering existing identical errors by analyzing the error type, error triggering condition, and related context information reflected in the log information within the problem identification file.
[0053] Specifically, the error types, error triggering conditions, and related context information reflected in the log information in the problem identification file are analyzed in order to filter out the same errors that exist. The error types are clear error types such as null pointer exceptions and array out-of-bounds errors; the error triggering conditions are triggered only under specific input values and specific system states (such as high CPU load); the context information includes the code logic around the error, other running processes, etc. For example, if there are multiple log records in the problem identification file that show the same error caused by the same null pointer, after analyzing the types of these errors, the triggering conditions (all triggered when accessing the same uninitialized pointer) and the context (all under a specific calling order of a function), only one of the most representative records can be retained, thereby filtering out other identical error records. This simplifies the problem set and improves the accuracy of the analysis.
[0054] S123, the log information obtained after filtering is determined as the screened problems that need bills of lading, and a bill of lading problem set is constructed according to a predetermined format and rules.
[0055] Specifically, the log information obtained after filtering in step S122 is determined as the screened problems that need bills of lading. Then, a bill of lading problem set is constructed according to the predetermined format and rules. The predetermined format specifies the description method of the problem, the order of error information, etc., and the rules involve how to classify and combine different types of problems. For example, the predetermined format requires describing the error type first, then explaining the error triggering conditions, and finally providing relevant context information. According to such requirements, the screened problems are constructed into a bill of lading problem set, which is convenient for developers to view and solve problems according to unified standards.
[0056] S130, search for error modification content related to the bill of lading problem set in the preset code library, and organize it into an error ticket; search for error information related to the bill of lading problem set in the external network and organize the valid information therein; perform additional processing on specific types of problems, and integrate the processing results with the error ticket and valid information to generate the bill of lading content.
[0057] Exemplarily, in step S130, the log management system searches for error modification content related to the bill of lading problem set in a preset code base and organizes it into an error ticket, including:
[0058] S131, for each problem in the bill of lading problem set, search for the error modification content related to it in the code library according to the key features of the problem; wherein the key features of the problem include the error type, the module involved and the function name.
[0059] Specifically, the processing module in the cloud starts searching for each problem in the bill of lading problem set. The search is performed in the code base to find out whether there are bug fixes related to these problems. The search is based on the key features of the problem, which include the error type (such as data overflow, null pointer reference, etc.), the modules involved (such as network communication module, image processing module, etc.), and the function name (specific function, because the problem may be closely related to the code inside a function). Through these key features, the bug modification records for the problem in the code base can be accurately located.
[0060] For example, if one of the problems in the bill of lading problem set is that there is an error in the "sendData" function in the network communication module that fails to send data, then based on the key features of "network communication module", "sendData function" and "data sending failure", we will search in the code library to see whether there are modification records or related solutions for this type of problem.
[0061] S132, sorting the error modification contents related to the bill of lading problem set searched from the code library into the error ticket according to a preset format and logic.
[0062] Specifically, the processing module in the cloud organizes the bug modification contents related to the bill of lading problem set that are searched from the code base. Then, these contents are organized into bug tickets according to the preset format and logic. This operation is to provide a reference for developers. The preset format specifies how to describe the bug modification contents, such as listing the original bug first, then explaining the specific code lines that have been modified, the modified code content, etc. The logic aspect involves organizing according to the severity of the problem or by module, etc.
[0063] For example, the preset format requires that for each bug modification in the bug ticket, first give an overall description of the problem (including the error type, the module involved, and the function name), then list in detail the original bug code snippet found in the code base, then explain the modification ideas and the specific modified code lines, and finally give the modified code snippet. According to this format and logic, the searched bug modification content is organized into the bug ticket to help developers better understand the problem.
[0064] Exemplarily, in step S130, searching the external network for error information related to the bill of lading problem set and sorting out the valid information therein includes:
[0065] S133, in the external network, construct a search query statement using the problem key information including the error description and the relevant technical keywords to search for error information related to the bill of lading problem set.
[0066] Specifically, the log management system will extract key information from the bill of lading problem set to construct this query statement. Key information includes error descriptions and relevant technical keywords. The error description can clearly explain the phenomenon and manifestation of the problem, such as the specific error prompt when the program crashes or the specific situation of functional abnormality. Relevant technical keywords are technical terms closely related to the problem, such as specific programming languages, framework names, algorithms involved, or specific system components. By combining these error descriptions and relevant technical keywords, a search query statement is constructed, and then this query statement is used to search in the external network. The purpose is to find error information related to the bill of lading problem set and provide more reference materials for subsequent problem solving.
[0067] S134, filtering and sorting the error information obtained from the external network to extract effective information for solving the problem.
[0068] Specifically, since the information sources of the external network are extensive and complex, the error information obtained by searching may contain content that is irrelevant to solving the current problem. Therefore, it is necessary to filter and organize the error information obtained. The purpose of filtering is to remove irrelevant, redundant or inaccurate information, and only retain information that is helpful in solving the problem; the purpose of organizing is to further optimize the filtered information, such as sorting or classifying it according to the reliability of the information, the degree of relevance to the problem, etc. Then, effective information for solving the problem is extracted from the filtered and organized information. The effective information will be combined with information from other sources (such as relevant bug modification content in the code library) to provide developers with more comprehensive and effective support for solving the problems in the bill of lading problem set, thereby improving the efficiency of problem solving.
[0069] Exemplarily, in S130, performing additional processing on a specific type of problem includes:
[0070] S135, classifying the problems in the bill of lading problem set to identify specific types of problems, where the specific types of problems include crash problems and deadlock problems during program runtime.
[0071] Specifically, by classifying the problems in the bill of lading problem set, we can distinguish problems of different natures so that we can handle specific types of problems later. For example, in a bill of lading problem set that contains multiple error types, such as network connection errors and data processing errors, we can single out the problems that are caused by program crashes or deadlocks during runtime, laying the foundation for further precise processing.
[0072] S136, if a crash problem during program execution is identified, a corresponding library file is obtained from a designated library storage location, and the specific location of the problem in the code is determined by analyzing call stack information of the library file and combining an address conversion tool.
[0073] Specifically, when it is determined that the crash problem occurs during program operation, the corresponding library file is obtained from the specified library storage location. The library file contains important information related to program operation. Then, by deeply analyzing the call stack information of the library file, which records key information such as the order of function calls, combined with address conversion tools (such as the add2line tool), the specific location of the problem in the code can be determined. This provides developers with accurate positioning information to solve crash problems.
[0074] S137, if a deadlock problem is identified, a link is constructed when the deadlock occurs by analyzing the system's resource allocation, thread status, and lock acquisition and release information. The link can show the specific resource occupation by a specific thread and the specific logical relationship that forms a deadlock loop.
[0075] Specifically, when a deadlock problem is determined, it is necessary to analyze the system's resource allocation to understand which resources are allocated to where; analyze the thread status to clarify whether each thread is in a running, waiting, or blocked state; analyze the lock acquisition and release information to understand which threads acquire which locks and when they are released. Through a comprehensive analysis of this information, a link is constructed when the deadlock occurs. The link can clearly show the situation in which specific resources are occupied by specific threads, as well as the specific logical relationship that forms a deadlock loop.
[0076] For example, it can show that thread A has obtained resource X and is waiting for resource Y, while thread B has obtained resource Y and is waiting for resource X, thus forming a deadlock loop. Developers can intuitively understand the deadlock formation mechanism through this link, thereby solving the deadlock problem more effectively.
[0077] S140, feeding back the integrated bill of lading content to the local terminal.
[0078] Specifically, the integrated bill of lading content includes a variety of information, such as the problem log compression package (whose file name contains important identifiers such as the number of boot times, problem type, time version information, etc.), full log (a log that fully records the system operation status), modifications to similar bugs in the code base (which can provide references for solving current bugs), relevant bug information collated from the external network (information obtained and collated from the external network that helps solve problems), additional processing reports of cloud processing modules (result reports after additional processing for specific types of problems), and other relevant information. Then, the log management system feeds back the integrated bill of lading content to the local terminal, which can be a device used by developers, etc., so that the local terminal can obtain complete bill of lading information so that developers can further analyze and solve bugs based on this information.
[0079] In some embodiments, the log management method further includes:
[0080] S150, receiving an update operation performed by a local terminal on configuration information, log tools, and scripts, and obtaining updated log information through the update operation.
[0081] Specifically, when developers find that the existing logs are insufficient or other relevant materials are insufficient during the process of dealing with bugs, they will update the configuration information, log tools, scripts, etc. The log management system is responsible for receiving the update operations performed by the local terminal on these aspects. Through the update operation, the log management system can obtain the updated log information. For example, if the developer finds that the original log does not record the operating status of a key module, by updating the configuration information of the log tool, the log management system can obtain new log information containing the operating status of the key module, thereby providing more comprehensive information for subsequent problem handling.
[0082] S160, updating the fixed troubleshooting information of the local terminal to the cloud.
[0083] Specifically, in the process of developers handling bugs, they will summarize some fixed troubleshooting methods for some problems. These fixed troubleshooting methods are the experience accumulated by developers in the process of solving problems. Then, the fixed troubleshooting information of the local terminal is updated to the cloud through the log management system. In this way, the processing module in the cloud can obtain this information and use this fixed troubleshooting information in subsequent pre-processing. For example, for a certain type of deadlock problem, the developers have summarized a set of fixed troubleshooting steps, through which the problem can be quickly located. After updating the fixed troubleshooting information to the cloud, when encountering similar deadlock problems in the future, the processing module in the cloud can use this information for pre-processing to improve the efficiency of handling such problems.
[0084] In summary, in the traditional bug bill repair solution, developers have a strong dependence on logs when solving problems. Factors such as the content and size of the logs affect whether the problem can be solved smoothly. Once the log is incomplete or lacks key content, the progress of bug repair will be seriously affected. This application is committed to solving these problems. First, the information and format of the log are standardized, and the log is fully automatically captured to ensure the integrity of the log. Secondly, the log system is intelligent. When a specific problem is found, such as anr problems, additional information such as data related to the performance of the entire machine can be captured synchronously. Finally, the log system also has a filtering and deduplication function. It can give modification suggestions for simple problems, perform pre-analysis of the problems, and complete some of the analysis work that was originally required to be performed by developers in advance. At the same time, it has a bill of lading function (that is, in the bug handling process, relevant information from multiple sources including code bases, external networks, logs, etc. can be integrated to form a bill of lading), which helps developers solve bugs more quickly.
[0085] The log management system provided by the present application is described below. The log management system described below and the log management method described above can be referenced to each other.
[0086] Please refer to Figure 2 , Figure 2 A log management system 200 includes an acquisition module 201 , a question module 202 , a bill of lading module 203 and a feedback module 204 .
[0087] Exemplarily, the acquisition module 201 is used to acquire a problem identification file generated by a local terminal.
[0088] Exemplarily, the question module 202 is used to perform a filtering operation on the acquired question identification file, and filter out the questions that require bills of lading to construct a bill of lading question set.
[0089] Exemplarily, the bill of lading module 203 is used to search for error modification content related to the bill of lading problem set in a preset code library, and organize it into an error ticket; search for error information related to the bill of lading problem set on an external network and organize the valid information therein; perform additional processing on specific types of problems, and integrate the processing results with the error ticket and valid information to generate the bill of lading content.
[0090] Exemplarily, the feedback module 204 is used to feed back the bill of lading content to the local terminal.
[0091] Exemplarily, the acquisition module 201 is further used for:
[0092] Problem monitoring is performed through the log management system. When a problem is detected, the time period in which the problem occurred is determined and log records are collected, including:
[0093] Collecting exception logs, where the exception logs are used to record the exception information at the time when the problem occurs;
[0094] Collect kernel logs within a preset time interval before and after the problem occurs, wherein the kernel logs are used to record kernel-level events related to the problem;
[0095] Collect event logs within a preset time interval before and after the problem occurs, and the event logs are used to record relevant information of various events in the system;
[0096] Collect system logs within a preset time interval before and after the problem occurs, and the system logs are used to record the overall operating status information of the system;
[0097] Collecting logs of a specific type related to the problem type, where the logs of the specific type can provide supplementary information for the specific problem;
[0098] All collected logs are integrated to generate the problem identification file.
[0099] Exemplarily, the question module 202 is further used to:
[0100] Compare the log information in the problem identification file with the log information of the previous bill in the log management system;
[0101] Within the problem identification file, by analyzing the error type, error triggering condition and related context information reflected in the log information, the existing identical errors are filtered;
[0102] The log information obtained after filtering is determined as the screened out problems requiring bill of lading, and the bill of lading problem set is constructed according to a predetermined format and rules.
[0103] Exemplarily, the bill of lading module 203 is also used for:
[0104] For each problem in the bill of lading problem set, searching for error modification content related thereto in the code base according to key features of the problem; wherein the key features of the problem include error type, involved modules and function names;
[0105] The error modification contents related to the bill of lading problem set searched from the code library are sorted into the error ticket according to a preset format and logic.
[0106] Exemplarily, the bill of lading module 203 is also used for:
[0107] In the external network, a search query statement is constructed using the problem key information including the error description and relevant technical keywords to search for error information related to the bill of lading problem set;
[0108] Filter and organize the error information obtained from the external network to extract effective information for solving the problem.
[0109] Exemplarily, the bill of lading module 203 is also used for:
[0110] Classifying the problems in the bill of lading problem set to identify the specific type of problems, wherein the specific type of problems includes crash problems and deadlock problems during program runtime;
[0111] If a crash problem is identified during program runtime, the corresponding library file is obtained from the specified library storage location, and the specific location of the problem in the code is determined by analyzing the call stack information of the library file and combining with the address conversion tool;
[0112] If a deadlock problem is identified, the link when the deadlock occurs is constructed by analyzing the system's resource allocation, thread status, and lock acquisition and release information. This link can show the specific logical relationship in which specific resources are occupied by specific threads and the deadlock loop.
[0113] Exemplarily, the log management method further includes:
[0114] Receiving an update operation performed by a local terminal on configuration information, a log tool, or a script, and obtaining updated log information through the update operation; and / or
[0115] Update the fixed troubleshooting information of the local terminal to the cloud.
[0116] It should be noted here that the above-mentioned log management system provided in the embodiment of the present application can implement all the method steps implemented in the above-mentioned method embodiment, and can achieve the same technical effect. The parts and beneficial effects that are the same as those in the method embodiment will not be described in detail here.
[0117] Please refer to Figure 3 , Figure 3 : is a structural diagram of an electronic device provided in an embodiment of the present application. The electronic device includes: a processor (Processor) 310, a communication interface (Communications Interface) 320, a memory (Memory) 330 and a communication bus 340, wherein the processor 310, the communication interface 320, and the memory 330 communicate with each other through the communication bus 340. The processor 310 can call the logic instructions in the memory 330 to execute the log management method.
[0118] In addition, the logic instructions in the above-mentioned memory 330 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art, and the computer software product is stored in a storage medium, including several instructions to ensure that a computer device (which can be a personal computer, a server, or a network device, etc.) executes all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk.
[0119] On the other hand, the present application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the log management method provided by the above methods.
[0120] On the other hand, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which is implemented when the computer program is executed by a processor to execute the log management method provided above.
[0121] The embodiments of the present application provide an electronic device, a computer program product, and a processor-readable storage medium, on which the computer program stored enables the processor to implement all the method steps implemented in the above-mentioned method embodiments and to achieve the same technical effects. The parts and beneficial effects of this embodiment that are the same as those in the method embodiments will not be described in detail herein.
[0122] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.
[0123] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions to ensure that a computer device (which can be a personal computer, a server, or a network device, etc.) executes the methods described in each embodiment or some parts of the embodiments.
[0124] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A log management method, characterized in that: The log management method comprises: Obtain the problem identification file generated by the local terminal; Perform filtering operations on the obtained problem identification files to select the problems that require bills of lading to construct a bill of lading problem set; Searching for error modification content related to the bill of lading problem set in a preset code library and organizing it into an error ticket; searching for error information related to the bill of lading problem set on an external network and organizing the valid information therein; performing additional processing on specific types of problems, and integrating the processing results with the error ticket and the valid information to generate bill of lading content; Feedback the integrated bill of lading content to the local terminal.
2. The log management method according to claim 1, characterized in that: The obtaining of the problem identification file generated by the local terminal includes: Use the log management system to monitor problems. When a problem is detected, determine the time period in which the problem occurred and collect log records, including: Collecting exception logs, where the exception logs are used to record the exception information at the time when the problem occurs; Collect kernel logs within a preset time interval before and after the problem occurs, wherein the kernel logs are used to record kernel-level events related to the problem; Collect event logs within a preset time interval before and after the problem occurs, and the event logs are used to record relevant information of various events in the system; Collect system logs within a preset time interval before and after the problem occurs, and the system logs are used to record the overall operating status information of the system; Collecting logs of a specific type related to the problem type, where the logs of the specific type can provide supplementary information for the specific problem; All collected logs are integrated to generate the problem identification file.
3. The log management method according to claim 1, characterized in that: The filtering operation performed on the obtained problem identification file to filter out the problems requiring bill of lading to construct the bill of lading problem set includes: Compare the log information in the problem identification file with the log information of the previous bill in the log management system; Within the problem identification file, by analyzing the error type, error triggering condition and related context information reflected in the log information, the existing identical errors are filtered; The log information obtained after filtering is determined as the screened out problems requiring bill of lading, and the bill of lading problem set is constructed according to a predetermined format and rules.
4. The log management method according to claim 1, characterized in that: The searching for error modification contents related to the bill of lading problem set in the preset code base and arranging them into error tickets includes: For each problem in the bill of lading problem set, searching for error modification content related thereto in the code base according to key features of the problem; wherein the key features of the problem include error type, involved modules and function names; The error modification contents related to the bill of lading problem set searched from the code library are sorted into the error ticket according to a preset format and logic.
5. The log management method according to claim 1, characterized in that: The searching of the external network for error information related to the bill of lading problem set and sorting out the valid information therein includes: In the external network, a search query statement is constructed using the problem key information including the error description and relevant technical keywords to search for error information related to the bill of lading problem set; Filter and organize the error information obtained from the external network to extract effective information for solving the problem.
6. The log management method according to claim 1, characterized in that: The additional processing for specific types of problems includes: Classifying the problems in the bill of lading problem set to identify the specific type of problems, wherein the specific type of problems includes crash problems and deadlock problems during program runtime; If a crash problem is identified during program runtime, the corresponding library file is obtained from the specified library storage location, and the specific location of the problem in the code is determined by analyzing the call stack information of the library file and combining with the address conversion tool; If a deadlock problem is identified, the link when the deadlock occurs is constructed by analyzing the system's resource allocation, thread status, and lock acquisition and release information. This link can show the specific logical relationship in which specific resources are occupied by specific threads and the deadlock loop.
7. The log management method according to claim 1, characterized in that: The log management method further includes: Receiving an update operation performed by a local terminal on configuration information, a log tool, or a script, and obtaining updated log information through the update operation; and / or Update the fixed troubleshooting information of the local terminal to the cloud.
8. A log management system, characterized in that: The log management system comprises: An acquisition module is used to acquire a problem identification file generated by a local terminal; The question module is used to perform filtering operations on the obtained question identification files, filter out the questions that need bill of lading, and build a bill of lading question set; The bill of lading module is used to search for error correction content related to the bill of lading problem set in the preset code library and organize it into an error ticket; search for error information related to the bill of lading problem set in the external network and organize the valid information therein; perform additional processing on specific types of problems, and integrate the processing results with the error ticket and valid information to generate the bill of lading content; The feedback module is used to feed back the integrated bill of lading content to the local terminal.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, the steps of the log management method according to any one of claims 1 to 6 are implemented.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the log management method according to any one of claims 1 to 6 are implemented.