Log storage failure management method and electronic equipment

Abstract

The invention discloses a log storage failure management method and electronic equipment. The method comprises the following steps of: identifying whether a log storage failure condition exists or not based on a write-in condition (such as speed) that a log is written into a log storage space, and if the log storage failure condition exists, recovering normal write-in of the log by executing a failure processing operation. Through the scheme of the embodiment, the loss of log records can be reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the computer technology field, and in particular, to a log storage failure management method and electronic equipment. BACKGROUND

[0002] In the automobile electronics, such as in the electronic products of HPC (High Performance Computer), the various logs (Log) generated in the entire electronic product are generally managed by a program named Log master. The management of the Log master on the logs includes, for example, storing the logs to a specified location, classifying and packaging the logs, and deleting the expired logs, etc. However, in the frequent use process of the Log master, the problem of log storage failure, i.e. log record loss, may occur. In view of this, the Log master will perform self-monitoring internally, i.e. monitoring whether the thread for storing the logs is abnormal. In addition, at the system level, the Log master is also monitored based on the health management mode of "heartbeat". However, even so, the inventors of the present application have observed the situation of log loss, i.e. log storage failure, in actual application, and therefore, the existing scheme needs to be improved. SUMMARY

[0003] Therefore, the present application provides a log storage failure management method and electronic equipment, which can improve the problem of log loss.

[0004] The log storage failure management method of the present application comprises: based on the writing condition of the logs being written into the log storage space, identifying whether there is a log storage failure situation, and if there is, performing a failure handling operation to restore the normal writing of the logs.

[0005] In some embodiments, the writing condition comprises: the writing speed of the logs being written into the log storage space; and when the writing speed is less than a preset speed threshold and the duration reaches a preset time threshold, there is the log storage failure situation.

[0006] In some embodiments, the log manager is responsible for writing the logs into the log storage space, and when the log storage failure situation is identified based on the writing condition, the log manager is restarted.

[0007] In some embodiments, when the restart reaches a preset limit, the function of the log manager is taken over and the log manager is not restarted, and a "shutdown" operation is instructed to be performed when the system enters hibernation, the system being set by default to perform a "suspend to RAM" operation when entering hibernation.

[0008] In some embodiments, after taking over the function of the log manager, if the log storage failure condition still exists based on the write condition, all log management related components are restarted, the core where the log manager is located is restarted, or the core where the log manager is located is restarted after all log management related components are restarted.

[0009] In some embodiments, the method further comprises monitoring a log storage thread inside the log manager, and restarting the log storage thread when the log storage thread is found to be abnormal.

[0010] In some embodiments, the log manager is monitored for abnormality based on the reporting of the "heartbeat" data of the log manager, and the log manager is restarted when the log manager is found to be abnormal.

[0011] An electronic device according to an embodiment of the present application comprises a core having a log management function, the core comprising a non-volatile memory, a log manager configured to write logs generated by the electronic device during operation into the non-volatile memory, and a storage management module configured to monitor a write rate of the log manager in writing the logs into the non-volatile memory, and to control the log manager according to the write rate.

[0012] In some embodiments, the storage management module is specifically configured to restart the log manager when the write rate is less than a preset first rate threshold and a duration is greater than a preset first time threshold.

[0013] In some embodiments, the storage management module is further configured to, when the number of restarts is greater than a preset number threshold, not restart the log manager, and instruct a "shutdown" operation to be performed when the core enters hibernation, the core being set by default to perform a "suspend to RAM" operation when entering hibernation.

[0014] In some embodiments, the storage management module is further configured to, when the log manager fails, write the logs into the non-volatile memory, and identify whether a log storage failure condition exists based on a write rate of the storage management module in writing the logs into the non-volatile memory, and if the log storage failure condition exists, restart all log management related components including the log manager, and if the log storage failure condition still exists after the restart, restart the core.

[0015] A computer device / system of an embodiment of the present application comprises a memory, a processor and a computer program stored on the memory, the processor executing the computer program to implement the steps of any of the methods of the embodiments of the present application.

[0016] A computer readable storage medium of an embodiment of the present application has a computer program / instruction stored thereon, the computer program / instruction being executed by a processor to implement the steps of any of the methods of the embodiments of the present application.

[0017] The embodiments of the present application have the following beneficial effects:

[0018] The embodiments of the present application directly judge whether there is a log storage failure situation based on the writing situation (e.g., writing rate) of the log being written into the log storage space, i.e., whether the log is normally stored. In this way, whether there is a log storage failure situation is directly judged by observing the writing situation of the log into the storage space, and the corresponding repair processing operation is performed, so it is not affected by the log manager's own monitoring scheme, and the problem of log loss (incomplete record) caused by the lack of the log manager's own monitoring scheme can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0019] Other details and advantages of the present application will become apparent from the detailed description provided below. It should be understood that the following drawings are merely schematic and therefore cannot be considered limiting of the present application, which will be described in detail below with reference to the attached drawings, wherein:

[0020] Figure 1A is a structural schematic diagram of an embodiment of the electronic device of the present application;

[0021] Figure 1B is a structural schematic diagram of another embodiment of the electronic device of the present application;

[0022] Figure 2 is a flowchart of an embodiment of the log storage failure management method of the present application;

[0023] Figure 3 is a flowchart of another embodiment of the log storage failure management method of the present application;

[0024] Figure 4 is a flowchart of another embodiment of the log storage failure management method of the present application;

[0025] Figure 5 is a flowchart of another embodiment of the log storage failure management method of the present application;

[0026] Figure 6 is a flowchart of another embodiment of the log storage failure management method of the present application;

[0027] Figure 7 is a flowchart of another embodiment of the method for managing log storage failure of the present application;

[0028] Figure 8 is a flowchart of another embodiment of the method for managing log storage failure of the present application;

[0029] Figure 9 is a structural diagram of an embodiment of a computer device / system capable of executing the method flow of the present application. DETAILED DESCRIPTION

[0030] In order to make the technical problems to be solved by the present application, technical solutions and beneficial effects more clear, specific embodiments will be described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, and are not intended to limit the present application.

[0031] In the description of the present application, it should be understood that the terms "first", "second" are only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features limited by "first", "second" can be explicitly or implicitly included one or more of the features. Moreover, the terms "first", "second" and the like are applicable to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged as appropriate, so that the embodiments of the application described herein can be implemented in an order other than those illustrated or described herein.

[0032] In automotive electronics, product development and design are generally based on the AUTOSAR (Automotive Open System Architecture) standard, such as developing HPC (High Performance Computer) products that meet the AUTOSAR standard to serve as electronic devices or products such as central gateways or central computing units in vehicles, other electronic devices or products include domain controllers, regional controllers or ECUs (Electronic Control Units), etc., which are not described here. In the AUTOSAR standard, the LogMaster module is used to manage logs, such as recording system logs, application logs, etc. in flash memory (e.g. EMMC, i.e. embedded multimedia card), packing and classifying logs, deleting expired logs, etc. It should be noted that in other standards or architectures, there are also modules similar to the log manager, and the solutions of the embodiments of the present application introduced below can also be applicable.

[0033] In the use of the log manager, it is inevitable that the log storage fails due to core freezing, resource shortage, excessive load and other factors, i.e. the logs of a certain time period are not recorded, which is obviously not expected by product developers. Therefore, in some embodiments, by monitoring the log storage thread in the log manager, such as the scheme of Figure 2 , and / or, by health management of the log manager, such as the scheme of Figure 3 , the abnormality of the log storage thread and the log manager can be found in time and repaired, so as to avoid the missing of log recording.

[0034] Specifically, in Figure 2 , thread 1 is a log storage thread, and thread 2 is a monitoring thread specially used for monitoring thread 1. When the log manager is running, thread 1 reports checkpoint information to thread 2 (step S202) after storing the log each time (step S201), thread 2 monitors thread 1 according to the checkpoint information reported by thread 1 (step S203), and judges whether thread 1 is abnormal (step S204) according to the checkpoint information. For example, if no checkpoint information is received within a set time or the number of received checkpoint information is insufficient, it is determined that thread 1 is abnormal. When thread 1 is abnormal, the repair is completed by restarting thread 1 (step S206) and the like. Further, the number of restarts can be controlled by step S205, for example, thread 1 is restarted only within a preset restart number threshold, so as to avoid thread 1 being restarted repeatedly.

[0035] In Figure 3 , it is a health management method based on "heartbeat". The log manager is registered with the PHM (Platform Health Management, platform health management module) to establish a "heartbeat" link, and the log manager reports "heartbeat" data at regular intervals (step S301). The PHM judges whether the log manager is abnormal (step S202) based on the reception of the "heartbeat" data. When it is judged that the log manager is abnormal, the log manager is restarted by the EM (Execution Management, execution management module) (steps S303 and 304). The PHM and the EM are both modules involved in AUTOSAR, and their related definitions and functions are familiar to those skilled in the art. The health management method based on "heartbeat" is also familiar to those skilled in the art, and will not be described here.

[0036] By Figure 2 and 3In this way, the log storage failure can be monitored at the thread level and the system level. However, the inventors of the present application have observed some missing log records in practical applications without monitoring the log storage thread exception or the log manager exception, and therefore the above monitoring method needs to be improved and perfected.

[0037] The present application provides a log storage failure management scheme. In the scheme, whether there is a log storage failure situation is identified from the writing condition of the logs into the log storage space, and if the log storage failure situation is identified, a failure handling operation is performed to restore the normal writing of the logs. Specifically, the inventors of the present application have analyzed the data of the electronic device and found that the electronic device generates a large amount of logs in real time during normal use, and therefore the log manager writes a large amount of logs into the log storage space (such as flash memory) in real time, which means that under normal circumstances, the writing rate (speed) of the log manager into the log storage space is maintained above a certain speed value for a long time. Therefore, this point can be used to monitor the writing condition of the logs into the log storage space, and when the writing condition shows that the log writing rate is slow, it can be determined that the log storage failure occurs, and therefore the related processing operation such as restarting can be performed without worrying about which level or what causes the log storage failure. With this method, the monitoring of the log storage failure can be further improved, and the missing log records can be avoided as much as possible. Moreover, this method can be used together with the methods shown in Figure 2 and 3 , so that the system can more comprehensively monitor the log storage failure and further avoid the missing log records. The scheme of the present application will be described in detail below in combination with examples.

[0038] As shown in Figure 1A and 1B , it is a structure schematic diagram of an embodiment of an electronic device 1. The log storage failure management scheme of the present embodiment can be applied to, but is not limited to, the electronic device shown in Figure 1A and 1B .

[0039] Specifically, as shown in Figure 1AAs shown, the log storage failure management scheme of the embodiment mainly involves the log manager 101, the storage manager 102 and the non-volatile storage 103 in the core 10. Among them, the log manager 101 is responsible for the management of the log as described above. The storage manager (IOST) 102 can control the reading and writing of the non-volatile storage 103 by various modules in the core 10, generally only calculates the reading and writing speed of the non-volatile storage 103 by various modules, and records it. In this embodiment, the storage manager 102 can monitor whether the log storage fails based on the rate of writing the non-volatile storage 103 by the log manager 101. And when it monitors the log storage failure, it temporarily takes over the log storage function; or, when the log manager is difficult to recover, it completely (permanently) takes over the log storage function until the next core restart. The non-volatile storage 103 is used to store the log, for example, it can be a flash memory in the core 10, such as an EMMC (Embedded Multi-Media Card). The non-volatile storage 103 can be an implementation of the above-mentioned log storage space.

[0040] As Figure 1B shown, is a structural schematic diagram of an embodiment of a multi-core electronic device 1. The electronic device 1 includes two cores, core 10 and core 20, of course, there can be more cores in practice. Among them, the core 10 is generally an A core, and the core 20 is generally an M core, wherein the A core is generally developed based on the Adaptive AUTOSAR standard, and the M core is generally developed based on the Classic AUTOSAR standard, of course, these are only examples and not a limitation of the embodiments of the present application. As Figure 1B shown, in addition to the log storage failure management scheme of the embodiment of the present application involving the log manager 101, the storage manager 102 and the non-volatile storage 103, it can also involve the PM (Power Master, power manager) 201, the HM (Health Management, health management module) 202 in the core 20, and the SPMC (slave power management client) 104, the LHM (Local Health Management, local health management module) 105, the PHM 106 and the EM 107 in the core 10. Among them, the PM 201 and the SPMC 104 together manage the power of the core 10, and will be used when the core 10 is restarted. The HM 202 and the LHM 105 are used together to manage the restart of the core 10, generally the LHM 105 notifies the HM 202 to restart the core 10. The PHM 106 is responsible for the health monitoring of the log manager 102. The EM 107 is used to execute the restart of the log manager 101 or other modules.

[0041] In Figure 1A and1B In this architecture, the log storage failure management scheme based on log write activity is primarily deployed in storage manager 102. Storage manager 102 can work with other modules to perform repair operations such as restarting when log storage failure is detected. Alternatively, this log storage failure management scheme can also be deployed in other modules, obtaining information such as the log manager 101's write rate to the log storage space from storage manager 102 or a module with similar functionality, and monitoring accordingly. This will not be elaborated upon here. Furthermore, Figure 2 The log storage failure management solution shown can be deployed in Log Manager 101. Figure 3 The log storage failure management solution shown can be deployed in PHM106.

[0042] The following is combined Figures 4-8 This paper describes a log storage failure management scheme based on log write status according to an embodiment of the present invention.

[0043] like Figure 4 The diagram shown is a flowchart of an embodiment of the log storage failure management method of the present invention. The method includes the following steps:

[0044] Step S401: Monitor the writing status of logs to the log storage space.

[0045] Step S402: Based on the monitored write activity, determine if there is a log storage failure. If so, proceed to step S403; otherwise, return to step S401 to continue monitoring.

[0046] Step S403: Perform a failure handling operation to restore normal log writing.

[0047] In step S401, when the log manager writes logs to the log storage space, the write status of the log manager writing logs to the log storage space can be obtained. In some embodiments, when the log manager completely fails, the storage management module completely takes over the work of the log manager, and in this case, the write status of the storage management module writing logs to the log storage space can be obtained.

[0048] In step S401, the write status can be, for example, the speed at which logs are written to the log storage space. Taking the log manager as an example, when writing logs normally, its write speed is generally greater than a certain threshold, which can be obtained through testing and long-term observation. Therefore, when the write speed is lower than the threshold and persists for a certain period of time, it is very likely that the log manager is experiencing log writing anomalies. Alternatively, the write status can also refer to the amount of data written to the log storage space within a certain period of time. When it is detected that the amount of data written to the log storage space by the log manager within a preset time is lower than a preset data volume threshold, the log storage can be considered to be ineffective.

[0049] In step S403, the executed failure handling operation can be a restart operation, for example. For example, the log manager can be restarted to solve the problem of log storage failure. However, if the problem cannot be solved by multiple restarts, continued restarts will become meaningless, and therefore the failure handling operation can further include: when the number of restarts reaches a limit, instructing the system to perform a "shutdown" operation when the system enters hibernation. Generally, the system is by default set to perform a "Suspend to RAM (S2R)" operation when entering hibernation, so that the system can be quickly awakened. However, the S2R operation cannot solve the log manager exception, and therefore when the number of restarts reaches the limit, the system can be instructed to perform a shutdown procedure when it next enters hibernation to solve the problem of the log manager exception. In addition, because the storage manager 102 can take over the relevant functions when the log manager exception cannot be recovered, there is no need to immediately perform a shutdown restart in order to minimize the impact on user experience as much as possible, but rather to perform it when the system next enters hibernation.

[0050] The present embodiment manages log storage failure by observing the writing of logs into the log storage space, so that log storage failure can be discovered in a timely manner when the log manager has some failure conditions that are not monitored, so that it can be repaired. The present embodiment determines the cause of log storage failure by observing the writing of logs, on the one hand, the present inventors realized that the log storage failure management solutions such as Figure 2 and 3 have shortcomings, i.e. in the case of Figure 2 and 3 , it is still possible for log storage failure to occur due to unknown reasons, and therefore the present inventors first realized that there is room for improvement and a need for solutions such as Figure 2 and 3 . On the other hand, based on a large amount of analysis of data for products such as HPC, the present inventors found that when these products are running normally, a large amount of logs will be generated, and the log manager will process a large amount of log data in real time, so that there is almost no situation in which the log manager has no logs to process for a long time, and therefore the speed at which the log manager writes to the log storage space will not be too low, and based on this, the speed at which logs are written to the log storage space can be monitored to directly determine whether there is log storage failure, regardless of the specific cause of the failure.

[0051] As shown in Figure 5 , it is a flowchart of another embodiment of the log storage failure management method of the present application. In Figure 5In the electronic product, because the time when each module is started is different, the module monitoring the log manager can be completed before the log manager, at this time, if the monitoring scheme is directly executed, the log storage can be misjudged as invalid because the log manager has not been completed, and the log manager is repeatedly restarted, resulting in chaotic functions. Therefore, after the system is started, the data amount of the log manager writing the log storage space is calculated (step S501), when the data amount of the log manager writing the log storage space in a certain time is greater than the preset data amount threshold (step S502), it is indicated that the log manager has been started and begins to work, and the monitoring of the log manager writing the log storage space is started (step S503), wherein the specific monitoring method or principle can be referred to Figure 4 The description of the embodiment.

[0052] As Figure 6 shown, it is a flowchart of another embodiment of the log storage invalidation management method of the present application. In Figure 6 the embodiment, whether the log is stored invalidly is managed by monitoring the speed of the log manager writing the log storage space (step S601). When the speed of the log manager writing the log storage space is less than the preset speed threshold for a period of time (step S602), the log storage invalidation is managed by restarting the log manager (step S603). In the embodiment, the preset speed can be 10 KB / s, and the preset time can be 5 seconds or 7 seconds, and the specific values of these parameters can be set in advance based on experience or test. In addition, because the scheme of the embodiment can be used in combination with the schemes of Figure 2 and 3 , when the abnormality is monitored, whether the log manager has exited is further determined, if the similar notification is received, the flowchart of the embodiment can not be further processed, but the flowchart of the embodiment 1 or 3 is processed. In the embodiment, Figure 6 or 3, when the abnormality is detected and repaired, the storage manager 102 is notified that the log manager temporarily exits the log management function. Figure 2 Figure 2

[0053] As Figure 7 shown, it is a flowchart of another embodiment of the log storage invalidation management method of the present application. In Figure 7 the embodiment, first, the speed of the log manager writing the log storage space is monitored based on the similar method of Figure 6 , and when the abnormality of writing the log storage space is monitored, the log manager is restarted 702. On this basis, Figure 7 ​​The solution further controls the number of restarts, because if multiple restarts still fail to resolve the issue, then restarting is pointless. Therefore, in Figure 7 In this process, if it is detected that the log manager's write speed to the log storage space is consistently lower than a preset rate, and the duration exceeds a preset time threshold, and the number of restarts has exceeded a preset number threshold (step S703), then the process abandons further restarting of the log manager and instructs the system to perform a "shutdown" operation instead of an "S2R" operation during system hibernation (step S704). In this embodiment, the preset rate threshold or time threshold may be different from... Figure 6 The rate threshold or time threshold in the embodiments, for example, in Figure 6 The time threshold can be 5 seconds, while Figure 7 The time threshold may be 30 seconds. In this embodiment, the system defaults to performing an "S2R (Suspend to Memory)" operation during hibernation. This means that when the system hibernates, data from modules such as the log manager and storage manager is saved to memory instead of being completely powered off, thus enabling rapid wake-up. Figure 7 In the proposed solution, when the condition in step S703 is met, a cold start can be used to resolve the log manager's storage problem upon the next wake-up. Figure 7 In the process, choosing to perform the repair operation at the next wake-up from hibernation can reduce the impact on the current situation. Figure 7 This scenario typically occurs when HPC and other devices are in operation; in other words, the vehicle is in motion, and immediately powering off and restarting it would negatively impact the user experience.

[0054] like Figure 8 The diagram shown is a flowchart illustrating another embodiment of the log storage failure management method of the present invention. Figure 8 In the middle, when the log manager completely malfunctions, for example Figure 7In the case shown, the log function of the log manager can be taken over by the storage manager 102, i.e. the log generated in the system operation is written into the log storage space (steps S801 and S802). At this time, the monitoring of the log storage exception is mainly monitoring whether the writing of the log into the log storage space by the storage manager 102 is abnormal. The way adopted can still be based on the writing speed. Specifically, when it is monitored that the speed of the log written into the log storage space continuously is less than the rate threshold (step S803), it can be judged as abnormal. At this time, all components related to log management are restarted (step S804), wherein the components related to log management include the log manager, the DLT daemon module and the DLT proxy module. If the problem still cannot be solved and is further aggravated, such as the speed of the log written into the log storage space continuously is less than the rate threshold and continuously for a preset time (step S805), it means that there is a serious problem in the whole system, and the core is immediately restarted (S806). The rate threshold and the time threshold in steps S8023 and S805 can be different.

[0055] The above-mentioned ways are combined together, comprehensive management of the log storage failure can be realized, and the repair means used is gradually strengthened to reduce the possible impact on the user. Figures 6-7

[0056] In addition, the embodiment of the present application further provides a computer device / apparatus / system 9, which comprises a memory 90, a processor 92 and a computer program stored on the memory, and the processor executes the computer program to realize the steps in any one of the above method embodiments.

[0057] In addition, the embodiment of the present application further provides a computer readable storage medium, which stores a computer program / instruction, and the computer program / instruction is executed by a processor to realize the steps in any one of the above method embodiments.

[0058] In addition, the embodiment of the present application further provides a computer program product, which comprises a computer program / instruction, and the computer program / instruction is executed by a processor to realize the steps in any one of the above method embodiments.

[0059] The above description of the computer device / apparatus / system, the storage medium and the program product embodiments is similar to the description of the above method embodiments, and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the computer device / apparatus / system, the storage medium and the program product embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0060] ​The processor can be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, and the like. It can be understood that the electronic device for implementing the above-described processor function can also be other, and the embodiments of the present application do not make specific limitations.

[0061] The computer storage medium / memory can be a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Ferromagnetic Random Access Memory (FRAM), a Flash Memory, a magnetic surface memory, an optical disc, a Compact Disc Read-Only Memory (CD-ROM), and the like. It can also be various terminals including one or any combination of the above memories, such as a mobile phone, a computer, a tablet device, a personal digital assistant, and the like.

[0062] It should be noted that the above description is only an example, not a limitation of the present application. In other embodiments of the present application, the method can have more, less or different steps, and the relationship between the steps, such as inclusion and function, can be different from the described and illustrated. For example, usually a plurality of steps can be combined into a single step, and a single step can also be split into a plurality of steps. For those skilled in the art, the order of the steps can be changed without creative labor, which is within the protection scope of the present application.

[0063] The technical solutions of the present application, essentially or the part that contributes to the prior art, or all or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor or a microcontroller to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0064] Those of ordinary skill in the art can understand that all or part of the steps of the above-mentioned method embodiments can be completed by program instruction-related hardware. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed.

[0065] Although the present application has been disclosed with the preferred embodiments as above, the present application is not limited to this. Any modifications and changes made by those skilled in the art without departing from the spirit and scope of the present application shall be included in the protection scope of the present application, and therefore the protection scope of the present application shall be limited by the scope defined in the claims.

Claims

1. A method for managing log storage failure, characterized in that, include: Based on the write status of logs to the log storage space, identify whether there is a log storage failure. If so, restore normal log writing by performing failure handling operations.

2. The log storage failure management method as described in claim 1, characterized in that, The writing status includes the writing speed at which logs are written to the log storage space; When the write speed is less than a preset rate threshold and the duration reaches a preset time threshold, the log storage may fail.

3. The log storage failure management method as described in claim 1 or 2, characterized in that, The log manager is responsible for writing logs to the log storage space, and when a failure of the log storage is detected based on the writing status, the log manager is restarted.

4. The log storage failure management method as described in claim 3, characterized in that, When the restart reaches the preset limit, the system takes over the function of the log manager and stops restarting the log manager. At the same time, it instructs the system to perform a "shutdown" operation when entering hibernation. The system is set by default to perform a "suspend to memory" operation when entering hibernation.

5. The log storage failure management method as described in claim 4, characterized in that, After taking over the functions of the log manager, if the log storage failure still exists based on the write status, then restart all log management-related components, restart the core where the log manager resides, or, if the log storage failure still exists after restarting all log management-related components, restart the core where the log manager resides.

6. The log storage failure management method as described in claim 3, characterized in that, The method further includes: monitoring the log storage thread within the log manager, and restarting the log storage thread when an abnormality is detected in the log storage thread; And / or, based on the reporting of the log manager's "heartbeat" data, monitor whether the log manager is abnormal, and restart the log manager when an abnormality is detected.

7. An electronic device, comprising: The core with log management functionality is characterized in that the core includes: Non-volatile memory; A log manager is configured to write logs generated by the electronic device during operation into the non-volatile memory; and The storage management module is used to monitor the write rate of the log manager writing the logs to the non-volatile memory, and to control the log manager according to the write rate.

8. The electronic device as claimed in claim 7, characterized in that, The storage management module is specifically used to restart the log manager when the write rate is less than a preset rate threshold and the duration is greater than a preset time threshold.

9. The electronic device as claimed in claim 8, characterized in that, The storage management module is further configured to stop restarting the log manager when the number of restarts exceeds a preset threshold, and to instruct the core to perform a "shutdown" operation when it enters hibernation. The core is set by default to perform a "suspend to memory" operation when it enters hibernation.

10. The electronic device as claimed in claim 9, characterized in that, The storage management module is further configured to: write the logs into the non-monitored volatile memory when the log manager fails, and identify whether there is a log storage failure based on the write rate of the logs written into the non-monitored volatile memory by the storage management module. If there is, restart all log management-related components, including the log manager. If the log storage failure still occurs after restarting, restart the core.

11. A computer device / equipment / system, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

12. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 6.

13. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 6.

Images