Application fault monitoring method and related device

Abstract

The invention provides an application fault monitoring method and a related device, and relates to the technical field of application. The application fault monitoring method can comprise the steps of obtaining at least one log file; the at least one log file is generated in the running process of a target vehicle-mounted application and is uploaded to the server by at least one vehicle; based on an application fault matching rule, determining log information related to an application fault of a target vehicle-mounted application in the at least one log file; respectively generating corresponding summary information for different application faults based on the target information; the target information comprises log information related to an application fault of the target vehicle-mounted application; sending the summary information to a target receiver; the summary information is used for the target receiver to carry out application fault monitoring on the target vehicle-mounted application according to the summary information. According to the technical scheme provided by the invention, the effect of an application fault positioning mode in the prior art can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of application failure analysis, and in particular to a method for monitoring application failures and related devices. Background Art

[0002] During the operation of an application, its reliability and stability are crucial. For example, for a vehicle, the operation of an application may affect the normal driving of the vehicle and the user's riding experience. However, some failures are inevitable during the operation of the application.

[0003] In the prior art, application developers can only find log files of the corresponding period according to the fault time (eg, timestamp) and manually analyze the log files to determine the application fault. This fault location method is time-consuming and labor-intensive. Summary of the invention

[0004] Based on the above-mentioned defects and shortcomings of the prior art, the present application proposes a monitoring method and related devices for application faults, which can solve the problem that the prior art method for locating application faults is time-consuming and labor-intensive.

[0005] According to a first aspect of an embodiment of the present application, a method for monitoring application failures is provided, which is applied to a server, and the method includes:

[0006] Obtain at least one log file; the at least one log file is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle;

[0007] Based on the application fault matching rule, determining, in the at least one log file, log information related to the application fault of the target in-vehicle application;

[0008] Based on the target information, corresponding summary information is generated for different application failures respectively; the target information includes: log information related to the application failure of the target vehicle application;

[0009] The summary information is sent to a target recipient; the summary information is used by the target recipient to perform application fault monitoring on the target vehicle-mounted application according to the summary information.

[0010] According to a second aspect of an embodiment of the present application, a monitoring device for application failure is provided, which is applied to a server and includes:

[0011] An acquisition module, used to acquire at least one log file; the at least one log file is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle;

[0012] A first determination module, configured to determine, in the at least one log file, log information related to the application failure of the target in-vehicle application based on an application failure matching rule;

[0013] An information generation module, for generating corresponding summary information for different application failures based on target information; the target information includes: log information related to the application failure of the target vehicle-mounted application;

[0014] The first sending module is used to send the summary information to a target recipient; the summary information is used by the target recipient to perform application fault monitoring on the target vehicle-mounted application according to the summary information.

[0015] According to a third aspect of an embodiment of the present application, there is provided a system for monitoring application failures, including a vehicle having a target vehicle-mounted application installed therein and a server;

[0016] The vehicle is used to send at least one log file generated during the operation of the target vehicle-mounted application to the server;

[0017] The server is used to execute the method for monitoring application failures as described in the first aspect.

[0018] According to a fourth aspect of the embodiments of the present application, there is provided an electronic device, including: a memory and a processor;

[0019] The memory is connected to the processor and is used to store programs;

[0020] The processor is used to implement the method for monitoring application failures as described in the first aspect by running the program in the memory.

[0021] According to a fifth aspect of an embodiment of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for monitoring application failures as described in the first aspect is implemented.

[0022] According to the sixth aspect of an embodiment of the present application, a computer program product or computer program is provided, wherein the computer program product includes a computer program, and the computer program is stored in a computer-readable storage medium; the processor of the computer device reads the computer program from the computer-readable storage medium, and when the processor executes the computer program, it implements the steps in the method for monitoring application failures as described in the first aspect.

[0023] In the technical solution provided by the present application, the log files generated by the vehicle-mounted application during operation will be uploaded to the server, and the server will parse the log files to determine whether there is log information related to the application failure in the log files. If it exists, corresponding summary information can be generated for different application failures based on the log information related to the application failure, and then the generated summary information is sent to the target recipient (such as the application developer, etc.) for relevant personnel (such as application developers) to monitor the application failure. Compared with the prior art, the application failure monitoring technology provided by the present application has a higher degree of automation, and there is no need for relevant personnel to manually search for log information related to the application failure from the log file according to the timestamp, which is conducive to improving the efficiency of locating application failures so as to repair the application failures in time. And some application failures may not be perceived and easily missed. Through the technical solution provided by the present application, relevant personnel can also promptly discover and repair such application failures. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 A closed-loop system for application fault monitoring provided in an embodiment of the present application;

[0025] Figure 2 A flowchart of a method for monitoring application failures provided in an embodiment of the present application;

[0026] Figure 3 A schematic diagram of log upload provided in an embodiment of the present application;

[0027] Figure 4 A schematic diagram of storing summary information provided in an embodiment of the present application;

[0028] Figure 5 A schematic diagram of the process of processing summary information provided in an embodiment of the present application;

[0029] Figure 6 A schematic diagram of an MTBF dashboard provided in an embodiment of the present application;

[0030] Figure 7 A block diagram of a monitoring device for application failure provided in an embodiment of the present application;

[0031] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0033] The technical solution provided by the present application relates to a closed-loop system for application fault monitoring, the closed-loop system comprising: a vehicle, a server and an application fault monitoring party. Figure 1 Take as an example to illustrate the closed-loop system.

[0034] In the closed-loop system, the log files generated by the vehicle-mounted applications installed on each vehicle 101 during operation can be uploaded to the server 102 in real time or at a scheduled time.

[0035] The server 102 can parse the log file sent by the vehicle 101 to determine whether the log file includes log information related to the application failure of the vehicle-mounted application. If so, it can generate corresponding summary information for different application failures based on the log information related to the application failure, and then transfer the generated summary information to the application failure monitoring party 103 (such as the application developer, etc.).

[0036] After receiving the summary information, the application fault monitoring party 103 can locate the application fault according to the summary information and repair the application fault. After the repair is completed, a new version of the application program is released.

[0037] The vehicle 101 obtains the new version of the application released by the application fault monitoring party 103, updates the application, and then continues to upload the log files generated during the operation of the updated application to the server 103, thereby starting a new round of application fault location and repair.

[0038] In this closed-loop system, the uploading of log files generated by the application by the vehicle, the parsing of the log files by the server, and the transfer of the summary information obtained by the parsing to the application fault monitoring party are all automated processes with high processing efficiency, which is conducive to timely detection and repair of faults. In addition, in the technical solution provided by the present application, after the application fault monitoring party repairs the application fault, it can release a new version of the application after a simple test or without testing, and transfer the specific test of the new version of the application to the actual use of the application. The vehicle and server monitor whether the application fault has been resolved, thereby realizing closed-loop processing of the application fault.

[0039] The technical solution provided in the embodiments of the present application is explained in detail below.

[0040] The present application embodiment provides a method for monitoring application failures, which is applied to a server (corresponding to the cloud). Figure 2 As shown, the method may include the following steps:

[0041] Step 201: Obtain at least one log file.

[0042] The at least one log file described here is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle.

[0043] First, the target vehicle-mounted application described here can be any vehicle-mounted application installed on the vehicle, such as a system application, a third-party application, a service program, etc.; secondly, each vehicle can upload the log file generated during the operation of the target vehicle-mounted application to the server in real time or at a fixed time. Thirdly, the at least one log file may include but is not limited to: system logs, log files managed by the application itself, core dump files generated when the program crashes (such as coredump files), application unresponsive tracking files (such as trace files), etc. For example, a vehicle is generally equipped with multiple domain controllers, and the software modules in each domain controller (such as third-party applications, system applications, service programs, etc.) will generate log information during operation and output it in the form of logs.

[0044] During the operation of the target vehicle-mounted application, if an abnormal event occurs (such as process crash, response timeout, etc.), at least one of the following information may be generated: crash information (such as coredump information, tombstone information), error information, landmark record information, ANR (Application not response) information, etc. These information may be recorded in log files in the form of logs. Therefore, log files are crucial for diagnosing and resolving application failures.

[0045] Optionally, the vehicle can record the name of each uploaded log file and the latest timestamp of the log information in the log file. Before uploading the log file next time, it can first determine whether a log file with the same name has been uploaded before. If not, the log file can be uploaded to the server; if it has been uploaded, the log information in it can be scanned according to the timestamp, the log information can be deduplicated, and the uploaded log information can be deleted to avoid repeated uploading of the same log information.

[0046] Optionally, in the embodiment of the present application, a log management service function may be added to the vehicle, through which the generated log files are managed, such as deduplication processing of log files, uploading processing of log files, etc. Figure 3 As shown, a log management service in a domain controller can upload log files to the server through the vehicle's networking module.

[0047] It should be noted that the specific contents of the log file can be pre-configured. For example, the generated log information can be set to include status information such as variables, stacks, registers, etc. during the application operation. When configuring, it should be considered that all kinds of application failures can be monitored and effective log files can be generated to ensure the accuracy and completeness of log information so as to timely discover and solve potential problems. For example, it is necessary to monitor the stability of system application services, mainly including abnormal crashes of service processes, etc. It is also necessary to monitor the stability of application services, mainly including enumerable business function anomalies, such as some errors when the voice function is abnormal.

[0048] Step 202: Based on the application fault matching rule, determine log information related to the application fault of the target vehicle-mounted application in the at least one log file.

[0049] In the embodiment of the present application, log information related to the application failure of the target vehicle application can be searched in each log file based on the application failure matching rule. For example, log information such as process name, system status information (such as CPU occupancy, memory usage, etc.) and cause can be extracted from the log file.

[0050] The application fault matching rules described herein may include, but are not limited to: at least one of a keyword matching rule and a pattern matching rule.

[0051] For the keyword matching rule, keywords in the log information related to the application failure may be collected in advance, and then used as the keyword matching rule to search the log file for log information that meets the keyword matching rule.

[0052] Among them, for pattern matching rules, some particularities of log information related to application failures can be analyzed in advance, and then pattern matching rules can be designed based on this. If a piece of log information meets the pattern matching rules, it can be screened out.

[0053] It should be noted that generally a complete piece of log information is used as the log information that meets the application fault matching rule.

[0054] Step 203: Based on the target information, corresponding summary information is generated for different application failures.

[0055] The target information mentioned here may include: log information related to the application failure of the target vehicle application, for example, it may include: the version of the target vehicle application, the name of the process where the application failure occurred, the time when the application failure occurred, the cause of the application failure, etc., so as to locate the defect.

[0056] In the embodiment of the present application, after obtaining the log information related to the application failure of the target vehicle-mounted application from the at least one log file, the log information can be analyzed to determine the type of the existing application failure, and then corresponding summary information can be generated for each application failure. The generated summary information at least includes the log information related to the corresponding application failure in the log information obtained according to step 202.

[0057] Among them, the log information included in the summary information corresponding to each application failure is obtained by analyzing all log files. For example, the number of the at least one log file is 4, and log information related to application failure A is found in 3 log files, then the summary information corresponding to application failure A includes at least the log information related to application failure A found in the aforementioned 3 log files.

[0058] Step 204: Send the generated summary information to the target recipient.

[0059] The target receiver may monitor the target vehicle-mounted application for application faults based on the summary information, that is, discover the application faults that occur in the target vehicle-mounted application, and then repair the application faults.

[0060] The target recipient mentioned here may specifically be a party that requires application fault monitoring, such as an application developer, an application maintainer, and the like.

[0061] It should be noted that the summary information is sent to the device corresponding to the target recipient, such as a terminal device.

[0062] The application failure monitoring method provided in the embodiment of the present application has a higher degree of automation, and does not require relevant personnel to manually search for log information related to the application failure from the log file according to the timestamp, which is conducive to improving the efficiency of locating the application failure so as to repair the application failure in time.

[0063] In addition, relevant personnel generally determine the time when the application failure occurs based on the reporting event of the application failure (such as the reporting event actively triggered by the user), and then search for log information related to the application failure in the log file based on the time to locate the application failure. However, some application failures are not perceived, which makes it difficult to report such application failures and causes omission of application failures. In the embodiment of the present application, the server searches for log information related to the application failure in the log file based on the application failure matching rule. The application failure matching rule is set based on the premise of fully understanding and analyzing the application failure, so that log information related to various application failures can be found, so that relevant personnel can promptly discover and repair different types of application failures, effectively solving the problem that probabilistic failures in complex software systems cannot be discovered and repaired in a timely manner.

[0064] In some embodiments, the target information in step 203 may also include: storage path information of the log file (also referred to as a log link), and accordingly, the generated summary information may also include the storage path information of the log file.

[0065] The corresponding log file can be obtained through the storage path information. When there is a need to view the log file, the corresponding log file can be linked through the storage path information, eliminating the operation of searching the log file based on the timestamp.

[0066] More specifically, both the target information and the summary information may further include: location information of the log information in the log file, so that relevant personnel can quickly locate the log information to be viewed in the log file.

[0067] In some embodiments, after receiving the log file sent by the vehicle, the server may first save the log file, and then regularly parse the newly added log file. The summary information obtained by the parsing may be stored in the problem database.

[0068] Optionally, a log service function may be set in the server, through which the log files are received and saved. In addition, a log parsing service function may also be set in the server, through which the log files are parsed. Figure 4 As shown, the log parsing service can access the log service by subscription or polling, and receive the log files sent by the log service through a message queue (MQ) or other network channels, then parse the log files, and finally store the summary information obtained by the analysis in the problem database.

[0069] In some embodiments, after the server generates the summary information and before sending the summary information to the target recipient, the method may further include:

[0070] Step A1: Determine, based on the first summary information and the historical summary information, whether there is an application failure similar to the first application failure in the historical application failures of the target vehicle-mounted application.

[0071] The first summary information mentioned here is any summary information generated based on the target information. For example, four summary information are generated based on the target information (each summary information can be understood as an information set), each summary information corresponds to an application failure, and the first summary information is any one of the four summary information.

[0072] The first application failure mentioned here is the application failure corresponding to the first summary information.

[0073] The historical summary information described here is summary information corresponding to historical application failures that occurred in the target vehicle-mounted application (which can also be understood as statistically analyzed historical application failures).

[0074] Step A2: when there is an application failure similar to the first application failure in the historical application failures, an association relationship between the first summary information and the similar application failure is established.

[0075] Step A3: if there is no application failure similar to the first application failure in the historical application failures, create a new application failure, and establish an association relationship between the first summary information and the new application failure.

[0076] Since summary information generated at different times may correspond to the same application failure, in order to facilitate the classification management of the summary information, after each summary information is generated, the newly generated summary information (corresponding to the first summary information) can be compared and analyzed with the summary information associated with the historical application failures of the application (corresponding to the target vehicle-mounted application) to determine whether there is an application failure in the historical application failures of the application that is similar to the application failure corresponding to the newly generated summary information (corresponding to the first application failure).

[0077] If there is a similar application failure, an association relationship between the newly generated summary information and the similar application failure can be established, that is, the newly generated summary information is saved under the similar application failure; if there is no similar application failure, a new application failure can be created, and then an association relationship between the newly generated summary information and the created new application failure is established, that is, the newly generated summary information is saved under the new application failure.

[0078] In an embodiment of the present application, the server may create an application fault identifier for different application faults, and establish an association relationship between the application fault identifier and the corresponding summary information, so as to manage the summary information. For example, in the absence of a similar application fault, a new application fault identifier may be created (i.e., a new application fault is created), and the first summary information may be saved under the newly created application fault identifier, i.e., an association relationship between the two may be established. Under each application fault identifier, in addition to the summary information, some statistical information may also be included, such as the number of application faults (or the frequency of application faults), etc. These statistical information may also be sent to the target recipient along with the summary information.

[0079] Optionally, it can be determined whether similar application failures exist based on the similarity between the summary information. For example, when the similarity is greater than or equal to a preset value, it is considered that similar application failures exist, and when there are multiple similar application failures, an association relationship can be established between the similar application failures with the greatest similarity; conversely, when the similarity is less than a preset value, it is considered that no similar application failures exist. The preset value can be set according to actual needs, and the embodiments of the present application do not specifically limit this.

[0080] Optionally, step A2 may include:

[0081] Step A21: When there is a failure similar to the first application failure in the historical application failures, determine whether the similar application failure is in a resolved state.

[0082] Step A22: When the similar application fault is in a resolved state, the similar application fault is set to an unresolved state, and an association relationship between the first summary information and the similar application fault is established.

[0083] Step A23: When the similar application failure is in an unresolved state, a correlation relationship between the first summary information and the similar application failure is directly established.

[0084] The status of the application faults that have been counted by the server may include: unresolved status and resolved status. When the application has not had the counted application faults for a preset number of consecutive versions, the application fault is set to resolved status, otherwise, the application fault is set to unresolved status.

[0085] For example, after saving the first application fault as a new application fault, the first application fault is set to an unresolved state. The server can monitor the version update of the target vehicle-mounted application, and when the first application fault does not occur for seven consecutive versions, the first application fault is set to a resolved state.

[0086] In the embodiment of the present application, when there is a fault similar to the first application fault in the historical application faults, it can be determined whether the similar application fault is in a resolved state.

[0087] If the similar application fault is in an unresolved state, the first summary information may be directly saved under the similar application fault.

[0088] If the similar application fault is in a resolved state, the state of the similar application fault needs to be updated to an unresolved state first, thereby indicating that the application fault needs to be repaired, and then the first summary information is saved under the similar application fault.

[0089] Optionally, in an embodiment of the present application, the server may further include a third-party software management system. When a new application failure needs to be created, it can be created through the third-party software management system. After the creation is completed, the corresponding information is saved to the problem database.

[0090] Optionally, after generating summary information, the server may first store it in a problem database, and then periodically obtain newly generated summary information from the problem database to check whether the application failures corresponding to the summary information are similar to unresolved historical application failures.

[0091] The following example illustrates the above content. After the log parsing service in the server generates summary information, it stores it in the problem database. After that, the server can execute Figure 5 As shown in the process. Figure 5 As shown, the process may include:

[0092] Step 501: The server periodically extracts new summary information from the question database, and then proceeds to step 502.

[0093] Step 502: Determine whether there is an application failure similar to application failure B in the historical application failures. If yes, proceed to step 503; if no, proceed to step 504.

[0094] The application fault B is the application fault corresponding to the summary information b, and the summary information b is any one of the extracted new summary information.

[0095] Step 503: Create a new application fault, and establish an association relationship between the summary information b and the new application fault.

[0096] Step 504: Determine whether similar application failures have been resolved. If yes, proceed to step 505; if no, proceed to step 506.

[0097] Step 505: Update the status of similar application failures, and establish an association relationship between the summary information b and the new application failure.

[0098] Step 506: directly establish an association relationship between the summary information b and the new application fault.

[0099] The embodiment of the present application can classify and manage summary information through similar algorithm rules to submit more effective application fault information to the target recipient.

[0100] In some embodiments, the server may periodically send all summary information of application failures for which the summary information has been updated within a period of time to the target recipient for the target recipient to view. Therefore, step 204: sending the summary information to the target recipient may include:

[0101] Step B1: Determine a second application failure of the target in-vehicle application.

[0102] The second application failure mentioned here includes: historical application failures with newly added summary information within a preset time period and / or newly created application failures. The preset time period mentioned here can be set according to actual needs, and the embodiment of the present application does not specifically limit this.

[0103] Step B2: Acquire second summary information associated with the second application failure.

[0104] Step B3: Send the second summary information to the target recipient.

[0105] The summary information generated in step 104 is included in the second summary information.

[0106] In the embodiment of the present application, by regularly sending relevant information about application failures that occurred in the target vehicle-mounted application within a period of time to the target recipient, it is helpful for the target recipient to centrally determine and repair the application failures.

[0107] In some embodiments, the method may further include:

[0108] Step C1: Determine a third application failure of the target in-vehicle application.

[0109] The third application failure mentioned here may include: historical application failures and newly created application failures, that is, all application failures occurring in the target vehicle-mounted application obtained by statistics from the server.

[0110] Step C2: Count the total number of times the third application failure occurs.

[0111] The server can record the number of times each application failure occurs, so as to obtain the total number of all application failures that occur in the target vehicle application.

[0112] Step C3: Obtain a quality evaluation result of the target in-vehicle application according to the total number of occurrences of the third application failure.

[0113] In the embodiment of the present application, the quality of the target vehicle-mounted application can be evaluated based on the total number of all application failures that occur in the target vehicle-mounted application. Generally speaking, the more total number of application failures that occur, the worse the application quality.

[0114] Step C4: Send the quality assessment result to the target recipient.

[0115] In order to ensure the stability of application services, it is necessary to monitor and analyze the application quality. Therefore, in an embodiment of the present application, the quality assessment results of the target vehicle-mounted application can be sent to the target recipient so that the target recipient can understand the quality problems of the target vehicle-mounted application, so that the target recipient can repair application defects in time and improve application quality as well as application reliability and performance.

[0116] Optionally, step C3: obtaining a quality assessment result of the target in-vehicle application according to the total number of occurrences of the third application failure, may include:

[0117] Step C31: Count the total running time of the target vehicle-mounted application on different vehicles.

[0118] When the target in-vehicle application is running, the vehicle can report the start time and end time of the application running to the server so that the total running time of the application can be counted later.

[0119] Step C32: Determine the ratio of the total number of occurrences of the third application failure to the total running time.

[0120] Step C33: Determine the ratio as the quality evaluation result of the target vehicle-mounted application.

[0121] This ratio can also be called the mean time between failures (MTBF) of the target vehicle-mounted application. The longer the mean time between failures, the lower the frequency of application failures and the higher the application quality. Conversely, the shorter the mean time between failures, the higher the frequency of application failures and the lower the application quality. Therefore, the embodiment of the present application uses the mean time between failures as the quality assessment result of the target vehicle-mounted application. The mean time between failures is obtained based on big data statistics, and the evaluation of application quality is more customer-oriented and more convincing than bench-based test results. It can also avoid the problem of being unable to expose and count some probabilistic failures or potential failures due to small samples.

[0122] Optionally, the embodiment of the present application can generate MTBF dashboards for different applications, such as Figure 6 The following is a MTBF dashboard for applications that can be installed on a vehicle. This dashboard allows you to see the MTBF of different applications at a glance.

[0123] In the embodiment of the present application, the application quality evaluation criteria can be pre-set, and the application quality can be determined based on the MTBF value, and the compliance status can be reflected in the MTBF dashboard for easy viewing. Of course, the compliance status can also be transferred to the target recipient when the summary information is transferred.

[0124] Optionally, it can be set that when the MTBF value is in the first value range, the application quality is considered to meet the standard; when the MTBF value is in the second value range, the application quality is considered to fail to meet the standard. The minimum value of the first value range is greater than the maximum value of the second value range. Of course, more detailed divisions can be made, for example, a pre-standard is set between meeting the standard and failing to meet the standard, such as Figure 6 As shown, the applications shown in the first row of the MTBF dashboard are in a non-compliant state, the applications shown in the second row are in a pre-compliant state, and the applications shown in the third row are in a compliant state.

[0125] Finally, it should be noted that the target vehicle-mounted application in the embodiment of the present application can be the entire application or an application module in the entire application.

[0126] The above is a description of the method for monitoring application failures applied to a server provided by the implementation of the present application.

[0127] In summary, in the technical solution provided by the present application, the log files generated by the vehicle-mounted application during operation will be uploaded to the server, and the server will parse the log files to determine whether there is log information related to the application failure in the log files. If it exists, corresponding summary information can be generated for different application failures based on the log information related to the application failure, and then the generated summary information is sent to the target recipient (such as the application developer, etc.) for relevant personnel (such as application developers) to monitor the application failure. Compared with the prior art, the application failure monitoring technology provided by the present application has a higher degree of automation, and there is no need for relevant personnel to manually search for log information related to the application failure from the log file according to the timestamp, which is conducive to improving the efficiency of locating application failures, so as to repair the application failures in time. And some application failures may not be perceived and easily missed. Through the technical solution provided by the present application, relevant personnel can also promptly discover and repair such application failures.

[0128] Correspondingly, an embodiment of the present application also provides a monitoring device for application failures, which is applied to a server.

[0129] like Figure 7 As shown, the device may include:

[0130] The acquisition module 701 is used to acquire at least one log file; the at least one log file is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle.

[0131] The first determination module 702 is configured to determine, based on an application failure matching rule, log information related to the application failure of the target vehicle-mounted application in the at least one log file.

[0132] The information generation module 703 is used to generate corresponding summary information for different application failures based on target information; the target information includes: log information related to the application failure of the target vehicle-mounted application.

[0133] The first sending module 704 is used to send the summary information to a target recipient; the summary information is used by the target recipient to perform application fault monitoring on the target vehicle-mounted application according to the summary information.

[0134] Optionally, the device may further include:

[0135] The second determination module is used to determine whether there is an application failure similar to the first application failure in the historical application failures of the target vehicle-mounted application according to the first summary information and the historical summary information; the first summary information is any summary information generated based on the target information, the first application failure is the application failure corresponding to the first summary information, and the historical summary information is the summary information corresponding to the historical application failure.

[0136] The relationship establishing module is used to establish an association relationship between the first summary information and the similar application failure when there is an application failure similar to the first application failure in the historical application failures.

[0137] The creation module is used to create a new application fault and establish an association relationship between the first summary information and the new application fault when there is no application fault similar to the first application fault in the historical application faults.

[0138] Optionally, the sending module 704 may include:

[0139] The first determining unit is used to determine a second application failure of the target in-vehicle application; the second application failure includes: a historical application failure with newly added summary information within a preset time period and / or a newly created application failure.

[0140] An acquiring unit is configured to acquire second summary information associated with the second application failure.

[0141] A sending unit is configured to send the second summary information to the target recipient.

[0142] Optionally, the device may further include:

[0143] The third determination module is used to determine a third application failure of the target in-vehicle application; the third application failure includes: the historical application failure and the created new application failure.

[0144] The statistics module is used to count the total number of times the third application failure occurs.

[0145] The quality assessment module is used to obtain a quality assessment result of the target vehicle-mounted application according to the total number of times the third application failure occurs.

[0146] The second sending module is used to send the quality assessment result to the target recipient.

[0147] Optionally, the quality assessment module may include:

[0148] The statistical unit is used to count the total running time of the target vehicle-mounted application on different vehicles.

[0149] The second determining unit is configured to determine a ratio of a total number of occurrences of the third application failure to the total running time.

[0150] The third determining unit is configured to determine the ratio as a quality evaluation result of the target in-vehicle application.

[0151] The monitoring device for application failures provided in this embodiment belongs to the same application concept as the monitoring method for application failures provided in the above embodiments of this application, and can execute the monitoring method for application failures provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not fully described in this embodiment, please refer to the specific processing content of the monitoring method for application failures provided in the above embodiments of this application, and will not be repeated here.

[0152] An embodiment of the present application also provides an application failure monitoring system, including a vehicle installed with a target vehicle-mounted application and a server.

[0153] The vehicle is used to send at least one log file generated during the operation of the target vehicle-mounted application to the server; the server is used to execute the application failure monitoring method described in the above embodiment.

[0154] The present application also provides an electronic device, such as Figure 8 As shown, the electronic device includes: a memory 800 and a processor 810 .

[0155] The memory 800 is connected to the processor 810 and is used to store programs.

[0156] The processor 810 is used to implement the method for monitoring application failures in the above embodiment by running the program stored in the memory 800 .

[0157] Specifically, the electronic device may further include: a communication interface 820 , an input device 830 , an output device 840 and a bus 850 .

[0158] The processor 810, the memory 800, the communication interface 820, the input device 830 and the output device 840 are connected to each other via a bus.

[0159] Bus 850 may include a pathway for transferring information between the various components of the computer system.

[0160] The processor 810 may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the scheme of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0161] The processor 810 may include a main processor, and may also include a baseband chip, a modem, and the like.

[0162] The memory 800 stores a program for executing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes a computer operation instruction. More specifically, the memory 800 may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0163] The input device 830 may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0164] Output device 840 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0165] The communication interface 820 may include any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc.

[0166] The processor 810 executes the program stored in the memory 800 and calls other devices, which can be used to implement each step of the application failure monitoring method provided in the above embodiment of the present application.

[0167] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps in the application failure monitoring method described in the embodiment of the present application.

[0168] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent application package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0169] In addition, the embodiments of the present application may also be a storage medium on which a computer program is stored, and the computer program is executed by a processor to execute the steps of the application failure monitoring method described in the embodiments of the present application.

[0170] In the several embodiments provided in the present application, it should be understood that the disclosed terminals, devices and methods can be implemented in other ways. For example, the terminal embodiments described above are only schematic, for example, the division of modules or submodules is only a logical function division, and there may be other division methods in actual implementation, for example, multiple submodules or modules can be combined or integrated into another module, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0171] The modules or submodules described as separate components may or may not be physically separated, and the components of the modules or submodules may or may not be physical modules or submodules, that is, they may be located in one place, or they may be distributed on multiple network modules or submodules. Some or all of the modules or submodules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0172] In addition, each functional module or submodule in each embodiment of the present application may be integrated into a processing module, or each module or submodule may exist physically separately, or two or more modules or submodules may be integrated into one module. The above-mentioned integrated modules or submodules may be implemented in the form of hardware or in the form of application functional modules or submodules.

[0173] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, an application unit executed by a processor, or a combination of the two. The application unit may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Claims

1. A method for monitoring application failures, characterized in that: Applied to a server, the method comprises: Obtain at least one log file; the at least one log file is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle; Based on the application fault matching rule, determining, in the at least one log file, log information related to the application fault of the target in-vehicle application; Based on the target information, corresponding summary information is generated for different application failures respectively; the target information includes: log information related to the application failure of the target vehicle application; The summary information is sent to a target recipient; the summary information is used by the target recipient to perform application fault monitoring on the target vehicle-mounted application according to the summary information.

2. The method according to claim 1, characterized in that After generating the summary information and before sending the summary information to the target recipient, the method further includes: Determine, according to the first summary information and the historical summary information, whether there is an application failure similar to the first application failure in the historical application failures of the target vehicle-mounted application; the first summary information is any summary information generated based on the target information, the first application failure is the application failure corresponding to the first summary information, and the historical summary information is the summary information corresponding to the historical application failure; In the case where there is an application failure similar to the first application failure in the historical application failures, establishing an association relationship between the first summary information and the similar application failure; If there is no application failure similar to the first application failure in the historical application failures, a new application failure is created, and an association relationship between the first summary information and the new application failure is established.

3. The method according to claim 2, characterized in that The sending the summary information to the target recipient includes: Determine a second application failure of the target in-vehicle application; the second application failure includes: a historical application failure with newly added summary information within a preset time period and / or a newly created application failure; Acquire second summary information associated with the second application failure; The second summary information is sent to the target recipient.

4. The method according to claim 2, characterized in that: The method further comprises: Determine a third application failure of the target in-vehicle application; the third application failure includes: the historical application failure and the created new application failure; Counting the total number of occurrences of the third application failure; Obtaining a quality assessment result of the target in-vehicle application according to the total number of occurrences of the third application failure; The quality assessment result is sent to the target recipient.

5. The method according to claim 4, characterized in that The obtaining, according to the total number of occurrences of the third application failure, a quality assessment result of the target vehicle-mounted application includes: Counting the total running time of the target vehicle-mounted application on different vehicles; Determine a ratio of a total number of occurrences of the third application failure to the total running time; The ratio is determined as a quality evaluation result of the target in-vehicle application.

6. A monitoring device for application failure, characterized in that: Applicable to servers, including: An acquisition module, used to acquire at least one log file; the at least one log file is generated during the operation of the target vehicle-mounted application and uploaded to the server by at least one vehicle; A first determination module, configured to determine, in the at least one log file, log information related to the application failure of the target in-vehicle application based on an application failure matching rule; An information generation module, configured to generate corresponding summary information for different application failures based on target information; the target information includes: log information related to the application failure of the target vehicle-mounted application; The first sending module is used to send the summary information to a target recipient; the summary information is used by the target recipient to perform application fault monitoring on the target vehicle-mounted application according to the summary information.

7. The application failure monitoring device according to claim 6, characterized in that: The device also includes: a second determination module, configured to determine whether there is an application failure similar to the first application failure in the historical application failures of the target vehicle-mounted application according to the first summary information and the historical summary information; the first summary information is any summary information generated based on the target information, the first application failure is the application failure corresponding to the first summary information, and the historical summary information is the summary information corresponding to the historical application failure; a relationship establishing module, configured to establish an association relationship between the first summary information and the similar application failure when there is an application failure similar to the first application failure in the historical application failures; The creation module is used to create a new application fault and establish an association relationship between the first summary information and the new application fault when there is no application fault similar to the first application fault in the historical application faults.

8. A monitoring system for application failures, characterized in that: including a vehicle and a server having a target in-vehicle application installed; The vehicle is used to send at least one log file generated during the operation of the target vehicle-mounted application to the server; The server is used to execute the application failure monitoring method as described in any one of claims 1 to 5.

9. An electronic device, characterized in that: include: Memory and processor; The memory is connected to the processor and is used to store programs; The processor is used to implement the method for monitoring application failures as described in any one of claims 1 to 5 by running the program in the memory.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by the processor, the method for monitoring application failures according to any one of claims 1 to 5 is implemented.

Images