CN117827500A

CN117827500A - Log acquisition method and device and electronic equipment

Info

Publication number: CN117827500A
Application number: CN202211185875.4A
Authority: CN
Inventors: 詹小奇; 陈慧鹏; 黄超超
Original assignee: Beijing Zitiao Network Technology Co Ltd
Current assignee: Beijing Zitiao Network Technology Co Ltd
Priority date: 2022-09-27
Filing date: 2022-09-27
Publication date: 2024-04-05

Abstract

The embodiment of the application discloses a log acquisition method, a log acquisition device and electronic equipment. One embodiment of the method comprises the following steps: in response to detecting the abnormal event, acquiring an event type of the abnormal event; determining occurrence times of abnormal events; and (4) performing log grabbing on the abnormal event based on the occurrence times and the event types. This embodiment makes log grabbing more targeted.

Description

Log acquisition method and device and electronic equipment

Technical Field

The embodiment of the disclosure relates to the technical field of computers, in particular to a log acquisition method, a log acquisition device and electronic equipment.

Background

With the rapid development of the mobile internet, android (Android) devices in daily use of people are more and more, and the stability of an Android system is important for user experience. Therefore, it is necessary to design an efficient log collection system for monitoring the stability of the Android device.

Disclosure of Invention

This disclosure is provided in part to introduce concepts in a simplified form that are further described below in the detailed description. This disclosure is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

In a first aspect, an embodiment of the present disclosure provides a log collection method, including: in response to detecting the abnormal event, acquiring an event type of the abnormal event; determining occurrence times of abnormal events; and (4) performing log grabbing on the abnormal event based on the occurrence times and the event types.

In a second aspect, an embodiment of the present disclosure provides a log collection device, including: an acquisition unit configured to acquire an event type of an abnormal event in response to detection of the abnormal event; a determining unit configured to determine the occurrence number of the abnormal event; and the grabbing unit is used for grabbing the logs of the abnormal events based on the occurrence times and the event types.

In a third aspect, an embodiment of the present disclosure provides an electronic device, including: one or more processors; and a storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the log collection method as in the first aspect.

In a fourth aspect, embodiments of the present disclosure provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements the steps of the log collection method according to the first aspect.

The log acquisition method, the log acquisition device and the electronic equipment provided by the embodiment of the disclosure acquire the event type of the abnormal event by responding to the detection of the abnormal event; then, the occurrence frequency of the abnormal event can be determined; finally, log grabbing may be performed on the abnormal event based on the occurrence number and the event type. By the method, log grabbing can be performed by using the occurrence times of the abnormal events and the event types, so that the log grabbing is more targeted.

Drawings

The above and other features, advantages, and aspects of embodiments of the present disclosure will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.

FIG. 1 is a flow chart of one embodiment of a log collection method according to the present disclosure;

FIG. 2 is a flow chart of yet another embodiment of a log collection method according to the present disclosure;

FIG. 3 is a flow chart of another embodiment of a log collection method according to the present disclosure;

FIG. 4 is a flow chart of yet another embodiment of a log collection method according to the present disclosure;

FIG. 5 is a flow chart of yet another embodiment of a log collection method according to the present disclosure;

FIG. 6 is a flow chart of one embodiment of determining whether an exception event is a memory problem in a log collection method according to the present disclosure;

FIG. 7 is a flow chart of yet another embodiment of a log collection method according to the present disclosure;

FIG. 8 is a flow chart of another embodiment of a log collection method according to the present disclosure;

FIG. 9 is a flow chart of one embodiment of the determining steps in a log collection method according to the present disclosure;

FIG. 10 is an exemplary system architecture diagram in which various embodiments of the present disclosure may be applied;

FIG. 11 is a schematic structural view of one embodiment of a log collection device according to the present disclosure;

fig. 12 is a schematic diagram of a computer system suitable for use in implementing embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.

It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units.

It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.

The names of messages or information interacted between the various devices in the embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

Referring to fig. 1, a flow 100 of one embodiment of a log collection method according to the present disclosure is shown. The log acquisition method comprises the following steps:

in step 101, in response to detecting the abnormal event, an event type of the abnormal event is acquired.

In this embodiment, the execution subject of the log collection method may determine whether an abnormal event is detected. If an abnormal event is detected, the event type of the abnormal event can be obtained.

Here, the event type of the above abnormal event may be a Watchdog (Watchdog) file abnormality, where Watchdog is a mechanism provided by the Android system for checking abnormality of the system in the future, and it checks several core services of the Android framework layer. The System Server process is cleared once the main thread blocks of core services such as AMS (Activity Manager Service, activity management service), WMS (Window Manager Service, interface management service) and PMS (Package Manage Service, installation management service) are discovered by the Watchdog.

Step 102, determining the occurrence times of the abnormal event.

In this embodiment, the execution body may determine the occurrence number of the abnormal event. Here, the execution subject may determine the number of occurrences of the abnormal event within a preset period of time (e.g., 1 day, 1 hour, 1 minute, etc.).

And step 103, performing log grabbing on the abnormal event based on the occurrence times and the event types.

In this embodiment, the execution body may perform log grabbing on the abnormal event based on the occurrence number determined in step 102 and the event type acquired in step 101.

As an example, since the Watchdog file exception is a relatively serious exception condition, if the event type is the Watchdog file exception, the log of the Watchdog file exception is grasped regardless of the number of occurrences of the Watchdog file exception.

The method provided by the embodiment of the present disclosure obtains an event type of an abnormal event by responding to the detection of the abnormal event; then, the occurrence frequency of the abnormal event can be determined; finally, log grabbing may be performed on the abnormal event based on the occurrence number and the event type. According to the method, log grabbing can be performed by using the occurrence times and the event types of the abnormal events, duplication can be removed according to the event types of the abnormal events, the problem of the same reason is only collected once, and specific logs are collected for different event types on the premise that the use of users is not affected, so that the problem solving efficiency is improved, and the log grabbing is more targeted.

In some alternative implementations, the event type may be android program Crash (Java Crash). Java Crash is the occurrence of uncaptured exceptions in Java code, resulting in program exception exit. The execution body may determine the occurrence number of the abnormal event by: when Java Crash occurs, the execution body may call a logginkghandle.uncaught exception () function to obtain stack information of the exception event, and then may extract a process name, detailed information (message), an exception type, and a target Crash stack from the stack information; then, the execution body may determine whether the exception event is the first occurrence based on the process name, the detailed information, the exception type, and the target crash stack. Here, the execution body may compare the process name, the detailed information, the exception type, and the target crash stack with data in a predetermined first database, and determine whether the exception event occurs for the first time. The first database generally stores information about Java Crash events that have occurred. If the process name, the detailed information, the exception type and the target crash stack match data in the first database, determining that the exception event did not occur for the first time; if the process name, the detailed information, the exception type, and the target crash stack do not match data in the first database, then determining that the exception event is the first occurrence.

In some alternative implementations, the event type may be application unresponsiveness (Application Not Response, ANR). ANR refers to an abnormal event in a dialog box that the system may display to the user when the application response is not sufficiently sensitive on the operating system. The execution body may determine the occurrence number of the abnormal event by: the execution body may acquire the target information when the abnormal event occurs. The target information is typically each operation index of the system when the abnormal event occurs. Then, it may be determined whether the abnormal event occurs for the first time based on the target information. Specifically, the executing body may determine a cause of the occurrence of the ANR by using each operation index of the system when the ANR occurs, so as to query in a preset second database whether the ANR of the cause has occurred; if so, determining that the abnormal event does not occur for the first time; if not, it may be determined that the abnormal event is the first occurrence. By the method, the attribute information of the ANR can be utilized to carry out attribution, for example, the system load is too high due to the same process, and the problem of the same type is considered to be the problem if the memory pressure is too high, so that the problem is de-duplicated, and repeated grabbing of the log is prevented. Whereas ANR caused by non-system loading problems is due to deduplication according to the main thread stack of the ANR process.

In some alternative implementations, the event type described above may be a power-on animation stuck. When starting to play the boot animation, the boot animation process sends a delay message to the log grabbing process to inform the start of the boot animation; when the starting-up animation process detects that the starting-up animation is finished to play, a notification informing that the starting-up animation is finished is sent to the log grabbing process, and the delay message is canceled. The abnormal event that the startup animation is stuck can be detected by the following way: the execution body may detect whether a start-up animation end notification is received within a preset first duration from a target time point. The target time point may be a time point when a startup notification is received (for example, a time point when the delay message is received), and the startup notification may be a notification sent when startup animation starts. If the starting-up animation end notification is not received within the first time period from the target time point, the execution body may determine that an abnormal event that the starting-up animation is blocked is detected. At this time, the above-mentioned delay message may be used to capture a log of the stuck event of the boot animation.

By the method, the scene of the startup animation which is not finished in a certain time period can be monitored, and whether the equipment is in an abnormal state of being blocked in the startup animation can be identified.

In some alternative implementations, the event type described above may be a power-on animation stuck. The abnormal event that the startup animation is stuck can also be detected by the following way: the execution body can detect whether the target process has a restart operation for a preset number of times within a preset second duration. The target process may be a System Server process (System Server process) or a parent process (zygate process) that spawns a non-native process. The Zygote is a process in the Android system, is started by a first process Init process (a first user-level process started by a kernel) in a user space, is a first Android run process (an Android program loading and running environment) operated by the Android system, and is a bridge for opening Native and Java. If the target process is detected to generate the restarting operation of the times within the second time period, the execution body can determine that the event that the startup animation is blocked is detected.

As an example, if the System Server process or the zygate process performs 5 restart operations within 8 minutes, it may be considered that a stuck-on event of the startup animation is detected.

By the method, the scene that the System Server process or the zygate process is restarted repeatedly can be monitored, and whether the equipment is in an abnormal state of being blocked in the startup animation can be identified.

In some optional implementations, the execution body may log the exception event by: the execution subject may perform log grabbing on the abnormal event using a target specimen local process, where the target specimen local process is used to grab a log. When an abnormal event occurs, data is usually transferred through a binder communication, and if a binder call is not supported currently or a binder service acquisition fails, the data can be transferred through the target local process. The target local process is a daemon process, and obtains driving data by adopting a read interface or a poll (adding a read waiting queue) interface mode. The above-mentioned destination local process stability buried point interface adopts asynchronous binder, so that the caller thread will not be blocked, but in order to support parallel execution of asynchronous binder threads, a corresponding anonymous binder entity is created according to the number of binder threads in the process binder thread pool to actually carry out binder communication.

With continued reference to FIG. 2, a flow 200 of yet another embodiment of a log collection method is shown. The process 200 of the log collection method includes the following steps:

in step 201, in response to detecting the abnormal event, an event type of the abnormal event is acquired.

In this embodiment, the execution subject of the log collection method may determine whether an abnormal event is detected. If an abnormal event is detected, the event type of the abnormal event can be obtained. Here, the event type may be an android crash.

Step 202, obtaining stack information of the abnormal event, and extracting a process name, detailed information, an abnormal type and a target crash stack from the stack information.

In this embodiment, when Java Crash occurs, the execution body may call a logminghandler.uncaghtexception () function to obtain stack information of the exception event, and then may extract a process name, detailed information, an exception type, and a target Crash stack from the stack information.

Here, the target crash stack may include: a first target crash stack and a second target crash stack, wherein the first target crash stack is extracted from a first stage crash stack, and the second target crash stack is extracted from a second stage crash stack.

As an example, the first target crash stack may be the first 10 lines of information extracted from the first-level crash stack, and the second target crash stack may be the first 10 lines of information extracted from the second-level crash stack.

It should be noted that, if the total number of lines of the first-stage crash stack or the second-stage crash stack is less than 10 lines, the first target crash stack may be all stack information extracted from the first-stage crash stack, and the second target crash stack may be all stack information extracted from the second-stage crash stack.

And 203, screening the abnormal event matched with the abnormal event from a preset first database by using the process name, the first target crash stack and the abnormal type to serve as a target event.

In this embodiment, the execution body may screen, as the target event, an exception event matching the exception event from a preset first database by using the process name, the first target crash stack, and the exception type. The first database generally stores information about Java Crash events that have occurred.

Step 204, determining whether an abnormal event matched with the abnormal event exists in the target event by using the second target crash stack and the detailed information.

In this embodiment, the execution body may determine whether an abnormal event matching the abnormal event exists in the target events screened in step 203 by using the second target crash stack and the detailed information.

If there is an abnormal event that matches the abnormal event, the execution body may determine that the abnormal event does not occur for the first time.

If there is no abnormal event matching the abnormal event, the execution body may execute step 205.

In step 205, if there is no abnormal event matching the abnormal event, it is determined that the abnormal event occurs for the first time.

In this embodiment, if it is determined in step 204 that there is no abnormal event matching the abnormal event, the execution body may determine that the abnormal event occurs for the first time.

And 206, performing log grabbing on the abnormal event based on the occurrence times and the event types.

In this embodiment, the execution body may perform log grabbing on the abnormal event based on the occurrence number and the event type. Here, if the event type is an android crash and the occurrence number is the first, the execution body may grab the log of the abnormal event.

After extracting the process name, the detailed information, the exception type and the target crash stack from the stack information, the execution body may send the process name, the detailed information, the exception type and the target crash stack to a System Server process through a binder communication through a notify appcrash () function. And the binder is a communication mode among processes in the android operating system. The System Server process is the last flow before the android System enters the desktop, and in the process of starting the System Server process, a plurality of service processes of the System, such as AMS, camera Server and the like, are started.

And then, determining whether the abnormal event occurs for the first time in the System Server process, and if so, notifying a target sample local process to grab the log of the abnormal event, wherein the target sample local process can be used for grabbing the log.

It should be noted that, for different exception types of Java Crash, different logs and files are grabbed, and for a specific exception type, when notifying a target local process to grab the log of the exception event, a sleep time is generally required to be set so as to prevent the process from ending prematurely and failing to grab an effective log.

As can be seen from fig. 2, compared with the embodiment corresponding to fig. 1, the flow 200 of the log collection method in this embodiment reflects the stack information of the obtained exception event, and extracts the process name, the detailed information, the exception type and the target crash stack from the stack information; screening an abnormal event matched with the abnormal event from a preset first database by using the process name, the first target crash stack and the abnormal type to serve as a target event; determining whether an abnormal event matched with the abnormal event exists in the target event by using the second target crash stack and the detailed information; if no abnormal event matched with the abnormal event exists, determining that the abnormal event is the first occurrence step. Therefore, when the android program crashes, the method and the device can utilize stack information of the abnormal event to determine whether the event matched with the abnormal event exists in the preset first database, and the implementation mode improves efficiency of screening the matched event from the first database.

In some optional implementations, the execution body may log the exception event by: the execution body may determine the log to be grabbed using the exception type. Here, the above-described anomaly types may include, but are not limited to, at least one of: the memory starvation (Out Of Memory Error), the inability to find specified classes (Class Not Found Exception), and input-output exceptions (IO exceptions). In this way, log information can be grasped customizable.

The execution body may store in advance a correspondence between the exception type and the corresponding log to be grabbed. As an example, if the exception type is that no specified class is found, the log that needs to be crawled may include: system settings (system prop) files, log main (log main) files, log system (log system) files, log crash (log crash) files, dex files, and DIR files. The Dex file is an executable file of the Android system and contains all operation instructions of the application program and runtime data. DIR generally refers to a COMMAND within the DOS operating system to view a file in a COMMAND.

With further reference to fig. 3, a flow 300 of another embodiment of a log collection method is shown. The process 300 of the log collection method includes the following steps:

in step 301, in response to detecting an abnormal event, an event type of the abnormal event is acquired.

In this embodiment, the execution subject of the log collection method may determine whether an abnormal event is detected. If an abnormal event is detected, the execution body may acquire an event type of the abnormal event. Here, the event type may be an application non-response.

Application unresponsive ANR refers to an abnormal event in a dialog box that the system may display to the user when the application is not sufficiently responsive on the operating system.

Step 302, obtaining target information when an abnormal event occurs.

In this embodiment, the execution body may acquire the target information when the abnormal event occurs. Here, the above target information may include: the CPU occupancy (CPU loading), the duty cycle of the input/output latency (IO wait) and the remaining space of the data partition within the response time are preset. The above-described response times are generally referred to as ANR response times.

The CPU occupancy rate may also be referred to as a CPU utilization rate, which generally refers to the ratio of the CPU resources occupied by an operating program, indicating the condition of the operating program of the machine at a certain point in time. The higher the usage, the more programs the machine runs at this time and vice versa.

Input/output latency is generally referred to as process latency due to IO and can be determined as follows: a few percent of the time in a sampling period is the following: the CPU is in an idle state and has at least one outstanding disk IO request. Since the system is doing input/output, no process is running dry, and the CPU is executing idle process idle. When the IO wait is high, it indicates that the idle CPU resources are more, and some computing-related work can be processed, that is, the IO wait is a representation form of the idle time of the CPU.

Step 303, determining whether the occupancy rate of the central processing unit in the response time is greater than a preset occupancy rate threshold.

In this embodiment, the executing entity may determine whether the cpu occupancy is greater than a preset occupancy threshold (e.g., 95%) during the ANR response time.

If the occupancy rate of the cpu is greater than the occupancy rate threshold in the ANR response time, it indicates that the execution subject has more execution programs at a certain time point, and step 304 may be executed.

Step 304, if the occupancy threshold is greater, determining whether the occupancy of the input/output latency is greater than a preset occupancy threshold.

In this embodiment, if it is determined in step 303 that the cpu occupancy is greater than the occupancy threshold during the ANR response time, the execution body may determine whether the occupancy of the i/o latency is greater than a preset occupancy threshold (e.g., 70%).

If the duty ratio of the i/o latency is greater than the duty ratio threshold, it indicates that there are more CPU resources that are free, and the execution subject may execute step 305.

In step 305, if the remaining space is greater than the duty ratio threshold, it is determined whether the remaining space is less than a preset space threshold.

In this embodiment, if it is determined in step 304 that the duty ratio of the input/output waiting time is greater than the duty ratio threshold, the execution body may determine whether the remaining space of the data partition is less than a preset space threshold (e.g., 200M).

If the remaining space of the data partition is less than the space threshold, the execution body may execute step 306.

If the abnormal event is less than the spatial threshold, it is determined that the abnormal event is an input/output problem, and the abnormal event does not occur for the first time in step 306.

In this embodiment, if it is determined in step 305 that the remaining space of the data partition is smaller than the space threshold, the execution body may determine that the abnormal event is an input/output (IO) problem, and the abnormal event does not occur for the first time.

Step 307, if the spatial threshold is greater than or equal to the spatial threshold, acquiring the input/output information in the response time, and analyzing the input/output information.

In this embodiment, if it is determined in step 305 that the remaining space of the data partition is greater than or equal to the space threshold, the execution body may acquire the input/output information in the ANR response time, and analyze the input/output information to determine the first target process when the abnormal event occurs. The first target process is generally determined based on the occupation condition of the central processing unit when the problem occurs, that is, the process information of each process occupying the CPU when the abnormal event occurs and the CPU occupation rate of each process are determined. As an example, the first target process may be a process with the highest CPU occupancy rate.

Step 308, determining whether the first target process when the abnormal event occurs is the same as the first target process when the input/output problem recorded in the preset second database occurs.

In this embodiment, the execution body may determine whether the first target process when the abnormal event occurs is the same as the first target process when the input/output problem recorded in the preset second database occurs. The second database generally stores information about ANR events that have occurred, that is, process information of a first target process when an input/output problem occurs is recorded in the second database, where the first target process is generally determined based on an occupation condition of a central processing unit when the problem occurs, that is, process information of each process occupying a CPU when the abnormal event occurs and a CPU occupation rate of each process are recorded in the second database. As an example, the first target process may be a process with the highest CPU occupancy rate.

Here, the execution body may determine whether or not a process having the highest CPU occupancy rate when the abnormal event occurs is the same as a process having the highest CPU occupancy rate when the input/output problem recorded in the second database occurs.

If the first target process when the abnormal event occurs is the same as the first target process when the input/output problem recorded in the second database occurs, the execution subject may execute step 308.

If the result is the same, step 309 determines that the abnormal event is an input/output problem, and the abnormal event does not occur for the first time.

In this embodiment, if it is determined in step 307 that the first target process when the abnormal event occurs is the same as the first target process when the input/output problem recorded in the second database occurs, the execution body may determine that the abnormal event is an input/output problem, and the abnormal event does not occur for the first time.

If the two events are different, step 310 determines that the abnormal event is an input/output problem, and the abnormal event is the first occurrence.

In this embodiment, if it is determined in step 307 that the first target process when the abnormal event occurs is different from the first target process when the input/output problem recorded in the second database occurs, the execution body may determine that the abnormal event is the input/output problem, and the abnormal event is the first occurrence.

Step 311, capturing the input/output occupation information of the process of the abnormal event based on the occurrence times and the event type.

In this embodiment, the execution body may grab input/output occupation information of a process of the abnormal event based on the occurrence number and the event type of the abnormal event, and store the grabbed input/output occupation information and the process information of the abnormal event in association with each other in the second database.

Here, if the event type is an input/output problem to which the application program does not respond, and the occurrence number is the first, the execution subject may grasp input/output occupation information of the progress of the abnormal event. If the event type is an input/output problem that the application program does not respond, the occurrence times are not the first time, and the execution subject may not grasp the input/output occupation information of the process of the abnormal event.

As can be seen from fig. 3, compared with the embodiment corresponding to fig. 1, the flow 300 of the log collection method in this embodiment shows steps of determining whether an abnormal event is an input/output problem and determining whether the abnormal event is the first occurrence when the abnormal event is an application non-response. Thus, the solution described in this embodiment can determine an abnormal event of an input/output problem when an application program non-response occurs.

With further reference to fig. 4, a flow 400 of yet another embodiment of a log collection method is shown. The process 400 of the log collection method includes the following steps:

in step 401, in response to detecting the abnormal event, an event type of the abnormal event is acquired.

Step 402, obtaining target information when an abnormal event occurs.

In this embodiment, the execution body may acquire the target information when the abnormal event occurs. Here, the above target information may include: the occupation rate of the central processing unit, the occupation rate of the input/output waiting time and the residual space of the data partition in the response time are preset. The above-described response times are generally referred to as ANR response times.

Step 403, determining whether the occupancy rate of the central processing unit in the response time is greater than a preset occupancy rate threshold.

In this embodiment, the execution body may determine whether the cpu occupancy is greater than a preset occupancy threshold during the ANR response time.

If the cpu occupancy rate is greater than the occupancy rate threshold in the ANR response time, it indicates that the execution subject has more execution programs at a certain time point, and step 404 may be executed.

If the occupancy threshold is greater, a determination is made as to whether the occupancy of the input/output latency is greater than a preset occupancy threshold, step 404.

In this embodiment, if it is determined in step 403 that the cpu occupancy is greater than the occupancy threshold during the ANR response time, the execution entity may determine whether the occupancy of the i/o latency is greater than a preset occupancy threshold.

If the duty ratio of the i/o latency is equal to or less than the duty ratio threshold, the execution subject may execute step 405, indicating that there are fewer idle CPU resources.

Step 405, if the duty ratio threshold is less than or equal to the duty ratio threshold, determining whether the second target process when the abnormal event occurs is the same as the second target process when the cpu load problem recorded in the second database occurs.

In this embodiment, if it is determined in step 404 that the duty ratio of the i/o latency is equal to or less than the duty ratio threshold, the execution body may determine whether the second target process when the abnormal event occurs is the same as the second target process when the cpu load problem recorded in the second database occurs. Here, the second target process may be determined based on an occupancy of the central processor at the time of occurrence of the problem. As an example, the second target process may be a process consuming more than 1 core CPU. That is, the execution body may determine whether a process consuming 1-core or more CPU when the abnormal event occurs is the same as a process consuming 1-core or more CPU when the CPU load problem recorded in the second database occurs.

If it is determined that the second target process when the abnormal event occurs is the same as the second target process when the cpu load problem recorded in the second database occurs, the execution body may execute step 406.

If it is determined that the second target process when the abnormal event occurs is different from the second target process when the cpu load problem recorded in the second database occurs, the execution body may execute step 407.

If the determination is the same, step 406 determines that the abnormal event is a cpu load problem, and the abnormal event does not occur for the first time.

In this embodiment, if it is determined in step 405 that the second target process when the abnormal event occurs is the same as the second target process when the cpu load problem recorded in the second database occurs, the execution body may determine that the abnormal event is the cpu load problem, and the abnormal event does not occur for the first time.

If the two events are different, step 407 determines that the abnormal event is a cpu load problem, and the abnormal event is the first occurrence.

In this embodiment, if it is determined in step 405 that the second target process when the abnormal event occurs is different from the second target process when the cpu load problem recorded in the second database occurs, the execution body may determine that the abnormal event is the cpu load problem, and the abnormal event is the first occurrence.

Step 408, based on the occurrence times and the event type, the occupation information of the central processor is grabbed.

In this embodiment, the execution body may grab occupancy information of the central processing unit based on the occurrence times and the event types of the abnormal events, and store the grabbed occupancy information of the central processing unit and process information of the abnormal events in the second database in an associated manner.

Here, if the event type is a cpu load problem to which the application program does not respond, and the occurrence number is the first, the execution body may grab occupancy information of the cpu. If the event type is a cpu load problem for which the application program does not respond, the occurrence frequency is not the first time, and the execution subject may not grasp occupancy information of the cpu.

As can be seen from fig. 4, compared with the embodiment corresponding to fig. 1, the flow 400 of the log collection method in this embodiment shows the steps of determining whether an abnormal event is a cpu load problem and determining whether the abnormal event occurs for the first time when the abnormal event is an application non-response. Therefore, the scheme described in the embodiment can determine the abnormal event of the load problem of the central processing unit when no response of the application program occurs.

With continued reference to fig. 5, a flow 500 of yet another embodiment of a log collection method is shown. The process 500 of the log collection method includes the following steps:

in step 501, in response to detecting an abnormal event, an event type of the abnormal event is obtained.

Step 502, obtaining target information when an abnormal event occurs.

Step 503, determining whether the occupancy rate of the central processing unit is greater than a preset occupancy rate threshold in the response time.

If the occupancy rate of the cpu is less than or equal to the occupancy rate threshold in the ANR response time, it indicates that the execution subject has fewer execution programs at a certain time point, and step 504 may be executed.

Step 504, if the occupancy rate is less than or equal to the occupancy rate threshold, determining whether the abnormal event is a memory problem.

In this embodiment, if it is determined in step 503 that the cpu occupancy rate is less than or equal to the occupancy rate threshold in the ANR response time, the execution body may determine whether the abnormal event is a memory problem.

If the exception event is a memory problem, the execution body may execute step 505.

In step 505, if the memory problem is present, it is determined whether the time interval between the occurrence time of the memory problem and the occurrence time of the abnormal event recorded in the second database is smaller than the preset first time interval.

In this embodiment, if it is determined in step 504 that the abnormal event is a memory problem, the execution body may determine whether a time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is less than a preset first time interval (e.g., 10 seconds).

If the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is smaller than the first time interval, the execution body may execute step 506.

If the first time interval is smaller than the first time interval, it is determined that the abnormal event is a memory problem, and the abnormal event does not occur for the first time.

In this embodiment, if it is determined in step 505 that the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is smaller than the first time interval, the execution body may determine that the abnormal event is a memory problem, and the abnormal event is not the first occurrence.

And 507, if the first time interval is greater than or equal to the first time interval, capturing the memory occupation information of the process of the abnormal event.

In this embodiment, if it is determined in step 505 that the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is greater than or equal to the first time interval, the execution subject may grasp the memory occupation information of the process of the abnormal event.

Step 508, determining, for each memory problem recorded in the second database, whether the third target process when the memory problem occurs is the same as the third target process when the abnormal event occurs.

In this embodiment, for each memory problem recorded in the second database, the execution body may determine whether the third target process when the memory problem occurs is the same as the third target process when the abnormal event occurs. Here, the third target process may be determined based on the memory occupancy at the time of the problem occurrence. As an example, the third target process may be a process with a memory occupancy greater than a total memory preset value (e.g., 15%).

That is, the execution body may determine whether the process with the memory occupancy rate greater than 15% of the total memory when the memory problem occurs is the same as the process with the memory occupancy rate greater than 15% of the total memory when the abnormal event occurs.

If it is determined that the process with the memory occupancy rate greater than 15% of the total memory when the memory problem occurs is the same as the process with the memory occupancy rate greater than 15% of the total memory when the abnormal event occurs, the execution body may execute step 509.

If it is determined that the process with the memory occupancy rate greater than 15% of the total memory when the memory problem occurs is different from the process with the memory occupancy rate greater than 15% of the total memory when the abnormal event occurs, the execution body may execute step 510.

If the same, step 509, it is determined that the abnormal event does not occur for the first time.

In this embodiment, if it is determined in step 508 that the process with the memory occupancy rate greater than 15% of the total memory when each memory problem recorded in the second database occurs is the same as the process with the memory occupancy rate greater than 15% of the total memory when the abnormal event occurs, the executing body may determine that the abnormal event does not occur for the first time.

If not, step 510 is performed to determine that the abnormal event is the first occurrence.

In this embodiment, if it is determined in step 508 that the process with the memory occupancy rate greater than 15% of the total memory when the problem occurs in the memory problem recorded in the second database is different from the process with the memory occupancy rate greater than 15% of the total memory when the abnormal event occurs, the execution subject may determine that the abnormal event occurs for the first time.

In step 511, the memory occupation information of the process of the abnormal event is grabbed based on the occurrence times and the event type.

In this embodiment, the executing body may grab memory occupancy information of a process of the abnormal event based on the occurrence times and the event types of the abnormal event, and store the grabbed memory occupancy information and the process information of the abnormal event in the second database in an associated manner.

Here, if the event type is a memory problem to which the application program does not respond, and the occurrence number is the first time, the execution body may grab memory occupation information of the process of the abnormal event. If the event type is a memory problem that the application program does not respond, the occurrence times are not the first time, and the execution body may not grasp memory occupation information of the process of the abnormal event.

As can be seen from fig. 5, compared with the embodiment corresponding to fig. 1, the process 500 of the log collection method in this embodiment shows steps of determining whether an abnormal event is a memory problem when the abnormal event is an application program non-response, determining whether the abnormal event is the first occurrence, and capturing memory occupation information of a process of the abnormal event. Therefore, the scheme described in the embodiment can determine the abnormal event of the memory problem when the application program does not respond, and can pointedly grasp the memory occupation information of the process.

Referring further to FIG. 6, a flow 600 of one embodiment of a log collection method for determining whether an exception event is a memory problem is shown. The process 600 of determining whether an exception event is a memory problem includes the steps of:

In step 601, it is determined whether the average remaining memory within the response time is less than a preset first remaining memory threshold.

In this embodiment, the execution body of the log collection method may determine whether the average remaining memory in the ANR response time is less than a preset first remaining memory threshold (e.g., 5%).

If it is determined that the average remaining memory within the ANR response time is less than the first remaining memory threshold, the execution body may execute step 602.

If it is determined that the average remaining memory within the ANR response time is greater than or equal to the first remaining memory threshold, the execution body may execute step 603.

In step 602, if the abnormal event is smaller than the first remaining memory threshold, it is determined that the abnormal event is a memory problem.

In this embodiment, if it is determined in step 601 that the average remaining memory in the ANR response time is smaller than the first remaining memory threshold, the execution body may determine that the abnormal event is a memory problem.

Step 603, if the first remaining memory threshold is greater than or equal to the first remaining memory threshold, determining whether a preset first condition exists.

In this embodiment, if it is determined in step 601 that the average remaining memory within the ANR response time is greater than or equal to the first remaining memory threshold, the execution body may determine whether a preset first condition exists.

Here, the first condition may be that a preset second condition occurs within the ANR response time and the remaining memory when the second condition occurs is less than a preset second remaining memory threshold (for example, 15%), and the second condition may include at least one of the following: the usage of the running kernel page swap daemon (kswapd 0 thread) and the low memory killing program (Low Memory Killer Daemon, LMKD) is not a first target value, which is typically 0. The kswapd0 thread is responsible for recovering pages when the memory is insufficient, the kswapd0 thread can be regarded as a virtual memory management program of the system, and if the physical memory is insufficient, the system wakes up the kswapd0 thread. The LMKD is used to monitor the memory state of an operating android system and to cope with high memory pressures by killing the least significant processes to keep the system operating at an acceptable level.

In step 604, if the preset first condition exists, it is determined that the abnormal event is a memory problem.

In this embodiment, if it is determined in step 603 that the first situation exists, the execution body may determine that the abnormal event is a memory problem.

The method provided by the above embodiment of the present disclosure determines whether the average remaining memory in the response time is smaller than a preset first remaining memory threshold; if the abnormal event is smaller than the first residual memory threshold value, determining the abnormal event as a memory problem; if the first remaining memory threshold is greater than or equal to the first remaining memory threshold, determining whether the following first situation exists: a second condition that the utilization rate of the kswapd0 thread or the LMKD is not 0 exists in the ANR response time, and the residual memory when the second condition occurs is smaller than a preset second residual memory threshold value; if the first condition exists, determining that the abnormal event is a memory problem, and by the mode, determining whether the abnormal event is the memory problem or not can be accurately performed.

With further reference to fig. 7, a flow 700 of yet another embodiment of a log collection method is shown. The process 700 of the log collection method includes the following steps:

in step 701, in response to detecting an abnormal event, an event type of the abnormal event is acquired.

Step 702, obtaining target information when an abnormal event occurs.

In step 703, it is determined whether the cpu occupancy is greater than a preset occupancy threshold during the response time.

If the cpu occupancy rate is less than or equal to the occupancy rate threshold during the ANR response time, it indicates that the execution subject has fewer execution programs at a certain time point, and step 704 may be executed.

In step 704, if the average remaining memory is less than or equal to the occupancy threshold, it is determined whether the average remaining memory within the response time is less than a preset first remaining memory threshold.

In this embodiment, if it is determined in step 703 that the cpu occupancy rate in the ANR response time is less than or equal to the occupancy rate threshold, the execution body may determine whether the average remaining memory in the ANR response time is less than a preset first remaining memory threshold (e.g., 5%).

If it is determined that the average remaining memory within the ANR response time is greater than or equal to the first remaining memory threshold, the execution body may execute step 705.

Step 705, if the first remaining memory threshold is greater than or equal to the first remaining memory threshold, determining whether a preset first condition exists.

In this embodiment, if it is determined in step 704 that the average remaining memory within the ANR response time is greater than or equal to the first remaining memory threshold, the execution body may determine whether a preset first condition exists.

Here, the first condition may be that a preset second condition occurs within the ANR response time and the remaining memory when the second condition occurs is less than a preset second remaining memory threshold (for example, 15%), and the second condition may include at least one of the following: the usage of running the kernel page swap daemon and the low memory killing program is not a first target value, which is typically 0. The kswapd0 thread is responsible for recovering pages when the memory is insufficient, the kswapd0 thread can be regarded as a virtual memory management program of the system, and if the physical memory is insufficient, the system wakes up the kswapd0 thread. The LMKD is used to monitor the memory state of an operating android system and to cope with high memory pressures by killing the least significant processes to keep the system operating at an acceptable level.

If it is determined that the first situation does not exist, the execution body may execute step 706.

In step 706, if the preset first condition does not exist, it is determined whether an abnormal event exists in the second database, wherein the abnormal event has the same process name and stack information as the abnormal event, and the main thread to which the application program does not respond is in a non-idle state.

In this embodiment, if it is determined in step 705 that the first situation does not exist, the execution body may determine whether an exception event exists in the second database, where the exception event has the same process name and stack information as the exception event, and the main thread to which the application program does not respond is in a non-idle state (looper).

If there is an abnormal event in which the main thread, which is identical in process name and stack information to the abnormal event and to which the application program does not respond, is in a non-idle state, the execution body may execute step 707.

If there is no abnormal event in which the main thread, which is the same as the process name of the abnormal event and the stack information is the same and the application program does not respond, is in a non-idle state, the execution body may execute step 708.

In step 707, if there is an abnormal event that is the same as the process name of the abnormal event and the stack information is the same and the main thread to which the application program does not respond is in a non-idle state, it is determined that the abnormal event is a logic problem, and the abnormal event does not occur for the first time.

In this embodiment, if it is determined in step 706 that there is an abnormal event that is the same as the process name of the abnormal event and the stack information is the same and the main thread to which the application program does not respond is in a non-idle state, the execution body may determine that the abnormal event is a logical problem, and the abnormal event does not occur for the first time.

If there is no abnormal event in which the main thread is in a non-idle state, which has the same process name and stack information as the abnormal event and the application program does not respond, the abnormal event is determined to be a logical problem, and the abnormal event occurs for the first time, step 708.

In this embodiment, if it is determined in step 706 that there is no abnormal event that the main thread, which has the same process name and stack information as the abnormal event and is not responded to by the application program, is in a non-idle state, the execution body may determine that the abnormal event is a logical problem, and the abnormal event is the first occurrence.

Step 709, log grabbing is performed on the abnormal event based on the occurrence times and the event type.

In this embodiment, the execution body may grab the log of the abnormal event based on the occurrence number and the event type of the abnormal event, and store the grabbed log and the process information of the abnormal event in the second database in association with each other. Here, the execution body may grasp the trace log. If the stack is stuck in the binder communication mode, the opposite end information of the binder needs to be captured.

As can be seen from fig. 7, compared with the embodiment corresponding to fig. 1, the flow 700 of the log collection method in this embodiment shows the steps of determining whether an abnormal event is a logic problem and determining whether the abnormal event is the first occurrence when the abnormal event is an application non-response. Therefore, the scheme described in the embodiment can determine the abnormal event of the logic problem when the application program does not respond.

With continued reference to fig. 8, a flow 800 of another embodiment of a log collection method is shown. The process 800 of the log collection method includes the following steps:

in step 801, in response to detecting an abnormal event, an event type of the abnormal event is acquired.

In this embodiment, the execution subject of the log collection method may determine whether an abnormal event is detected. If an abnormal event is detected, the execution body may acquire an event type of the abnormal event. Here, the event type may be a local Crash (Native Crash). Native Crash is generally because illegal addresses are accessed in Native code, and may cause problems in address alignment or active program suspension, which all generate corresponding signals, resulting in program exception exit.

Step 802, determining the occurrence number of the abnormal event.

Step 803, process information of the abnormal event is acquired.

In this embodiment, the execution body may acquire process information of the abnormal event. Here, the above-described process information may include basic information of the process, such as a process name and a signal value.

Step 804, the following determination steps are performed: determining whether the process information which is not traversed exists in a preset third database; if the process information which is not traversed exists, the process information which is not traversed is obtained as target process information; determining whether an event indicated by the target process information is identical to an abnormal event or not based on the process information and the target process information; if the event indicated by the target process information is the same as the abnormal event, updating the occurrence times and the breakdown time points of the abnormal event in a third database; determining whether the occurrence frequency of the abnormal event is equal to a preset occurrence frequency threshold value; and if the occurrence frequency threshold value is equal to the occurrence frequency threshold value, performing log grabbing on the abnormal event.

In this embodiment, step 804 may include sub-steps 8041, 8042, 8043, 8044, 8045, and 8046. Wherein:

step 8041, determining whether there is process information which is not traversed in the preset third database.

In this embodiment, the execution body may determine whether there is process information that is not traversed in the preset third database. The third database generally stores information about the occurrence of the Native Crash event.

If it is determined that the process information that is not traversed exists in the third database, the execution body may execute step 8042.

In step 8042, if there is process information that is not traversed, the process information that is not traversed is obtained as target process information.

In this embodiment, if it is determined in step 8041 that the process information that is not traversed exists in the third database, the execution subject may acquire the process information that is not traversed as the target process information.

Step 8043, based on the process information and the target process information, determines whether the event indicated by the target process information is the same as the abnormal event.

In this embodiment, the execution body may determine whether the event indicated by the target process information is the same as the abnormal event based on the process information acquired in step 803 and the target process information acquired in step 8042. Here, the execution body may compare the process information and the target process information, determine whether the process information and the target process information match, and if so, determine that the event indicated by the target process information is identical to the abnormal event.

If it is determined that the event indicated by the target process information is the same as the abnormal event, the execution body may execute step 8044.

In step 8044, if the event indicated by the target process information is the same as the abnormal event, the occurrence times and the crash time points of the abnormal event are updated in the third database.

In this embodiment, if it is determined in step 8043 that the event indicated by the target process information is the same as the abnormal event, the execution subject may update the occurrence number of the abnormal event and the crash time point in the third database. Specifically, the execution body may add 1 to the number of occurrences of the abnormal event, and update the crash time point to the crash time point when the current abnormal event occurs.

In step 8045, it is determined whether the occurrence number of the abnormal event is equal to a preset occurrence number threshold.

In this embodiment, the execution body may determine whether the occurrence number of the abnormal event is equal to a preset occurrence number threshold (for example, 3 times).

If it is determined that the occurrence number of the abnormal event is equal to the occurrence number threshold, the execution body may execute step 8046.

Step 8046, if the occurrence frequency threshold is equal to the occurrence frequency threshold, performing log grabbing on the abnormal event.

In this embodiment, if it is determined in step 8045 that the occurrence frequency of the abnormal event is equal to the occurrence frequency threshold, the execution body may perform log grabbing on the abnormal event.

As can be seen from fig. 8, compared with the embodiment corresponding to fig. 1, the flow 800 of the log collection method in this embodiment shows the steps of searching whether the process information which is not traversed exists in the preset third database when the abnormal event is a local crash, determining whether the event indicated by the searched process information is the same as the abnormal event, if so, determining the occurrence times of the abnormal event, and grabbing the log of the abnormal event when the occurrence times are the preset occurrence times threshold. Therefore, according to the scheme described in the embodiment, when the local crash occurs, log grabbing can be performed when the occurrence times of the local crash meet the conditions, so that log grabbing resources are saved.

In some optional implementations, after determining in step 8041 whether there is non-traversed process information in the third database, if it is determined that there is no non-traversed process information, the executing body may store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to a second target value, where the second target value is generally 1. Thereafter, the execution body may determine whether the occurrence number of the abnormal event is equal to a preset occurrence number threshold (e.g., 3 times). If the occurrence frequency of the abnormal event is equal to the occurrence frequency threshold, the execution body may perform log grabbing on the abnormal event.

In some optional implementations, after determining in step 8043 whether the event indicated by the target process information is identical to the abnormal event based on the process information and the target process information, if it is determined that the event indicated by the target process information is not identical to the abnormal event, the execution subject may continue to perform the determining step (i.e., step 8041-step 8046).

In some optional implementations, the execution body may log the exception event by: the execution body may determine the log to be grabbed using a signal value and termination information (Abort message) in the process information.

As an example, if the signal value is 6 (SIGABRT, representing a deadly signal), and the termination information indicates that the virtual memory of the kernel is insufficient, determining the log to be grabbed may include at least one of: log main (log main) files, log event (log event) files, log system (log system) files, log crash (log crash) files, log kernel (log kernel) information, system memory (system memory) information, and system settings (system prop) files.

With further reference to fig. 9, a flow 900 of one embodiment of the determining steps in the log collection method is shown. The flow 900 of the determining step includes the steps of:

Step 901, determining whether there is process information which is not traversed in a preset third database.

In this embodiment, the execution body of the log collection method may determine whether there is process information that is not traversed in the preset third database. The third database generally stores information about the occurrence of the Native Crash event.

If it is determined that the process information that is not traversed exists in the third database, the execution body may execute step 902.

In step 902, if there is process information that is not traversed, the process information that is not traversed is obtained as target process information.

In this embodiment, if it is determined in step 901 that the process information that is not traversed exists in the third database, the execution subject may acquire the process information that is not traversed as the target process information.

Step 903, it is determined whether the process name and the signal value in the process information and the target process information are the same.

Here, when a Native Crash event occurs, a main () function of crash_dump.cpp, in which process information can be acquired, is triggered. The process information may include a process identification number (Process Identification, PID), a process name, a signal value (sign num), termination information (capability message), cause information (cause message), crash stack, and crash time point.

In this embodiment, the execution body may determine whether the process name and the signal value in the process information and the target process information are the same.

If it is determined that the process names and the signal values in the process information and the target process information are the same, the execution body may execute step 904.

Here, the execution body may call notify Process Native Crash () function (a function for notifying the Native Crash process of capturing) to access the System Server process through the binder communication. And calling a System Server process to compare the process information.

If it is determined that the process names and signal values in the process information and the target process information are not the same, the execution body may execute step 908.

Step 904, if the process names and the signal values in the process information and the target process information are the same, determining whether the time interval between the crash time point in the process information and the crash time point in the target process information is greater than a preset second time interval.

In this embodiment, if it is determined in step 903 that the process names and the signal values in the process information and the target process information are the same, the executing body may determine whether the time interval between the crash time point in the process information and the crash time point in the target process information is greater than a preset second time interval (for example, 2 minutes).

If it is determined that the time interval between the crash time point in the process information and the crash time point in the target process information is greater than the second time interval, the execution body may execute step 905.

If it is determined that the time interval between the crash time point in the process information and the crash time point in the target process information is less than or equal to the second time interval, the execution body may execute step 909.

Step 905, if the second time interval is greater than the second time interval, determining whether the termination information and the reason information in the process information and the target process information are the same.

In this embodiment, if it is determined in step 904 that the time interval between the crash time point in the process information and the crash time point in the target process information is greater than the second time interval, the execution body may determine whether the termination information and the cause information in the process information and the target process information are the same.

If it is determined that the termination information and the cause information in the process information and the target process information are the same, the execution subject may execute step 906.

If it is determined that the termination information and the cause information in the process information and the target process information are not identical, the execution body may perform step 910.

Step 906, if the termination information and the cause information in the process information and the target process information are the same, determining whether the crash stacks in the process information and the target process information are the same.

In this embodiment, if it is determined in step 905 that the termination information and the cause information in the process information and the target process information are the same, the execution body may determine whether the crash stack in the process information and the target process information is the same.

If it is determined that the crash stacks in the process information and the target process information are the same, the execution body may execute step 907.

If it is determined that the crash stacks in the process information and the target process information are not identical, the execution body may perform step 911.

In step 907, if the crash stacks in the process information and the target process information are the same, it is determined that the event indicated by the target process information is the same as the abnormal event.

In this embodiment, if it is determined in step 906 that the crash stacks in the process information and the target process information are the same, the execution body may determine that the event indicated by the target process information is the same as the exception event.

Step 908, if the process names and the signal values in the process information and the target process information are different, determining that the event indicated by the target process information is different from the abnormal event, storing the process information of the abnormal event in the third database, and setting the occurrence times of the abnormal event as the second target value.

In this embodiment, if it is determined in step 903 that the process names and signal values in the process information and the target process information are different, the execution subject may determine that the event indicated by the target process information is different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to a second target value, where the second target value is typically 1.

In step 909, if the time interval between the crash time point in the process information and the crash time point in the target process information is less than or equal to the second time interval, it is determined that the event indicated by the target process information is identical to the abnormal event.

In this embodiment, if it is determined in step 904 that the time interval between the crash time point in the process information and the crash time point in the target process information is less than or equal to the second time interval, the execution body may determine that the event indicated by the target process information is the same as the abnormal event.

Step 910, if the termination information and the reason information in the process information and the target process information are different, determining that the event indicated by the target process information is different from the abnormal event, storing the process information of the abnormal event in the third database, and setting the occurrence frequency of the abnormal event as the second target value.

In this embodiment, if it is determined in step 905 that the termination information and the cause information in the process information and the target process information are different, the execution subject may determine that the event indicated by the target process information is different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to a second target value, where the second target value is generally 1.

Step 911, if the crash stacks in the process information and the target process information are different, determining that the event indicated by the target process information is different from the abnormal event, storing the process information of the abnormal event in the third database, and setting the occurrence frequency of the abnormal event as the second target value.

In this embodiment, if it is determined in step 906 that the crash stacks in the process information and the target process information are different, the execution subject may determine that the event indicated by the target process information is different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to a second target value, where the second target value is generally 1.

In step 912, if the event indicated by the target process information is the same as the abnormal event, the occurrence times and the crash time points of the abnormal event are updated in the third database.

In this embodiment, if it is determined in step 907 and step 909 that the event indicated by the target process information is the same as the abnormal event, the execution subject may update the occurrence number of the abnormal event and the crash time point in the third database. Specifically, the execution body may add 1 to the number of occurrences of the abnormal event, and update the crash time point to the crash time point when the current abnormal event occurs.

Step 913, determining whether the occurrence number of the abnormal event is equal to a preset occurrence number threshold.

If it is determined that the occurrence number of the abnormal event is equal to the occurrence number threshold, the execution body may execute step 914.

If the number of occurrences is equal to the threshold, log grabbing is performed on the abnormal event 914.

In this embodiment, if it is determined in step 913 that the occurrence frequency of the abnormal event is equal to the occurrence frequency threshold, the execution body may perform log grabbing on the abnormal event.

According to the method provided by the embodiment of the disclosure, the process information which is not traversed and the process information of the abnormal event are compared through the process identification number, the process name, the signal value, the termination information, the reason information, the crash stack and the crash time point, so that whether the event indicated by the process information which is not traversed is identical to the abnormal event or not is determined, and therefore accuracy of process information comparison is improved.

Fig. 10 illustrates an exemplary system architecture 1000 in which embodiments of the log collection method of the present disclosure may be applied.

As shown in fig. 10, the system architecture 1000 may include terminal devices 10011, 10012, 10013, a network 1002, and a server 1003. The network 1002 serves as a medium for providing communication links between the terminal devices 10011, 10012, 10013 and the server 1003. The network 1002 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user may interact with the server 1003 via the network 1002 using the terminal devices 10011, 10012, 10013 to send or receive messages or the like, for example, the terminal devices 10011, 10012, 10013 may acquire data recorded by the preset first database, the preset second database, and the preset third database from the server 1003. Various communication client applications, such as video-type applications, search engines, instant messaging software, etc., may be installed on the terminal devices 10011, 10012, 10013.

The terminal devices 10011, 10012, 10013 may be hardware or software. When the terminal devices 10011, 10012, 10013 are hardware, they may be various electronic devices having a display screen and supporting information interaction, including but not limited to smartphones, tablets, laptop portable computers, etc. When the terminal devices 10011, 10012, 10013 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., multiple software or software modules for providing distributed services) or as a single software or software module. The present invention is not particularly limited herein.

The terminal devices 10011, 10012, 10013 acquire event types of the abnormal events in response to detecting the abnormal events; then, the occurrence frequency of the abnormal event can be determined; then, log grabbing can be performed on the abnormal event based on the occurrence times and the event types.

The server 1003 may be a server providing various services. For example, it may be a background server that provides the terminal devices 10011, 10012, 10013 with data recorded by the preset first database, the preset second database, and the preset third database.

The server 1003 may be hardware or software. When the server 1003 is hardware, it may be implemented as a distributed server cluster including a plurality of servers, or as a single server. When the server 1003 is software, it may be implemented as a plurality of software or software modules (e.g., to provide distributed services), or as a single software or software module. The present invention is not particularly limited herein.

It should be further noted that, in the log collection method provided by the embodiment of the present disclosure, the log collection device is typically disposed in the terminal devices 10011, 10012, 10013 when the terminal devices 10011, 10012, 10013 generally execute the log collection method.

It should be understood that the number of terminal devices, networks and servers in fig. 10 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With further reference to fig. 11, as an implementation of the method shown in the foregoing figures, the present application provides an embodiment of a log collection device, where an embodiment of the device corresponds to the embodiment of the method shown in fig. 1, and the device may be specifically applied to various electronic devices.

As shown in fig. 11, the log collection device 1100 of the present embodiment includes: an acquisition unit 1101, a determination unit 1102, and a grasping unit 1103. Wherein, the obtaining unit 1101 is configured to obtain an event type of an abnormal event in response to detecting the abnormal event; the determining unit 1102 is configured to determine the occurrence number of the abnormal event; the grabbing unit 1103 is configured to grab the log of the abnormal event based on the occurrence number and the event type.

In the present embodiment, specific processes of the acquisition unit 1101, the determination unit 1102, and the grasping unit 1103 of the log acquisition apparatus 1100 may refer to steps 101, 102, and 103 in the corresponding embodiment of fig. 1.

In some alternative implementations, the event type is an android crash; and the determining unit 1102 is further configured to determine the occurrence number of the abnormal event by: acquiring stack information of the abnormal event, and extracting a process name, detailed information, an abnormal type and a target crash stack from the stack information; determining whether the exception event is a first occurrence based on the process name, the detailed information, the exception type, and the target crash stack.

In some alternative implementations, the target crash stack includes: a first target crash stack and a second target crash stack, wherein the first target crash stack is extracted from a first stage crash stack and the second target crash stack is extracted from a second stage crash stack; and the determining unit 1102 is further configured to determine whether the exception event occurs for the first time based on the process name, the detailed information, the exception type, and the target crash stack in the following manner: screening an abnormal event matched with the abnormal event from a preset first database by using the process name, the first target crash stack and the abnormal type to serve as a target event; determining whether an abnormal event matched with the abnormal event exists in the target event by using the second target crash stack and the detailed information; if no abnormal event matched with the abnormal event exists, determining that the abnormal event occurs for the first time.

In some optional implementations, the foregoing grabbing unit 1103 is further configured to log the abnormal event by: and determining the log to be grabbed by using the anomaly type.

In some alternative implementations, the event type is application no response; and the determining unit 1102 is further configured to determine the occurrence number of the abnormal event by: acquiring target information when an abnormal event occurs; then, based on the target information, it is determined whether the abnormal event is the first occurrence.

In some alternative implementations, the target information includes: presetting the occupation rate of a central processing unit, the occupation rate of input/output waiting time and the residual space of a data partition in response time; and the determining unit 1102 is further configured to determine whether the abnormal event occurs for the first time based on the target information by: determining whether the occupancy rate of the central processing unit is greater than a preset occupancy rate threshold value in response time; if the occupancy rate is greater than the occupancy rate threshold, determining whether the occupancy rate of the input/output waiting time is greater than a preset occupancy rate threshold; if the residual space is larger than the duty ratio threshold value, determining whether the residual space is smaller than a preset space threshold value; if the abnormal event is smaller than the space threshold value, determining the abnormal event as an input/output problem, wherein the abnormal event does not occur for the first time.

In some optional implementations, after determining whether the remaining space is smaller than the preset space threshold, the determining unit 1102 is further configured to obtain the input/output information in the response time if the remaining space is greater than or equal to the space threshold, parse the input/output information, and determine whether a first target process when an abnormal event occurs is the same as a first target process when an input/output problem recorded in a preset second database occurs, where the first target process is determined based on an occupation condition of the central processor when the problem occurs; if the two types of the data are the same, determining that the abnormal event is an input/output problem, wherein the abnormal event does not occur for the first time.

In some optional implementations, after determining whether the first target process is the same as the first target process preset for the existing input/output problem in the second database, the determining unit 1102 is further configured to determine that the abnormal event is an input/output problem if the first target process is not the same, where the abnormal event is the first occurrence; and the grabbing unit 1103 is further configured to log-grab an abnormal event by: and capturing the input/output occupation information of the process of the abnormal event.

In some alternative implementations, after determining whether the duty ratio of the input/output waiting time is greater than the preset duty ratio threshold, the determining unit 1102 is further configured to determine whether a second target process when the abnormal event occurs is the same as a second target process when the cpu load problem recorded in the second database occurs, where the second target process is determined based on the occupancy of the cpu when the problem occurs, if the duty ratio is less than or equal to the duty ratio threshold; if the two types of the abnormal events are the same, determining that the abnormal event is a CPU load problem, wherein the abnormal event does not occur for the first time.

In some optional implementations, after determining whether the second target process when the abnormal event occurs is the same as the second target process when the cpu load problem recorded in the second database occurs, the determining unit 1102 is further configured to determine that the abnormal event is the cpu load problem if the abnormal event is not the same, where the abnormal event is the first occurrence; and the grabbing unit 1103 is further configured to log-grab an abnormal event by: and grabbing the occupation information of the central processing unit.

In some optional implementations, after determining whether the occupancy rate of the cpu is greater than the preset occupancy rate threshold in the response time, the determining unit 1102 is further configured to determine whether the abnormal event is a memory problem if the occupancy rate is less than or equal to the occupancy rate threshold; if the memory problem exists, determining whether the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is smaller than the preset first time interval; if the abnormal event is smaller than the first time interval, determining that the abnormal event is a memory problem, wherein the abnormal event does not occur for the first time.

In some optional implementations, the determining unit 1102 is further configured to determine whether the abnormal event is a memory problem by: determining whether the average residual memory in the response time is smaller than a preset first residual memory threshold value; if the abnormal event is smaller than the first residual memory threshold value, determining the abnormal event as a memory problem.

In some optional implementations, after determining whether the average remaining memory is smaller than the preset first remaining memory threshold in the response time, the determining unit 1102 is further configured to determine whether a preset first case exists if the average remaining memory is greater than or equal to the first remaining memory threshold, where the first case is a preset second case occurring in the response time and the remaining memory when the second case occurs is smaller than the preset second remaining memory threshold, where the second case includes at least one of: running kernel page swap daemon and low memory killing program with use rate not being the first target value; if so, determining the abnormal event as a memory problem.

In some optional implementations, after determining whether the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is smaller than the preset first time interval, the determining unit 1102 is further configured to grasp the memory occupancy information of the process of the abnormal event if the time interval is greater than or equal to the first time interval, and determine, for each memory problem recorded in the second database, whether a third target process when the memory problem occurs is the same as a third target process when the abnormal event occurs, where the third target process is determined based on the memory occupancy condition when the problem occurs; if so, it is determined that the abnormal event does not occur for the first time.

In some optional implementations, after determining, for each memory problem recorded in the second database, whether the third target process when the memory problem occurs and the third target process when the abnormal event occurs are the same, the determining unit 1102 is further configured to determine that the abnormal event occurs for the first time if the first target process and the third target process are different; and the grabbing unit 1103 is further configured to log-grab an abnormal event by: and grabbing the memory occupation information of the process of the abnormal event.

In some optional implementations, after determining whether the preset first situation exists, the determining unit 1102 is further configured to determine whether an abnormal event exists in the second database, where the abnormal event is the same as a process name of the abnormal event, has the same stack information, and is in a non-idle state in the main thread that is not responded by the application program, if the abnormal event does not exist; if so, determining that the abnormal event is a logic problem, wherein the abnormal event does not occur for the first time.

In some optional implementations, after determining whether there is an exception event in the second database that is the same as a process name of the exception event and has the same stack information and the main thread that the application program does not respond to is in a non-idle state, the determining unit 1102 is further configured to determine that the exception event is a logic problem if there is no exception event, and the exception event is the first occurrence.

In some alternative implementations, the event type is a local crash; and the grabbing unit 1103 is further configured to grab the log of the abnormal event based on the occurrence number and the event type in the following manner: acquiring process information of an abnormal event; the following determination steps are performed: determining whether the process information which is not traversed exists in a preset third database; if the process information which is not traversed exists, the process information which is not traversed is obtained as target process information; determining whether an event indicated by the target process information is identical to an abnormal event or not based on the process information and the target process information; if the event indicated by the target process information is the same as the abnormal event, updating the occurrence times and the breakdown time points of the abnormal event in a third database; determining whether the occurrence frequency of the abnormal event is equal to a preset occurrence frequency threshold value; and if the occurrence frequency threshold value is equal to the occurrence frequency threshold value, performing log grabbing on the abnormal event.

In some alternative implementations, the process information includes a process identification number, a process name, a signal value, termination information, cause information, a crash stack, and a crash time point; and the foregoing grabbing unit 1103 is further configured to determine, based on the process information and the target process information, whether the event indicated by the target process information is the same as the abnormal event, by: determining whether the process names and the signal values in the process information and the target process information are the same; if the time intervals are the same, determining whether the time interval between the breakdown time point in the process information and the breakdown time point in the target process information is larger than a preset second time interval or not; if the time interval is larger than the second time interval, determining whether the termination information and the reason information in the process information and the target process information are the same; if so, determining whether the crash stacks in the process information and the target process information are the same; if the event indicated by the target process information is the same as the abnormal event, the event indicated by the target process information is determined to be the same as the abnormal event.

In some optional implementations, after determining whether the process names and the signal values in the process information and the target process information are the same, the capturing unit 1103 is further configured to determine that the event indicated by the target process information is different from the abnormal event if the process names and the signal values are different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to the second target value.

In some optional implementations, after determining whether the time interval between the crash time point in the process information and the crash time point in the target process information is greater than a preset second time interval, the capturing unit 1103 is further configured to determine that the event indicated by the target process information is the same as the abnormal event if the time interval is less than or equal to the second time interval.

In some optional implementations, after determining whether the termination information and the reason information in the process information and the target process information are the same, the capturing unit 1103 is further configured to determine that the event indicated by the target process information is different from the abnormal event if the termination information and the reason information are different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to the second target value.

In some optional implementations, after determining whether the crash stacks in the process information and the target process information are the same, the grabbing unit 1103 is further configured to determine that the event indicated by the target process information is different from the abnormal event if the crash stacks are different from the abnormal event, store the process information of the abnormal event in the third database, and set the occurrence number of the abnormal event to the second target value.

In some optional implementations, after determining whether there is process information that is not traversed in the preset third database, the capturing unit 1103 is further configured to store the process information of the abnormal event in the third database and set the occurrence number of the abnormal event to the second target value if there is no process information that is not traversed; determining whether the occurrence frequency of the abnormal event is equal to a preset occurrence frequency threshold value; and if the occurrence frequency threshold value is equal to the occurrence frequency threshold value, performing log grabbing on the abnormal event.

In some alternative implementations, after determining, based on the process information and the target process information, whether the event indicated by the target process information is the same as the abnormal event, the capturing unit 1103 is further configured to continue to perform the determining step if the event indicated by the target process information is not the same as the abnormal event.

In some optional implementations, the foregoing grabbing unit 1103 is further configured to log the abnormal event by: and determining the log to be grabbed by using the signal value and the termination information in the process information.

In some alternative implementations, the event type is that the boot animation is stuck; and the abnormal event that the startup animation is stuck is detected by: and in response to detecting that the starting-up animation ending notification is not received within a preset first duration from a target time point, determining that the abnormal event that the starting-up animation is blocked is detected, wherein the target time point is the time point when the starting-up notification is received, and the starting-up notification is the notification sent when the starting-up animation starts.

In some alternative implementations, the event type is that the boot animation is stuck; and the abnormal event that the startup animation is stuck is detected by: and in response to detecting that the target process generates restarting operation for a preset number of times within a preset second time period, determining that the event that the startup animation is blocked is detected, wherein the target process is a system server process or a parent process for hatching a non-local process.

In some optional implementations, the foregoing grabbing unit 1103 is further configured to log the abnormal event by: and carrying out log grabbing on the abnormal event by using a target specimen local process, wherein the target specimen local process is used for grabbing the log.

A schematic structural diagram of an electronic device (e.g., the terminal device of fig. 10) 1200 suitable for use in implementing embodiments of the present disclosure is shown below with reference to fig. 12. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), car terminals (e.g., car navigation terminals), and the like, and stationary terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 12 is merely an example, and should not impose any limitations on the functionality and scope of use of embodiments of the present disclosure.

As shown in fig. 12, the electronic apparatus 1200 may include a processing device (e.g., a central processor, a graphics processor, etc.) 1201, which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 1202 or a program loaded from a storage device 1208 into a Random Access Memory (RAM) 1203. In the RAM 1203, various programs and data required for the operation of the electronic apparatus 1200 are also stored. The processing device 1201, the ROM 1202, and the RAM 1203 are connected to each other through a bus 1204. An input/output (I/O) interface 1205 is also connected to the bus 1204.

In general, the following devices may be connected to the I/O interface 1205: input devices 1206 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 1207 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; and a communication device 1209. The communication means 1209 may allow the electronic device 1200 to communicate wirelessly or by wire with other devices to exchange data. While fig. 12 shows an electronic device 1200 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 12 may represent one device or a plurality of devices as needed.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via the communication device 1209, or installed from the storage device 1208, or installed from the ROM 1202. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing device 1201. It should be noted that, the computer readable medium according to the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In an embodiment of the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.

The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to detecting an abnormal event, acquiring an event type of the abnormal event; determining the occurrence times of the abnormal events; and carrying out log grabbing on the abnormal event based on the occurrence times and the event types.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes an acquisition unit, a determination unit, and a grasping unit. The names of these units do not constitute a limitation of the unit itself in some cases, and the determination unit may also be described as "a unit that determines the occurrence number of the abnormal event", for example.

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A log collection method, comprising:

in response to detecting an abnormal event, acquiring an event type of the abnormal event;

determining the occurrence times of the abnormal events;

and carrying out log grabbing on the abnormal event based on the occurrence times and the event type.

2. The method of claim 1, wherein the event type is an android crash; and

the determining the occurrence times of the abnormal event comprises the following steps:

acquiring stack information of the abnormal event, and extracting a process name, detailed information, an abnormal type and a target crash stack from the stack information;

Determining whether the exception event is a first occurrence based on the process name, the detailed information, the exception type, and the target crash stack.

3. The method of claim 2, wherein the target crash stack comprises: a first target crash stack and a second target crash stack, wherein the first target crash stack is extracted from a first stage crash stack and the second target crash stack is extracted from a second stage crash stack; and

the determining whether the exception event is the first occurrence based on the process name, the detailed information, the exception type, and the target crash stack includes:

screening an abnormal event matched with the abnormal event from a preset first database by using the process name, the first target crash stack and the abnormal type as a target event;

determining whether an abnormal event matched with the abnormal event exists in the target event by using the second target crash stack and the detailed information;

and if no abnormal event matched with the abnormal event exists, determining that the abnormal event occurs for the first time.

4. The method of claim 2, wherein the logging the exception event comprises:

and determining the log to be grabbed by utilizing the anomaly type.

5. The method of claim 1, wherein the event type is application no response; and

acquiring target information when the abnormal event occurs;

based on the target information, determining whether the abnormal event occurs for the first time.

6. The method of claim 5, wherein the target information comprises: presetting the occupation rate of a central processing unit, the occupation rate of input/output waiting time and the residual space of a data partition in response time; and

the determining whether the abnormal event occurs for the first time based on the target information includes:

determining whether the occupancy rate of the central processing unit in the response time is greater than a preset occupancy rate threshold;

if the occupancy rate is greater than the occupancy rate threshold, determining whether the occupancy rate of the input/output waiting time is greater than a preset occupancy rate threshold;

if the residual space is larger than the duty ratio threshold, determining whether the residual space is smaller than a preset space threshold;

If the abnormal event is smaller than the space threshold value, the abnormal event is determined to be an input/output problem, and the abnormal event does not occur for the first time.

7. The method of claim 6, wherein after said determining whether said remaining space is less than a preset space threshold, said method further comprises:

if the space threshold value is greater than or equal to the space threshold value, acquiring input/output information in the response time, analyzing the input/output information, and determining whether a first target process when the abnormal event occurs is the same as a first target process when an input/output problem recorded in a preset second database occurs, wherein the first target process is determined based on the occupation condition of a central processing unit when the problem occurs;

if the abnormal events are the same, determining the abnormal events as input/output problems, wherein the abnormal events do not occur for the first time.

8. The method of claim 7, wherein after said determining whether the first target process is the same as the first target process that presets an existing input/output problem in the second database, the method further comprises:

if the abnormal events are different, determining the abnormal events as input/output problems, wherein the abnormal events occur for the first time; and

The log grabbing of the abnormal event includes:

and grabbing the input/output occupation information of the process of the abnormal event.

9. The method of claim 6, wherein after said determining whether the duty cycle of the input/output latency is greater than a preset duty cycle threshold, the method further comprises:

if the duty ratio threshold value is smaller than or equal to the duty ratio threshold value, determining whether a second target process when the abnormal event occurs is the same as a second target process when the central processing unit load problem recorded in the second database occurs, wherein the second target process is determined based on the occupation condition of the central processing unit when the problem occurs;

if the abnormal events are the same, determining that the abnormal events are central processing unit load problems, wherein the abnormal events do not occur for the first time.

10. The method of claim 9, wherein after said determining whether a second target process at which said exception event occurred is the same as a second target process at which a central processor load problem recorded in said second database occurred, said method further comprising:

if the abnormal events are different, determining that the abnormal events are central processing unit load problems, wherein the abnormal events occur for the first time; and

The log grabbing of the abnormal event includes:

and grabbing the occupation information of the central processing unit.

11. The method of claim 6, wherein after said determining whether a central processor occupancy is greater than a preset occupancy threshold within said response time, said method further comprises:

if the occupancy rate threshold is smaller than or equal to the occupancy rate threshold, determining whether the abnormal event is a memory problem;

if the memory problem exists, determining whether the time interval between the occurrence time of the memory problem recorded in the second database and the occurrence time of the abnormal event is smaller than a preset first time interval or not;

if the abnormal event is smaller than the first time interval, determining that the abnormal event is a memory problem, wherein the abnormal event does not occur for the first time.

12. The method of claim 11, wherein determining whether the exception event is a memory problem comprises:

determining whether the average residual memory in the response time is smaller than a preset first residual memory threshold;

and if the abnormal event is smaller than the first residual memory threshold value, determining that the abnormal event is a memory problem.

13. The method of claim 12, wherein after said determining whether the average remaining memory within the response time is less than a preset first remaining memory threshold, the method further comprises:

If the first remaining memory threshold is greater than or equal to the first remaining memory threshold, determining whether a preset first condition exists, wherein the first condition is that a preset second condition occurs in the response time and the remaining memory when the second condition occurs is less than a preset second remaining memory threshold, and the second condition comprises at least one of the following: running kernel page swap daemon and low memory killing program with use rate not being the first target value;

if so, determining the abnormal event as a memory problem.

14. The method of claim 11, wherein after said determining whether a time interval between an occurrence time of a memory problem recorded in said second database and an occurrence time of said abnormal event is less than a preset first time interval, said method further comprises:

if the first time interval is greater than or equal to the first time interval, capturing memory occupation information of a process of the abnormal event, and determining whether a third target process when the memory problem occurs is the same as a third target process when the abnormal event occurs according to each memory problem recorded in the second database, wherein the third target process is determined based on the memory occupation condition when the problem occurs;

If so, it is determined that the abnormal event does not occur for the first time.

15. The method of claim 14, wherein after determining, for each memory problem recorded in the second database, whether a third target process at which the memory problem occurred is the same as a third target process at which the exception event occurred, the method further comprises:

if the abnormal events are different, determining that the abnormal events occur for the first time; and

the log grabbing of the abnormal event includes:

and grabbing the memory occupation information of the process of the abnormal event.

16. The method of claim 13, wherein after said determining whether a preset first condition exists, the method further comprises:

if not, determining whether an abnormal event which is the same as the process name of the abnormal event and the stack information is the same and the main thread of which the application program does not respond is in a non-idle state exists in the second database;

if so, determining that the abnormal event is a logic problem, wherein the abnormal event does not occur for the first time.

17. The method of claim 16, wherein after said determining whether there is an exception event in the second database that is the same as a process name of the exception event and that has the same stack information and that is non-idle for a main thread to which the application is unresponsive, the method further comprises:

If the abnormal event does not exist, determining the abnormal event as a logic problem, wherein the abnormal event occurs for the first time.

18. The method of claim 1, wherein the event type is a local crash; and

the log grabbing of the abnormal event based on the occurrence times and the event type includes:

acquiring process information of the abnormal event;

the following determination steps are performed: determining whether the process information which is not traversed exists in a preset third database; if the process information which is not traversed exists, the process information which is not traversed is obtained as target process information; determining whether an event indicated by the target process information is identical to the abnormal event or not based on the process information and the target process information; if the event indicated by the target process information is the same as the abnormal event, updating the occurrence times and the breakdown time points of the abnormal event in the third database; determining whether the occurrence times of the abnormal events are equal to a preset occurrence times threshold value; and if the occurrence frequency threshold value is equal to the occurrence frequency threshold value, performing log grabbing on the abnormal event.

19. The method of claim 18, wherein the process information includes a process identification number, a process name, a signal value, termination information, cause information, a crash stack, and a crash time point; and

The determining, based on the process information and the target process information, whether the event indicated by the target process information is the same as the abnormal event includes:

determining whether the process names and the signal values in the process information and the target process information are the same;

if the time intervals are the same, determining whether the time interval between the breakdown time point in the process information and the breakdown time point in the target process information is larger than a preset second time interval or not;

if the second time interval is larger than the second time interval, determining whether the termination information and the reason information in the process information and the target process information are the same;

if so, determining whether the crash stacks in the process information and the target process information are the same;

and if so, determining that the event indicated by the target process information is the same as the abnormal event.

20. The method of claim 19, wherein after said determining if the process name and signal value in the process information and the target process information are the same, the method further comprises:

if the event indicated by the target process information is different from the abnormal event, determining that the event indicated by the target process information is different from the abnormal event, storing the process information of the abnormal event into the third database, and setting the occurrence frequency of the abnormal event as a second target value.

21. The method of claim 19, wherein after said determining whether a time interval between a crash time point in the process information and a crash time point in the target process information is greater than a preset second time interval, the method further comprises:

and if the time interval is smaller than or equal to the second time interval, determining that the event indicated by the target process information is identical to the abnormal event.

22. The method according to claim 19, wherein after said determining whether termination information and cause information in said process information and said target process information are the same, the method further comprises:

23. The method of claim 19, wherein after said determining if the crash stacks in the process information and the target process information are the same, the method further comprises:

24. The method of claim 18, wherein after said determining whether there is unremoved process information in the preset third database, the method further comprises:

if the process information which is not traversed does not exist, the process information of the abnormal event is stored in the third database, and the occurrence frequency of the abnormal event is set to be a second target value;

determining whether the occurrence times of the abnormal events are equal to a preset occurrence times threshold value;

and if the occurrence frequency threshold value is equal to the occurrence frequency threshold value, performing log grabbing on the abnormal event.

25. The method of claim 18, wherein after said determining, based on said process information and said target process information, whether an event indicated by said target process information is the same as said exception event, said method further comprises:

and if the event indicated by the target process information is not the same as the abnormal event, continuing to execute the determining step.

26. The method of claim 18, wherein said logging said exception event comprises:

and determining the log to be grabbed by utilizing the signal value and the termination information in the process information.

27. The method of claim 1, wherein the event type is a power-on animation stuck; and

the abnormal event that the startup animation is blocked is detected by the following method:

and in response to detecting that the starting-up animation ending notification is not received within a preset first duration from a target time point, determining that the abnormal event that the starting-up animation is blocked is detected, wherein the target time point is the time point when the starting-up notification is received, and the starting-up notification is the notification sent when the starting-up animation is started.

28. The method of claim 1, wherein the event type is a power-on animation stuck; and

and in response to detecting that the target process generates restarting operation for a preset number of times within a preset second time period, determining that the event that the startup animation is blocked is detected, wherein the target process is a system server process or a parent process for hatching a non-local process.

29. The method of claim 1, wherein the logging the exception event comprises:

and carrying out log grabbing on the abnormal event by using a target specimen local process, wherein the target specimen local process is used for grabbing the log.

30. A log collection device, comprising:

an acquisition unit configured to acquire an event type of an abnormal event in response to detection of the abnormal event;

a determining unit configured to determine the occurrence number of the abnormal event;

and the grabbing unit is used for grabbing the log of the abnormal event based on the occurrence times and the event type.

31. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-29.

32. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-29.