CN112860195A - Log storage method and device - Google Patents

Abstract

The invention discloses a log storage method and a log storage device, which can be applied to the field of cloud computing, and the method comprises the following steps: collecting log data to be stored; writing the collected log data into a memory file system; and performing persistent storage on the log data in the memory file system. According to the invention, the log data is written into the file system based on the memory, so that the IO jitter problem of disk storage can be avoided, the writing of the log data cannot be blocked, and the business process cannot be influenced.

Description

Log storage method and device

Technical Field

The invention discloses a log storage method and a log storage device, which can be applied to the field of cloud computing and can also be applied to any field except the field of cloud computing.

Background

This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein is not admitted to be prior art by inclusion in this section.

With the rapid development of cloud computing, distributed storage is more and more widely applied due to the characteristics of hardware decoupling, elastic expansion and the like, and the performance, high availability and the like are remarkably improved. However, due to the basic characteristic of scattering distributed storage slices, a single-node fault also has a more or less influence on the overall IO of the cluster, and although each distributed storage manufacturer optimizes the distributed storage slices in terms of architecture design, fault detection, isolation mechanisms and the like, the influence time can be shortened, and the influence cannot be completely eliminated. Therefore, under the condition that cluster IO jitter is caused by common faults of a distributed storage single disk or a single node and the like, a high-concurrency service transaction with extremely sensitive IO delay may fail due to timeout caused by failure of log write IO in time. Similarly, in a non-distributed storage scenario, such as centralized storage, a local disk, or the like, or in a case where the disk is busy in reading and writing, IO blocking of a file system may also occur due to a failure or the like, which affects log dropping, thereby affecting service transaction processing. Relatively speaking, file system IO blocking is more common in distributed storage scenarios.

For the problem of storage IO jitter blocking a service thread, the following two solutions are mainly adopted in the prior art:

the first is that log writing is modified into asynchronous IO at the application level (that is, after receiving an I/O request, the system first tells the application that the I/O request has been received, then goes to asynchronous processing, and after the processing is completed, the system tells the application result in an event notification manner, so that the process of IO processing does not block a thread, and other tasks, such as Java AIO, can be processed). The blocking is caused by waiting for synchronous IO (i.e. the system cannot respond to the application program immediately after receiving the I/O request, and the system can tell the application program the I/O result in a system call mode only after the processing is completed, and the process of IO processing blocks the thread and cannot process other tasks), and the modification of the program optimization IO model is the most direct and thorough method. The scheme for modifying the log writing into the asynchronous log writing in the application layer is most direct and thorough, but has higher relative investment cost, does not have modification conditions or has extremely high modification difficulty in many cases, for example, third-party products such as middleware and JDK do not master source codes, and even provide the source codes and do not have the capability of customized modification; or after the JVM GC log, the important audit log, etc. of the JDK are modified into an asynchronous log, abnormal log recording may be incomplete, which is unacceptable in some cases because asynchronous log writing cannot ensure that the log is successfully written into the disk.

The second is to add a separate local disk for log writing, usually two or more high-performance SSDs and configure RAID (RAID 1 or RAID5) to avoid interaction with other IO, and improve the performance and reliability of log IO writing. The application needs to be matched with transformation to adjust the path written in the log. The method for adding the independent local disk special for the log has small influence on an application layer, only needs to adjust the configuration of a log writing path, but has relatively high input cost, and needs to separately configure at least two high-performance disks (although the capacity of the whole disk may not be needed) and one disk array card to ensure performance and high availability. Meanwhile, the use scene of the scheme is limited to a certain extent, and the virtual machine can only be used in a physical airport scene, and the virtual machine loses the heat transfer characteristic due to the direct connection of the hard disk under the virtual machine scene, so that the heat upgrading capability of the data plane is influenced. Meanwhile, the operation and maintenance complexity and the operation and maintenance cost are greatly increased by using the distributed storage and the local disk in a mixed manner in the cloud environment, so that great difficulty exists in the implementation level of the virtualization scene.

In view of the above problems, no effective solution has been proposed.

Disclosure of Invention

The embodiment of the invention provides a log storage method, which is used for solving the technical problem that the distributed storage system blocks log writing due to storage IO jitter so as to cause overtime failure of service transaction, and comprises the following steps: collecting log data to be stored; writing the collected log data into a memory file system; and performing persistent storage on the log data in the memory file system.

The embodiment of the invention also provides a log storage device, which is used for solving the technical problem that the distributed storage system blocks the log writing disk due to the jitter of storage IO (input/output) so as to cause the overtime failure of the service transaction, and comprises the following steps: the log acquisition module is used for acquiring log data to be stored; the temporary log storage module is used for writing the acquired log data into a memory file system; and the log persistent storage module is used for persistently storing the log data in the memory file system.

The embodiment of the invention also provides computer equipment for solving the technical problem that the distributed storage system blocks log writing due to storage IO jitter so as to cause overtime failure of service transaction.

The embodiment of the invention also provides a computer readable storage medium, which is used for solving the technical problem that the distributed storage system fails due to overtime of business transaction because storage IO jitter blocks log writing.

According to the log storage method, the log storage device, the computer equipment and the computer readable storage medium provided by the embodiment of the invention, after the log data to be stored are collected, the collected log data are firstly written into the memory file system, and then the log data in the memory file system are subjected to persistent storage. Compared with the technical scheme of directly writing the log data into the disk in the prior art, the embodiment of the invention writes the log data into the file system based on the memory, can avoid the IO jitter problem of disk storage, cannot block the writing of the log data, and cannot influence the service process.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts. In the drawings:

fig. 1 is a flowchart of a log storage method provided in an embodiment of the present invention;

FIG. 2 is a flow chart of persistent storage of log data provided in an embodiment of the present invention;

fig. 3 is a flowchart of log data collection provided in an embodiment of the present invention;

FIG. 4 is a flowchart of an alternative log storage method provided in an embodiment of the present invention;

fig. 5 is a flowchart of a log storage implementation based on a Linux memory file system according to an embodiment of the present invention;

FIG. 6 is a diagram illustrating a log storage device according to an embodiment of the present invention;

fig. 7 is a schematic diagram of a computer device provided in an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the embodiments of the present invention are further described in detail below with reference to the accompanying drawings. The exemplary embodiments and descriptions of the present invention are provided to explain the present invention, but not to limit the present invention.

The embodiment of the invention provides a log storage method, which can effectively avoid the problem that the storage IO jitter blocks log writing due to reasons such as storage failure or busy of a disk, so that the business transaction is failed overtime.

Fig. 1 is a flowchart of a log storage method provided in an embodiment of the present invention, and as shown in fig. 1, the method includes the following steps:

and S101, collecting log data to be stored.

It should be noted that, a large amount of log data is generated during operation and operation of the service system, and the log data collected in S101 refers to log data to be written into the disk file system, which is generated during operation or operation of the service system.

And S102, writing the collected log data into a memory file system.

It should be noted that the memory file system in the embodiment of the present invention may be, but is not limited to, a Linux memory file system tmpfs; for example, the file system may be a memory-based file system such as ramdisk and ramfs.

S103, performing persistent storage on the log data in the memory file system.

It should be noted that, because the memory file system can only store data temporarily, log data in the memory file system needs to be stored persistently in the local disk file system or in other devices.

In an embodiment, as shown in fig. 2, the log storage method provided in the embodiment of the present invention may perform persistent storage on log data in the memory file system through S201 or S202:

s201, uploading log data in the memory file system to a log center cluster;

and S202, storing the log data in the memory file system to a local disk file system according to a pre-configured unloading period and a pre-configured storage path.

It should be noted that the log center cluster in the embodiment of the present invention refers to a system that provides mass log storage in a cluster manner, and can provide, but is not limited to, functions of log structured storage, online retrieval, and the like.

It should be noted that, in the embodiment of the present invention, in addition to supporting the above-mentioned unloading of the day-to-center cluster and the local disk file system, the persistent storage of the log data may also flexibly customize extensions according to different scenarios, for example, forwarding to an object storage, forwarding to a syslog server, or unloading to a shared file system.

Further, in an embodiment, the log storage method provided in the embodiment of the present invention may upload log data in the memory file system to the log center cluster in an asynchronous manner.

Further, in an embodiment, the log storage method provided in the embodiment of the present invention may upload log data in the memory file system to the log center cluster in an asynchronous manner by the following steps: sending the log data in the memory file system to a Kafka queue; and reading log data from the Kafka queue by the log center cluster and performing persistent storage.

In an embodiment, as shown in fig. 3, the log storage method provided in the embodiment of the present invention may collect log data to be stored through the following steps, including:

s301, monitoring whether log data in a log file or a log directory is updated or not;

s302, when the log data in the log file or the log directory is updated, the incremental log data is read.

After collecting log data to be stored, in an embodiment, as shown in fig. 4, the log storage method provided in the embodiment of the present invention may further include the following steps:

and S100, preprocessing the acquired log data according to the log storage requirement.

Fig. 5 is a flowchart for implementing log storage based on the Linux memory file system according to the embodiment of the present invention, and as shown in fig. 5, the log is written into the Linux memory file system tmpfs, and the log collection module is used in cooperation to implement log dump and persistence, and is suitable for use in virtual machines, physical machines, containers, and other scenes. Because tmpfs is a function supported by the Linux kernel, and kubernets also provides native support for tmpfs through an emptyDir type volume, the method is easier to implement and does not involve the modification of an application level.

In the log storage method based on the Linux memory file system provided by the embodiment of the invention, when the method is specifically implemented, the physical memory of the server is required to be sufficient (the occupied size of the tmpfs memory is increased on the basis of the service program memory requirement), and the swapp parameter is configured to be 0 or the swap is directly related according to the application condition, so that logs written in tmpfs are actually written into the physical memory, and the problem of disk IO jitter can be effectively avoided. Since all the contents in tmpfs are temporary, i.e. no file will be created on disk, if the tmpfs instance is unloaded (or the server is restarted, etc.), all the files saved therein will be lost. Therefore, in order to ensure that the log can be taken for problem analysis under abnormal conditions, the log persistence module is matched for use, so that the log file written into the tmpfs file system can be asynchronously persisted into a disk or other storage media.

The creation and the mounting in the tmpfs file system correspond to different embodiments under the scenes of a virtual machine, a physical machine and a container. Supporting the virtual machine and the physical machine mirror image to be pre-configured through/etc/fstab under the scenes of the virtual machine and the physical machine, or directly mounting in a system through a script; in the container scenario, the volume configuration of the emptyDir class based on K8s (i.e. Kubernates, which is a container scheduling framework of an open source) is performed, and the configuration is automatically applied when a Pod or a container is started through a cloud management platform, so that the application side is completely transparent.

In the above scheme, the flow direction of log data is mainly divided into three stages:

the first stage is as follows: the log is written to a tmpfs file system. The process is not different from writing in a common file system, and logs such as applications, middleware, JDKs and the like can be supported to be written in the directory;

and a second stage: and the log collection Agent detects the update of the log file and reads the updated content. The log collection Agent is an access component of the log center, monitors a log directory or a log file according to the specified configuration, and then reads the updated log lines in increments. The read log can be preprocessed according to needs, for example, whether the log is discarded or not is judged, the matching part field is checked, and then forwarding or disk writing is carried out;

and a third stage: and (5) collecting log persistence. The scheme provides two persistence modes, and the configuration is selected according to requirements. The first is uploading to a log center for centralized storage. In order to decouple the acquisition and storage links of the log center, ensure that logs are not lost due to abnormal reception of the log center and improve the throughput of log processing, a kafka queue is introduced, and the log acquisition Agent only needs to send acquired log information to the kafka queue (log production), and then the log center actively reads logs from the kafka queue (log consumption) and persists the logs to the log center cluster. The second is a local file system dump. The log collection Agent can regularly write the collected incremental log content into a file system according to the configuration of a configuration dump cycle, a path and the like, and the process of persisting to a disk is completed.

The log center cluster provided by the embodiment of the invention is mainly used for structured storage of massive logs and provides online retrieval capability, is a public log warehouse, can be used in scenes of collecting and storing other logs, has more specific implementation schemes, and is typically ElasticSearch.

Next, simulation test and comparison are performed on the influence of the service thread under the condition that the disk is busy:

the test environment is an 8C16G virtual machine, the speed limit is carried out on a virtual machine disk at the back end of storage (reading IOPS upper limit 100, writing IOPS upper limit 10; reading MBPS upper limit 100, writing MBPS upper limit 10), and the high IO load is simulated by using an IO pressurization script (by adopting direct IO bypassing the cache of an operating system).

The logic of the business thread simulation test program is to constantly generate 10KB objects and place them in a queue, and when the number of objects reaches 100000, half of the objects are removed from the queue. Therefore, the maximum number of objects stored in the heap is 100000, which may occupy 1GB of space, and this process may last for about 5 minutes, and frequently triggers the JVM GC (garbage collection mechanism). Log, analysis after the run ends, and statistics of JVM STW pause time (during GC event, application pause STM will be generated). The local disk write and the tmpfs write were each tested three times in succession and the effect of tmpfs was then used in a comparative analysis.

1) Writing the GC log to a local disk:

starting a background IO simulation script, executing a test program, designating a gc.log path as a local disk, continuously testing for three times, analyzing and recording the STW pause time, and realizing the following codes:

“$JAVA_PATH/java -Xmx10g -Xms10g -Xloggc:gc.log -XX:+UseG1GC-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps Test”

2) the GC log writes a tmpfs memory file system:

firstly, creating a tmpfs for storing the log, and implementing the code as follows:

“mkdir/logtmpfs

mount-t tmpfs-o size＝1G,nr_inodes＝1k,mode＝755tmpfs/logtmpfs”

the command will mount a tmpfs instance on/logmpfs, allocate 755 entitlement to 1GB RAM/SWAP (non-pre-emptive) space, and may have 10240 inode instances. The size parameter does not specify that the default value is half of the physical RAM without swap. If the tmpfs instance is too large, the machine may deadlock, requiring reasonable evaluation and use in conjunction with the conditions of the server's physical memory, because the OOM processing will not be able to release this memory. The nr _ inodes default value is half the number of pages of physical memory, or the number of pages of low-end memory RAM, whichever is lower, suggesting a combination of log write requirement determination.

And starting the background IO simulation script again, executing the test program, designating the gc.log path as/logmpfs, continuously testing for three times, analyzing and recording the STW pause time, and realizing the following codes:

“>$JAVA_PATH/java -Xmx10g -Xms10g -Xloggc:/logtmpfs/gc.log-XX:+UseG1GC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps Test”

the test results are shown in table 1.

TABLE 1 comparison of test results

It is obvious from the summary comparison of the test results shown in table 1 that after the GC log is written into the tmpfs memory file system, the program operation is not affected by busy disk IO any more, the STW pause time of the JVM is less than 200ms, and no second-level pause occurs.

Based on the same inventive concept, the embodiment of the present invention further provides a log storage apparatus, as described in the following embodiments. Because the principle of the device for solving the problems is similar to the log storage method, the implementation of the device can refer to the implementation of the log storage method, and repeated parts are not described again.

Fig. 6 is a schematic diagram of a log storage device provided in an embodiment of the present invention, and as shown in fig. 6, the log storage device includes: a log collection module 61, a log temporary storage module 62 and a log persistent storage module 63.

The log acquisition module 61 is used for acquiring log data to be stored; the log temporary storage module 62 is used for writing the acquired log data into a memory file system; and the log persistent storage module 63 is used for persistently storing log data in the memory file system.

It should be noted here that the log collection module 61, the log temporary storage module 62, and the log persistent storage module 63 correspond to S101 to S103 in the method embodiment, and the modules are the same as the examples and application scenarios realized by the corresponding steps, but are not limited to the disclosure of the method embodiment. It should be noted that the modules described above as part of an apparatus may be implemented in a computer system such as a set of computer-executable instructions.

In one embodiment, in the log storage apparatus provided in the embodiment of the present invention, the log persistent storage module 63 may include any one of the first persistent storage unit 631 and the second persistent storage unit 632.

The first persistent storage unit 631 is configured to upload log data in the memory file system to a log center cluster; the second persistent storage unit 632 is configured to store the log data in the memory file system to the local disk file system according to a pre-configured unloading period and a pre-configured storage path.

It should be noted here that the first persistent storage unit 631 and the second persistent storage unit 632 correspond to S201 and S202 in the method embodiment, and the modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the method embodiment. It should be noted that the modules described above as part of an apparatus may be implemented in a computer system such as a set of computer-executable instructions.

Further, in the log storage apparatus provided in the embodiment of the present invention, the first persistent storage unit 631 may be configured to upload log data in the memory file system to the log center cluster in an asynchronous manner.

Furthermore, in the log storage apparatus provided in the embodiment of the present invention, the first persistent storage unit 631 may further be configured to send log data in the memory file system to the Kafka queue; and reading the log data from the Kafka queue by the log center cluster and performing persistent storage.

In an embodiment, in the log storage device provided in the embodiment of the present invention, the log collection module 61 may specifically include: a log update monitoring unit 611 and an incremental log data reading unit 612.

The log update monitoring unit 611 is configured to monitor whether log data in a log file or a log directory has an update; an incremental log data reading unit 612, configured to read incremental log data when there is an update in the log data in the log file or the log directory.

It should be noted here that the log update monitoring unit 611 and the incremental log data reading unit 612 correspond to S301 and S302 in the method embodiment, and the modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the disclosure of the method embodiment. It should be noted that the modules described above as part of an apparatus may be implemented in a computer system such as a set of computer-executable instructions.

In an embodiment, the log storage apparatus provided in the embodiment of the present invention may further include: and the log data preprocessing module 64 is used for preprocessing the acquired log data according to the log storage requirement.

It should be noted here that the log data preprocessing module 64 corresponds to S100 in the method embodiment, and the module is the same as the example and application scenario realized by the corresponding steps, but is not limited to the disclosure of the method embodiment. It should be noted that the module as part of the apparatus may be implemented in a computer system such as a set of computer executable instructions.

Based on the same inventive concept, a computer device is further provided in the embodiments of the present invention to solve the technical problem that a distributed storage system fails to time out due to storage IO jitter blocking log writing, fig. 7 is a schematic diagram of a computer device provided in the embodiments of the present invention, as shown in fig. 7, the computer device 70 includes a memory 701, a processor 702, and a computer program stored in the memory 701 and operable on the processor 702, and the processor 702 implements the log storage method when executing the computer program.

Based on the same inventive concept, the embodiment of the present invention further provides a computer readable storage medium, so as to solve the technical problem that a distributed storage system blocks log writing due to storage IO jitter, thereby causing a business transaction timeout failure, where the computer readable storage medium stores a computer program for executing the log storage method.

In summary, according to the log storage method, the log storage device, the computer device, and the computer readable storage medium provided in the embodiments of the present invention, after the log data to be stored is collected, the collected log data is first written into the memory file system, and then the log data in the memory file system is persistently stored. Compared with the technical scheme of directly writing the log data into the disk in the prior art, the embodiment of the invention writes the log data into the file system based on the memory, can avoid the IO jitter problem of disk storage, cannot block the writing of the log data, and cannot influence the service process.

The embodiment of the invention solves the technical problem that the distributed storage system blocks the service thread due to the jitter of the disk storage IO, has the characteristics of simple implementation, low implementation cost and wide use scene, and can realize but not limited to the following technical effects:

the method has the advantages that the log data are written based on a memory file system (such as a Linux memory file system tmpfs), the implementation threshold is very low, the application and software product matching transformation is not involved, and the additional hardware investment cost is not needed;

scenes such as virtual machines, physical machines and containers are supported, and the characteristics such as virtual machine heat migration and container automatic drifting are not influenced;

and various log asynchronous persistent storage schemes are supported, flexible combination and configuration can be realized, and the requirements of different scenes are met.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.

Claims (16)

1. A method of log storage, comprising:

collecting log data to be stored;

writing the collected log data into a memory file system;

and performing persistent storage on the log data in the memory file system.

2. The method of claim 1, wherein persisting log data in the memory file system comprises:

and uploading the log data in the memory file system to a log center cluster.

3. The method of claim 2, wherein uploading log data in the in-memory file system to a log center cluster comprises:

and uploading the log data in the memory file system to a log center cluster in an asynchronous mode.

4. The method of claim 3, wherein uploading log data in the in-memory file system to a log center cluster in an asynchronous manner comprises:

sending the log data in the memory file system to a Kafka queue;

and reading log data from the Kafka queue by the log center cluster and performing persistent storage.

5. The method of claim 1, wherein persisting log data in the memory file system comprises:

and storing the log data in the memory file system to a local disk file system according to a pre-configured unloading period and a pre-configured storage path.

6. The method of claim 1, wherein collecting log data to be stored comprises:

monitoring whether log data in a log file or a log directory is updated or not;

and reading the incremental log data when the log data in the log file or the log directory has update.

7. The method of claim 1, wherein after collecting log data to be stored, the method further comprises:

and preprocessing the acquired log data according to the log storage requirement.

8. A log storage device, comprising:

the log acquisition module is used for acquiring log data to be stored;

the temporary log storage module is used for writing the acquired log data into a memory file system;

and the log persistent storage module is used for persistently storing the log data in the memory file system.

9. The apparatus of claim 8, wherein the log persistence storage module comprises:

and the first persistent storage unit is used for uploading the log data in the memory file system to a log center cluster.

10. The apparatus of claim 9, wherein the first persistent storage unit is configured to upload log data in the in-memory file system to a log center cluster in an asynchronous manner.

11. The apparatus of claim 10, wherein the first persistent storage unit is further configured to send log data in the memory file system to a Kafka queue; and reading log data from the Kafka queue by the log center cluster and performing persistent storage.

12. The apparatus of claim 8, wherein the log persistence storage module further comprises:

and the second persistent storage unit is used for storing the log data in the memory file system to a local disk file system according to a pre-configured unloading period and a pre-configured storage path.

13. The apparatus of claim 8, wherein the log collection module comprises:

the log updating monitoring unit is used for monitoring whether the log data in the log file or the log directory is updated or not;

and the incremental log data reading unit is used for reading the incremental log data when the log data in the log file or the log directory is updated.

14. The apparatus of claim 8, wherein the apparatus further comprises:

and the log data preprocessing module is used for preprocessing the acquired log data according to the log storage requirement.

15. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the log storage method of any one of claims 1 to 7 when executing the computer program.

16. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program for executing the log storing method of any one of claims 1 to 7.

Images