Multi-core heterogeneous log management architecture, log anomaly detection method, computer equipment and computer program product

Abstract

The invention provides a multi-core heterogeneous log management architecture, a log anomaly detection method, computer equipment and a computer program product, and is suitable for the technical field of computers, and the multi-core heterogeneous log management architecture comprises a main core and a slave core for division of labor and cooperation: the main core is responsible for integration and deep analysis of global log data and performs anomaly positioning and processing in a global range; a log source analyzed by the main core comprises an alarm log reported by the slave core and global log data collected by the main core. And the slave core is responsible for operating a lightweight anomaly detection module in the field equipment, quickly detecting log data with high timely storage requirements, and mainly paying attention to key indexes of equipment operation states and task execution. When the slave core detects the exception, the generated alarm log is uploaded to the master core through the shared memory area, and meanwhile, a local emergency processing task can be triggered, so that the defect of fault response lag of a log management technology in a multi-core environment is effectively improved, and the accuracy and response speed of exception detection are improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and particularly relates to a multi-core heterogeneous log management architecture, a log anomaly detection method, a computer device, and a computer program product. Background Art

[0002] With the development of the intelligentization of the power system, as a new generation of special operating system for the power industry, the multi-core processing ability of the Power Harmony operating system provides the possibility for the efficient operation of complex applications.

[0003] However, in a multi-core heterogeneous environment where the main core and slave cores cooperate, especially for complex application scenarios in the power industry, the existing log management technology has the disadvantage of lagging fault response. Since the existing anomaly detection technology mainly relies on centralized processing and cannot fully utilize the real-time processing ability of the slave cores, it leads to delays in anomaly detection and alarm response. There is a lack of an efficient collaborative detection mechanism between the main core and the slave cores, making it difficult to quickly locate and handle anomalies. Specifically, it includes: the main core cannot monitor the running state of the slave core log module in real time, resulting in the failure to start the log transfer or recovery mechanism in time when the slave core fails. And after the slave core fails, the log recovery process overly relies on manual intervention or complex operation procedures, and cannot quickly restore the running state of the system, making the log recovery process complex. Summary of the Invention

[0004] To solve the technical problem of "the log management technology in a multi-core environment has the disadvantage of lagging fault response due to limitations in the detection mechanism and the lack of a master-slave cooperation mechanism" mentioned in the above background art, the embodiments of this application provide a multi-core heterogeneous log management architecture, a log anomaly detection method, a computer device, and a computer program product.

[0005] In a first aspect, the embodiments of this application provide a multi-core heterogeneous log management architecture, including a main core, slave cores, and a shared memory area; the slave cores include a log generation module, a lightweight cache module, and a log upload module;

[0006] The main core is configured to run the Power Harmony operating system;

[0007] The slave cores are configured to run a bare-metal program, access hardware resources through the bare-metal program to enable the log generation module to generate raw log data, and cache the raw log data in the lightweight cache module in real time;

[0008] The slave cores are further configured to run a real-time operating system to provide real-time task scheduling and resource management, and optimize the processing flow of the raw log data through the real-time task scheduling and the resource management;

[0009] The log upload module is configured to write the log data at the cache tail of the lightweight cache module into the shared memory area when the data cached in the lightweight cache module reaches a preset condition;

[0010] The main core is further configured to monitor the data in the shared memory area, and when it monitors that the slave core uploads the original log data to the shared memory area, read the log data uploaded by each slave core in the shared memory area, and integrate and deeply analyze the log data uploaded by each slave core to obtain global log data;

[0011] The slave core is further configured to detect target log data to determine the device running state and key metrics for task execution; and when it detects that the target log data is abnormal, generate an alarm log and upload the alarm log to the main core through the shared memory area; wherein, the target log data is log data whose storage requirements reach a preset storage requirement condition;

[0012] The main core is further configured to analyze the alarm log in combination with the global log data to locate the source of the abnormality, evaluate the scope of influence of the source of the abnormality, determine the abnormal analysis result, and trigger an emergency handling task within the global scope according to the abnormal analysis result.

[0013] In one example, the slave core is further configured to start a detection strategy to execute a preset emergency handling task when it determines that the abnormal analysis result meets a preset abnormal threshold;

[0014] The main core is further configured to call an anomaly detection model to adjust the detection strategy of the slave core.

[0015] In one example, the main core is further configured to monitor the global log data, determine key logs from the global log data, store the key logs in the main core cache module, and when it detects that the Power Harmony operating system is about to power off, write the key logs in the main core cache module into a high-speed storage device;

[0016] The slave core is further configured to save key status data through the lightweight cache module when it detects that the Power Harmony operating system is about to power off; and when it detects a power off, write the key status data in the lightweight cache module into a non-volatile memory; wherein, the key status data includes the running logs and status information of key tasks.

[0017] In one example, the main core is configured to determine and restore the key logs from the high-speed storage device after the Power Harmony operating system restarts;

[0018] The slave core is configured to determine and restore the critical status data from the non-volatile memory after the Power Harmony operating system restarts, and transmit the restored critical status data to the master core;

[0019] The master core is further configured to restore the complete log running state according to the critical log and the critical status data, and the complete log running state is the running state before the Power Harmony operating system has a power outage.

[0020] In a second aspect, the present application also proposes a log anomaly detection method, which is implemented based on the multi-core heterogeneous log management architecture described in the first aspect above. The method includes:

[0021] The master core runs the Power Harmony operating system;

[0022] The slave core runs a bare-metal program, accesses hardware resources through the bare-metal program to enable the log generation module to generate raw log data, and caches the raw log data in the lightweight cache module in real time;

[0023] The slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of the raw log data through the real-time task scheduling and the resource management;

[0024] When the data cached in the lightweight cache module by the slave core reaches a preset condition, the log data at the cache tail of the lightweight cache module is written into the shared memory area;

[0025] The master core monitors the data in the shared memory area, and when it monitors that the slave core uploads the raw log data to the shared memory area, reads the log data uploaded by each slave core in the shared memory area, and integrates and deeply analyzes the log data uploaded by each slave core to obtain global log data;

[0026] The slave core detects target log data to determine key indicators of the device running state and task execution; and when it detects that the target log data is abnormal, generates an alarm log, and uploads the alarm log to the master core through the shared memory area; wherein, the target log data is log data whose storage requirement reaches a preset storage requirement condition;

[0027] The master core analyzes the alarm log in combination with the global log data to locate the source of the anomaly, evaluate the influence range of the source of the anomaly, determine the anomaly analysis result, and trigger an emergency processing task within the global scope according to the anomaly analysis result.

[0028] In one example, after the step of triggering an emergency handling task within the global scope according to the abnormal analysis result, the method further includes:

[0029] When the slave core determines that the abnormal analysis result meets a preset abnormal threshold, it starts a detection strategy to execute a preset emergency handling task;

[0030] The master core calls an anomaly detection model to adjust the detection strategy of the slave core.

[0031] In one example, the method further includes:

[0032] When the slave core detects a local failure, it uploads the unprocessed log data to the master core;

[0033] The master core monitors the running state of the slave core log module; wherein, the slave core log module at least includes the log generation module, the lightweight cache module, and the log upload module; the running state of the log generation module at least includes the log generation rate, the running state of the lightweight cache module at least includes the cache occupancy rate, and the running state of the log upload module at least includes the communication state;

[0034] When the master core detects an anomaly in the slave core log module, it receives and integrates the unprocessed log data uploaded by the slave core to restore the running state of the complete slave core log, and the running state of the complete slave core log is the running state before the slave core has an anomaly.

[0035] In one example, when the slave core detects a local failure and the master core cannot upload the unprocessed log data to the master core, the method further includes:

[0036] The slave core transfers the unprocessed log data to the backup device, so that the backup device stores the unprocessed log data of the slave core;

[0037] The master core obtains and integrates the unprocessed log data of the slave core from the backup device to restore the running state of the complete slave core log.

[0038] In a third aspect, the present application also proposes a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, it implements the steps of the log anomaly detection method as described in the second aspect.

[0039] Fourthly, the present application also provides a computer program product. The computer program product stores a computer program, and when the computer program is executed by a processor, it implements the steps of the log anomaly detection method as described in the second aspect.

[0040] The beneficial effects of the present application are as follows: The main core and the slave core of the present application cooperate with each other: the main core is responsible for the integration and in-depth analysis of global log data, and performs anomaly location and processing within the global scope. The log sources analyzed by the main core include the alarm logs reported by the slave core and the global log data collected by itself. The slave core is responsible for running a lightweight anomaly detection module in the field device. It quickly detects the log data with high requirements for timely storage, and mainly focuses on the key indicators of the device operation status and task execution. When the slave core detects an anomaly, it uploads the generated alarm log to the main core through the shared memory area, and at the same time can trigger a local emergency processing task, effectively improving the defect of lagging fault response in the log management technology in a multi-core environment, and enhancing the accuracy and response speed of anomaly detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0042] Figure 1 It is a schematic diagram of an embodiment of a multi-core heterogeneous log management architecture provided by the present application;

[0043] Figure 2 It is a schematic flowchart of an embodiment of a log anomaly detection method provided by the present application;

[0044] Figure 3 It is a schematic structural diagram of an embodiment of a computer device for executing the log anomaly detection method provided by the present application;

[0045] Figure 4 It is a schematic diagram of another embodiment of a multi-core heterogeneous log management architecture provided by the present application;

[0046] Figure 5 It is a schematic flowchart of another embodiment of a log anomaly detection method provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0047] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field to which this application belongs; the terms used herein are for the purpose of describing specific embodiments only and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above description of the drawings are intended to cover non-exclusive inclusion.

[0048] It should be understood that when used in the specification and appended claims of this application, the term "including" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0049] It should also be understood that the term "and / or" as used in the specification and appended claims of this application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0050] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "once" or "in response to determining" or "in response to detecting" depending on the context. Similarly, the phrase "if determined" or "if [the described condition or event] is detected" can be interpreted as meaning "once determined" or "in response to determining" or "once [the described condition or event] is detected" or "in response to detecting [the described condition or event]" depending on the context.

[0051] In the description of the embodiments of this application, the term "plurality" means two or more (including two), unless otherwise specifically defined.

[0052] In addition, in the description of the specification and appended claims of this application, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0053] Reference to "one embodiment" or "some embodiments" or the like described in the specification of this application means that a specific feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0054] The applicant of the present invention has noticed that in the multi-core heterogeneous environment of the power industry, log anomaly detection is of great significance to the stability and security of the system. However, the existing anomaly detection mechanisms have the following problems in the multi-core environment:

[0055] Insufficient real-time performance of anomaly detection:

[0056] The current anomaly detection solutions usually focus on the main core for processing. Limited by the log transmission delay and the computing resources of the main core, they cannot quickly respond to anomalies in on-site devices.

[0057] Unclear division of labor in anomaly detection:

[0058] The responsibilities of the main core and the slave cores in the anomaly detection task are not clear, resulting in the main core undertaking too many log analysis tasks, while the real-time capabilities of the slave cores are not fully utilized.

[0059] Incomplete alarm mechanism:

[0060] When an anomaly is detected by a slave core, there is a lack of a mechanism for rapid alarm and cooperation with the main core, resulting in the possible failure to report anomaly information in a timely manner, delaying the location and handling of problems.

[0061] Therefore, the embodiments of the present application provide a multi-core heterogeneous log management architecture and a log anomaly detection method in a multi-core environment. Through the rapid detection of on-site devices by the slave cores and the global analysis and cooperation of the main core, the real-time performance and accuracy of anomaly detection are improved to solve the defect of lagging fault response in the log management technology in the multi-core environment. The specific technical solutions of the present application are elaborated below through specific embodiments.

[0062] Embodiment 1

[0063] To solve the technical problem of "the log management technology in the multi-core environment has the drawback of lagging fault response" mentioned in the above background art, the present application provides a multi-core heterogeneous log management architecture, as Figure 1 and Figure 2 shown, including a main core 10, slave cores 20, and a shared memory area 30; the slave cores 20 include a log generation module 21, a lightweight cache module 22, and a log upload module 23; the main core 10 mainly interacts with the slave cores 20 through a global log management center.

[0064] The main core 10 is configured to run the Power Harmony operating system;

[0065] The slave cores 20 are configured to run a bare-metal program, access hardware resources through the bare-metal program to enable the log generation module 21 to generate raw log data, and cache the raw log data in the lightweight cache module 22 in real time;

[0066] The slave core 20 is also configured to run a Real-Time Operating System (RTOS) to provide real-time task scheduling and resource management, and optimize the processing flow of the original log data through the real-time task scheduling and the resource management;

[0067] The log upload module 23 is configured to write the log data at the cache tail of the lightweight cache module 22 into the shared memory area 30 when the data cached in the lightweight cache module 22 reaches a preset condition;

[0068] The master core 10 is further configured to monitor the data in the shared memory area 30, and when it monitors that the slave core 20 uploads the original log data to the shared memory area 30, read the log data uploaded by each slave core in the shared memory area 30, and integrate and deeply analyze the log data uploaded by each slave core to obtain global log data.

[0069] The slave core 20 is further configured to detect target log data to determine key indicators of device operation status and task execution; and when it detects that the target log data is abnormal, generate an alarm log and upload the alarm log to the master core 10 through the shared memory area 30; wherein, the target log data is log data whose storage requirement reaches a preset storage requirement condition, and the target log data may be part of the global log data;

[0070] The master core 10 is further configured to analyze the alarm log uploaded by the slave core in combination with the global log data to locate the source of the abnormality, evaluate the influence range of the source of the abnormality, determine the abnormal analysis result, and trigger an emergency handling task within the global scope according to the abnormal analysis result.

[0071] It can be understood that the cooperation of the log management functions of the master core 10 and the slave core 20 in the embodiments of the present application is mainly divided into:

[0072] The master core runs the Power Harmony operating system and serves as the global log management center, responsible for receiving the log data uploaded by the slave core, and integrating, classifying, and storing the logs. Provide a unified log indexing function, organize and sort the logs through keywords such as timestamps and source cores, so that subsequent users can quickly query the log data based on the log indexing function. In addition, the master core 10 in this embodiment may further include a log analysis module, and the log analysis module is used to perform preliminary analysis on the log data and extract key information for upper-layer applications to use.

[0073] The slave core 10 runs a bare-metal program or a real-time operating system RTOS, focusing on the generation and preliminary processing of local logs.

[0074] It is understandable that the bare-metal program in the embodiments of the present application is a program that runs directly on hardware without the support of the HarmonyOS operating system. It is usually used in application scenarios that require high efficiency and low latency because it avoids the overhead of the operating system. In the multi-core heterogeneous environment of the embodiments of the present application, the slave core runs the bare-metal program and can focus on specific tasks, such as the initial generation and processing of log data. Due to the reduction of the intermediate layer of the operating system, the bare-metal program in the embodiments of the present application can respond more quickly to the log generation requirements and improve the real-time performance of log data. The bare-metal program in the embodiments of the present application is closely related to the generation of log data because it can directly access hardware resources, quickly capture and record system events, and generate raw log data.

[0075] The real-time operating system (RTOS) in the embodiments of the present application is an operating system specifically designed for real-time applications. It provides functions such as task scheduling, time management, and interrupt handling, while maintaining a low system overhead to meet real-time requirements. In the multi-core architecture of the embodiments of the present application, the slave core runs the RTOS and can more effectively manage the generation, caching, and transmission of log data. The RTOS in the embodiments of the present application ensures that log data can be processed and stored according to the predetermined time requirements by providing real-time task scheduling and resource management. The RTOS in the embodiments of the present application also supports concurrent execution of multiple tasks, enabling the slave core to process multiple log generation tasks simultaneously, improving the overall efficiency and reliability of the log system. The relationship between the RTOS in the embodiments of the present application and the generation of log data lies in that the RTOS can optimize the processing flow of log data and ensure the timeliness and accuracy of log data.

[0076] In addition, it should be noted that the log management module of the slave core 20 in the embodiments of the present application is mainly designed in a lightweight manner and has the ability of low-overhead log generation, caching, and transmission. It supports the rapid generation of high-frequency logs, realizes real-time caching through a circular buffer, and ensures the integrity of log data. The slave core 20 uploads the locally cached logs to the master core at an appropriate time, reducing the cross-core communication overhead.

[0077] In some embodiments, for the main core 10, the multi-core optimization strategy for log collection and storage is as follows: The main core adopts a centralized storage mechanism: responsible for the storage management of global log data, classifying and storing logs according to the importance and time sequence of the logs. The concept of log priority is introduced to ensure that critical task logs can be stored and processed preferentially. For the slave core 20, the lightweight cache module adopted by the slave core 20 in this embodiment can circularly store data in the buffer. When the buffer of the lightweight cache module reaches the end, it will continue to write from the beginning of the buffer, forming a circular structure. This can ensure the integrity of log data and avoid interference with task execution during the log writing process. The log is segmented and stored using statically allocated cache space, and the circular overwrite method is used to avoid buffer overflow, reduce the interference of log generation on real-time tasks, and ensure the stable performance of the system.

[0078] In addition, in this embodiment, the log transmission mechanism between the main core 10 and the slave core 20 is as follows:

[0079] Efficient transmission based on shared memory: Allocate a shared memory area 30, and the slave core 20 directly writes the generated logs into the shared memory area 30, and the main core 10 reads the logs from it for processing. This embodiment preferably uses a flag bit mechanism to avoid read-write conflicts of multiple cores on the shared memory and improve data transmission efficiency at the same time. Adopt event-triggered data transmission: The slave core triggers log transmission when the local cache reaches a certain threshold or the task is completed. The main core listens to the transmission event of the slave core and pulls or waits for log data as needed.

[0080] It can be understood that in the multi-core log management framework, both the shared memory and the lightweight cache module are key components for log data transmission and processing. The shared memory in this embodiment represents a mechanism for efficiently transmitting log data between the main core and the slave core. It allows the slave core to directly write the generated logs into the shared memory area, and the main core can read the logs from the shared memory area for processing.

[0081] The buffer of the lightweight cache module 22 used by the slave core 20 is the space for the slave core 20 to temporarily store log data. After the slave core 20 generates logs, the log data will be cached in the lightweight cache module 22 first, and then the log data will be transmitted to the shared memory area 30 when the data cached in the lightweight cache module 22 meets the preset conditions (such as when the cache reaches a certain threshold or the task is completed).

[0082] In some embodiments, in specific implementations, this embodiment can optimize the task division and load of multi-core log processing: Main core tasks: Integrate and classify the logs uploaded by multiple cores to ensure the orderliness of global logs. Be responsible for the log analysis and storage of low-real-time tasks, such as the historical records of system operation. Slave core tasks: Mainly responsible for the generation and preliminary processing of high-real-time logs, such as the acquisition logs of sensor data. When the load of the slave core is low, undertake the local storage task of some logs to further relieve the pressure on the main core.

[0083] In some embodiments, in specific implementations, the log format adaptation and conversion under the heterogeneous architecture of this embodiment: The slave core side adopts a unified log generation format: Use a standardized structured format, such as metadata like fixed timestamp, source core identifier, task ID, etc., to facilitate the main core to quickly parse. The main core side designs a log format conversion module: According to actual needs, convert the slave core logs into a more advanced format (such as JSON or binary format) to adapt to different upper-layer application requirements.

[0084] Furthermore, in specific implementations of this embodiment, the division of labor and cooperation mechanism between the main core 10 and the slave core 20. The main core 10 is responsible for the integration and in-depth analysis of global log data, verifying the anomaly detection results, and anomaly localization and processing within the global scope; The slave core 20 runs a lightweight anomaly detection module to quickly detect the target log data with high requirements for timely storage (i.e., the storage requirements reach the preset storage demand conditions), and generate an alarm log and upload it to the main core when an anomaly is detected;

[0085] And the anomaly detection process of this embodiment is: The slave core 20 monitors the log data in real time according to the predefined detection rules, generates an alarm log when an anomaly is detected, and uploads it to the main core 10 through the shared memory area 30; After receiving the alarm log, the main core 10 conducts further analysis in combination with the global log data to locate the anomaly source and evaluate its impact range; In specific implementations, the predefined detection rules include but are not limited to detection rules such as reaching the key performance index threshold and task timeout.

[0086] The beneficial effects of this embodiment are as follows: Division of labor and cooperation between the main core and the slave core: The main core is responsible for the integration and in-depth analysis of global log data, verifying the anomaly detection results, and anomaly localization and processing within the global scope. The log sources analyzed by the main core include the alarm logs reported by the slave core and the global log data collected by itself. The slave core is responsible for running a lightweight anomaly detection module in the on-site device to quickly detect the log data with high requirements for timely storage, mainly focusing on the key indicators of the device operation status and task execution. When the slave core detects an anomaly, it will upload the generated alarm log to the main core through an efficient transmission mechanism, and at the same time, it can trigger the local emergency processing task.

[0087] In addition, in some embodiments, the slave core 20 is further configured to, when determining that the abnormal analysis result meets a preset abnormal threshold, start a detection policy to execute a preset emergency handling task;

[0088] The master core 10 is further configured to call an anomaly detection model to adjust the detection policy of the slave core.

[0089] It can be understood that the abnormal handling and response mechanism of this embodiment is as follows: The master core 10 triggers an emergency handling task within the global scope according to the abnormal analysis result. At the same time, after detecting an abnormality, the slave core 20 can directly start its detection policy to execute a preset emergency handling task. The master core 10 dynamically adjusts the detection policy of the slave core 20 through the optimized anomaly detection model.

[0090] In specific implementation, after detecting an abnormality, in addition to reporting to the master core, the slave core can directly execute a preset emergency handling task (such as restarting the device or switching backup tasks). Global optimization and verification of the master core: The master core verifies the validity of the abnormality based on the abnormal information reported by the slave core and in combination with the logs of other cores and the system, to avoid false alarms or missed alarms. The master core dynamically adjusts the detection policy of the slave core (such as updating detection rules) through the optimized anomaly detection model, achieving fast response and optimization in mechanism.

[0091] Embodiment 2

[0092] Corresponding to the multi-core heterogeneous log management architecture mentioned in the above Embodiment 1, an embodiment of the present application provides a log anomaly detection method, as Figure 2 described, the log anomaly detection method of this embodiment is implemented based on the multi-core heterogeneous log management architecture described in the above Embodiment 1, and the method includes:

[0093] Step S10, the master core runs the Power Harmony operating system; the slave core runs a bare-metal program, accesses hardware resources through the bare-metal program to enable a log generation module to generate original log data, and caches the original log data in the lightweight cache module in real time; the slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of the original log data through real-time task scheduling and resource management;

[0094] Step S20, when the data cached in the lightweight cache module by the slave core reaches a preset condition, write the log data at the cache tail of the lightweight cache module into the shared memory area;

[0095] Step S30, the master core monitors the data in the shared memory area, and when it monitors that the slave core uploads the original log data to the shared memory area, reads the log data uploaded by each slave core in the shared memory area, and integrates and deeply analyzes the log data uploaded by each slave core to obtain global log data;

[0096] Step S40: Determine the key indicators of the device operation status and task execution from the nuclear detection target log data; and in the case where the target log data is detected to be abnormal, generate an alarm log and upload the alarm log to the main core through the shared memory area; wherein, the target log data is the log data whose storage requirement reaches the preset storage requirement condition.

[0097] Step S50: The main core analyzes the alarm log in combination with the global log data to locate the source of the anomaly, evaluate the scope of influence of the source of the anomaly, determine the anomaly analysis result, and trigger an emergency handling task within the global scope according to the anomaly analysis result.

[0098] Correspondingly, the technical effect of the log anomaly detection method in the second embodiment corresponds to the multi-core heterogeneous log management architecture mentioned in the first embodiment. To avoid repetition, the second embodiment will not be elaborated here.

[0099] Please refer to Figure 3 , Figure 3 , which is a schematic structural diagram of an embodiment of a computer device for executing the log anomaly detection method in the second embodiment of the present application. As Figure 3 shown, the computer device 1 in this embodiment includes: at least one processor 10 ( Figure 3 only one is shown in

[0100] ), a memory 11, and a computer program 12 stored in the memory 11 and executable on the at least one processor 10. When the processor 10 executes the computer program 12, the steps in the embodiment of the multi-core log management method of the present application are implemented.

[0101] Figure 2 The computer device shown may include, but is not limited to, a processor 10 and a memory 11. Those skilled in the art can understand that Figure 2 this is only an example of the computer device 1, and does not constitute a limitation on the computer device 1. It may include more or fewer components than shown in the figure, or combine some components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0102] The so-called processor 10 may be a Central Processing Unit (CPU), and the processor 10 may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0103] In some embodiments, the memory 11 may be an internal storage unit of the computer device 1, such as the hard disk or memory of the computer device 1. In other embodiments, the memory 11 may also be an external storage device of the computer device 1, such as the hard disk or memory of the computer device. In other embodiments, the memory 11 may also be an external storage device of the computer device 1, such as the Dynamic Random Access Memory (DRAM), Solid State Drive (SSD), and Hard Disk Drive (HDD) equipped on the computer device, etc. The memory 11 is used to store the operating system, application programs, BootLoader, data, and other programs, such as the program code of the computer program, etc. The memory 11 may also be used to temporarily store the data that has been output or will be output.

[0104] For the content such as information interaction and execution process between the above-mentioned devices / units, since it is based on the same concept as the method embodiment of this application, for its specific functions and the technical effects brought, please refer to the method embodiment part for details.

[0105] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules as needed, that is, the internal structure is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiment and will not be elaborated here.

[0106] Embodiment III

[0107] Furthermore, in the multi-core heterogeneous environment of the power industry (the main core runs Power HarmonyOS, and the slave core runs a bare-metal program or RTOS), the reliability and data protection capabilities of log management in extreme situations such as power outages are crucial. However, the existing log management systems have the following problems in power-off protection:

[0108] Risk of key log loss: In the case of a power outage or accidental power failure, the key logs that have not been written to the storage device in time may be lost, resulting in the lack of key information after the system restarts and affecting the recovery of the operating state.

[0109] Insufficient protection of slave-core log data: When the slave core is executing tasks, due to limited hardware resources, it usually lacks an independent log protection mechanism and is prone to losing the last key state data due to a power outage.

[0110] Complex log recovery after restart: After the system restarts, the recovery of log data depends on a complex process, which increases the recovery time after a device failure and affects the continuity of the power system.

[0111] Therefore, based on the multi-core heterogeneous log management architecture provided in the above Embodiment I, Embodiment III proposes a technical solution for a power-off log protection mechanism applicable to power scenarios. Through the collaborative work of the main core and the slave core, it ensures the integrity of key logs during a power outage and efficiently recovers log data after the system restarts.

[0112] Refer to Figure 4 , in this embodiment, the main core 10 is further configured to monitor the global log data, determine the key logs from the global log data; store the key logs in the main-core cache module; and write the key logs in the main-core cache module to the high-speed storage device when it is detected that the Power HarmonyOS is about to have a power outage.

[0113] The slave core 20 is also used to save critical status data through the lightweight cache module when it is detected that a power failure is about to occur in the Power Harmony operating system; and when a power failure is detected, write the critical status data in the lightweight cache module into a non-volatile memory; wherein, the critical status data includes the running logs and status information of critical tasks.

[0114] It can be understood that in the specific implementation, the master core is responsible for backing up critical logs: the master core regularly backs up critical logs during normal operation: monitors the generation and writing status of logs in real time through the critical log management module, and writes system critical logs to a high-speed storage device, such as a solid-state drive (SSD), at regular intervals. Adopt a transactional writing method to ensure the atomicity of the critical log writing process and prevent partial log data from being damaged due to accidental interruption. Before the system powers off, the master core will give priority to saving all critical logs that have not been written to the storage device: through a fast writing mechanism, give priority to writing the critical logs in the master core cache module to the high-speed storage device to ensure the integrity of the log data during power-off.

[0115] The slave core runs a lightweight log cache module, which is responsible for saving the final critical status data: in the specific implementation, this embodiment can use a low-overhead data structure such as a circular buffer to retain the running logs and status information of critical tasks before power-off. When power-off occurs, the slave core will write the critical data in the cache into a non-volatile memory, such as NVRAM (Non-Volatile Random Access Memory), for use when the system restarts. The slave core uploads some logs to the master core before power-off: if the slave core detects that power-off is about to occur, uploads important logs to the master core through a high-speed channel to increase the protection redundancy of the log data.

[0116] Furthermore, in this embodiment, the master core 10 is configured to determine and restore the critical logs from the high-speed storage device after the Power Harmony operating system restarts;

[0117] The slave core 20 is configured to determine and restore the critical status data from the non-volatile memory after the Power Harmony operating system restarts, and transmit the restored critical status data to the master core;

[0118] The master core 10 is further configured to restore the complete log running status according to the critical logs and the critical status data, and the complete log running status is the running status before the power failure of the Power Harmony operating system.

[0119] In a specific implementation, the log recovery mechanism of this embodiment can be as follows: After the Power Harmony operating system restarts, the main core restores the critical logs backed up before power-off from the high-speed storage device. The slave core restores the last state data cached in the non-volatile memory and synchronizes it to the main core. The main core integrates the log data of itself and the slave core to restore the complete operating state before power-off. Log consistency check: During the log recovery process, the main core checks the integrity of the logs through the timestamp and verification mechanism to ensure the correctness and consistency of all data.

[0120] The beneficial effects of the third embodiment are as follows: It realizes the protection and recovery of log data of the main core and the slave core in the case of power-off, ensures the integrity and reliability of critical logs, significantly shortens the recovery time after system restart, and meets the requirements for highly reliable log management in the power scenario.

[0121] Embodiment Four

[0122] Furthermore, in the multi-core heterogeneous environment of the power industry, the disaster tolerance and recovery capabilities of log management are crucial for the reliability and data integrity of the system. However, the existing log management systems have the following problems in disaster tolerance and recovery:

[0123] Risk of log data loss: When a failure occurs in the slave core, the unprocessed log data fails to be saved or transferred in time, which may lead to the loss of critical operation information and affect subsequent fault diagnosis and system recovery.

[0124] Insufficient cooperation between the main core and the slave core: Currently, the main core lacks the ability to monitor the running state of the slave core's log module in real time and cannot quickly respond and start the log transfer or recovery mechanism when a failure occurs in the slave core.

[0125] Low efficiency of log disaster tolerance: The transfer and recovery of logs during the disaster tolerance process rely on complex processes, lacking real-time performance and high efficiency, which may delay the system recovery and operation.

[0126] Therefore, based on the log anomaly detection method provided in the second embodiment above, this embodiment four proposes a processing method for a multi-core log disaster tolerance and recovery mechanism, which utilizes the detection and regulation capabilities of the main core and the log transfer function of the slave core to ensure the integrity and availability of log data during a failure.

[0127] Specifically, referring to Figure 5 The log anomaly detection method of this embodiment further includes:

[0128] A1: When the slave core detects a local failure, it uploads the unprocessed log data to the main core;

[0129] A2: The main core monitors the operating status of the slave core log module. Among them, the slave core log module at least includes the log generation module, the lightweight cache module, and the log upload module. The operating status of the log generation module at least includes the log generation rate, the operating status of the lightweight cache module at least includes the cache occupancy rate, and the operating status of the log upload module at least includes the communication status.

[0130] A3: When the main core detects an abnormality in the slave core log module, it receives and integrates the unprocessed log data uploaded by the slave core to restore the complete log operating status of the slave core, and the complete log operating status of the slave core is the operating status before the slave core has an abnormality.

[0131] In a specific implementation, the main core of this embodiment is responsible for monitoring and restoring the log status. Among them, the monitoring of the log module operating status mainly includes: the main core monitors the operating status of the slave core log module in real time through the log management module, including the log generation rate, the cache occupancy rate, the communication status, etc. When detecting an abnormality (such as timeout or unreachability) in the slave core log module, the main core will immediately record the abnormality information and start the disaster recovery mechanism.

[0132] The log recovery process of the main core includes: after the main core detects an abnormality in the slave core, it receives and integrates the log data transferred by the slave core, and at the same time attempts to restore the operating status of the slave core. When the slave core is completely faulty and cannot be restored, the main core reconstructs the key operating status based on the existing log data to ensure the continuous operation of the system.

[0133] On the other hand, for the slave core, it adopts the log transfer and standby strategy. The specific log transfer of the slave core in this embodiment includes: when the slave core detects its own fault or abnormal state, it sends the unprocessed log data to the main core through a high-speed channel for temporary storage. If the main core cannot receive the log, the slave core can choose to transfer the log data to a standby device for storage to ensure the integrity of the log data. Log temporary caching: When a fault occurs, the slave core uses the local non-volatile memory to temporarily store the key logs, and uploads them to the main core preferentially after the system is restored.

[0134] The beneficial effects of this embodiment are as follows: The main core monitors the operating status of the slave core in real time, identifies abnormal situations and records the fault logs. After the slave core detects a fault, it starts the log transfer mechanism to upload the unprocessed logs to the main core or transfer them to a standby device. The main core integrates the log data uploaded or transferred by the slave core to restore the complete operating status of the system. After the slave core returns to normal, the log data is synchronized to update the global log record. Through the above technical solutions of this embodiment, this application realizes the log disaster recovery and recovery mechanism in a multi-core environment, significantly improves the reliability and log management ability of the system in abnormal scenarios, and meets the requirements of the power industry for highly reliable log management.

[0135] In addition, an embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in the above-mentioned embodiments of various multi-core log management methods are implemented.

[0136] In addition, an embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned embodiments of various multi-core log management methods can be implemented.

[0137] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-mentioned embodiment methods of the present application, a computer program can be used to instruct relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the photographing device / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium may not be an electrical carrier signal and a telecommunication signal.

[0138] In the above embodiments, the descriptions of the various embodiments have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0139] The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A multi-core heterogeneous log management architecture, characterized in that: It includes a master core, a slave core and a shared memory area; the slave core includes a log generation module, a lightweight cache module and a log upload module; The main core is configured to run the power Hongmeng operating system; The slave core is configured to run a naked running program, access hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in the lightweight cache module in real time; The slave core is further configured to run a real-time operating system to provide real-time task scheduling and resource management, and optimize the processing flow of the original log data through the real-time task scheduling and the resource management; The log upload module is configured to write the log data at the cache tail of the lightweight cache module into the shared memory area when the data cached in the lightweight cache module meets a preset condition; The master core is further configured to monitor the data in the shared memory area, and when monitoring that the slave core uploads the original log data to the shared memory area, read the log data uploaded by each of the slave cores in the shared memory area, and integrate and deeply analyze the log data uploaded by each of the slave cores to obtain global log data; The slave core is further used to detect target log data to determine the key indicators of the equipment operation status and task execution; and when an abnormality is detected in the target log data, an alarm log is generated, and the alarm log is uploaded to the master core through the shared memory area; wherein the target log data is log data whose storage requirement meets the preset storage requirement condition; The main core is also used to analyze the alarm log in combination with the global log data to locate the source of the exception, evaluate the impact range of the source of the exception, determine the exception analysis result, and trigger the global emergency processing task according to the exception analysis result.

2. The multi-core heterogeneous log management architecture according to claim 1, characterized in that: The slave core is further configured to start a detection strategy to execute a preset emergency processing task when it is determined that the abnormal analysis result meets a preset abnormal threshold; The master core is also used to call the anomaly detection model to adjust the detection strategy of the slave core.

3. The multi-core heterogeneous log management architecture according to claim 1, characterized in that: The main core is further used to monitor the global log data and determine the key logs from the global log data; store the key logs in the main core cache module; and write the key logs in the main core cache module to a high-speed storage device when it is detected that the power Hongmeng operating system is about to lose power; The slave core is further configured to save key state data through the lightweight cache module when it is detected that the power Hongmeng operating system is about to lose power; and write the key state data in the lightweight cache module into a non-volatile memory when a power outage is detected; The key status data includes the operation log and status information of the key tasks.

4. The multi-core heterogeneous log management architecture as described in claim 3, characterized in that: The main core is configured to determine and restore the key log from the high-speed storage device after the power Hongmeng operating system is restarted; The slave core is configured to determine and restore the key status data from the non-volatile memory after the power Hongmeng operating system is restarted, and transmit the restored key status data to the master core; The main core is also configured to restore the complete log running state according to the key log and the key status data, and the complete log running state is the running state of the Hongmeng operating system before the power outage occurs.

5. A log anomaly detection method, characterized in that: The log anomaly detection method is implemented based on the multi-core heterogeneous log management architecture according to any one of claims 1 to 4, and the method includes: The main core runs the power Hongmeng operating system; The slave core runs a naked running program, accesses hardware resources through the naked running program so that the log generation module generates original log data, and caches the original log data in real time in the lightweight cache module; The slave core runs a real-time operating system to provide real-time task scheduling and resource management, and optimizes the processing flow of the original log data through the real-time task scheduling and the resource management; When the data cached in the lightweight cache module reaches a preset condition, the slave core writes the log data located at the cache tail of the lightweight cache module into the shared memory area; The master core monitors the data in the shared memory area, and when monitoring that the slave core uploads the original log data to the shared memory area, reads the log data uploaded by each of the slave cores in the shared memory area, and integrates and deeply analyzes the log data uploaded by each of the slave cores to obtain global log data; The slave core detects the target log data to determine the key indicators of the equipment operation status and task execution; and when an abnormality is detected in the target log data, an alarm log is generated, and the alarm log is uploaded to the master core through the shared memory area; wherein the target log data is log data whose storage requirements meet the preset storage requirement conditions; The main core analyzes the alarm log in combination with the global log data to locate the source of the exception, evaluate the impact range of the source of the exception, determine the exception analysis result, and trigger a global emergency processing task based on the exception analysis result.

6. The log anomaly detection method according to claim 5, characterized in that: After the step of triggering a global emergency processing task according to the abnormal analysis result, the method further includes: The slave core starts the detection strategy to execute the preset emergency processing task when determining that the abnormal analysis result meets the preset abnormal threshold; The master core calls the anomaly detection model to adjust the detection strategy of the slave core.

7. The log anomaly detection method according to claim 5, characterized in that: The method further comprises: When the slave core detects a local failure, the slave core uploads the unprocessed log data to the master core; The master core monitors the running state of the slave core log module; wherein the slave core log module at least includes the log generation module, the lightweight cache module and the log upload module; the running state of the log generation module at least includes the log generation rate, the running state of the lightweight cache module at least includes the cache occupancy rate, and the running state of the log upload module at least includes the communication state; When the master core detects that an abnormality occurs in the slave core log module, it receives and integrates the unprocessed log data uploaded by the slave core to restore the complete log operation state of the slave core, where the complete log operation state of the slave core is the operation state before the abnormality occurs in the slave core.

8. The log anomaly detection method according to claim 7, characterized in that: When the slave core detects a local transmission failure, if the master core is unable to upload unprocessed log data to the master core, the method further includes: The slave core transfers the unprocessed log data to the standby device, so that the standby device stores the unprocessed log data of the slave core; The master core obtains and integrates the unprocessed log data of the slave core from the backup device to restore the complete log operation state of the slave core.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the log anomaly detection method according to any one of claims 6 to 8 are implemented.

10. A computer program product, characterized in that The computer program product stores a computer program, and when the computer program is executed by a processor, the steps of the log anomaly detection method according to any one of claims 5 to 8 are implemented.

Images