A storage engine state monitoring method, system, device and storage medium

Abstract

The application relates to a storage engine state monitoring method, system and device and a storage medium. The application calculates the metadata index size of a current file system log generated by a storage engine during OSD service running and the metadata index size of the file system log after log compaction; calculates a first ratio of the metadata index size of the current file system log to the boot area size of the storage engine and a second ratio of the metadata index size of the file system log after log compaction to the boot area size of the storage engine; compares the first ratio and the second ratio with a first threshold value and a second threshold value; and obtains the storage engine state according to the comparison result. The application considers the influence of the metadata size of the file system log on the OSD service storage engine state, more comprehensively monitors the storage engine state, timely monitors the storage engine state abnormity and carries out corresponding processing, and avoids business loss caused by the software reason leading to the storage engine abnormity.

Description

Technical Field

[0001] This invention relates to the field of distributed storage engine status monitoring, and in particular to a storage engine status monitoring method, system, device, and storage medium. Background Technology

[0002] In distributed storage systems, the failure of a single disk is treated as a high-probability failure. The causes of disk failures can be categorized into many types, some of which are hardware failures and others are software failures. For example, severe fragmentation of storage space or excessive amounts of storage service metadata can cause OSD service storage engine failures, preventing normal service provision. These software failures can be prevented through operation and maintenance commands.

[0003] Currently, regarding the causes of severe storage space fragmentation, patents CN201610692345.7 discloses a file fragmentation assessment method and terminal; patents CN201510940407.7 discloses a disk defragmentation method, device, and host; and patent CN202110712422.1 discloses a file system defragmentation method, device, and storage medium. All these patents compare the degree of fragmentation with a set threshold, automatically defragmenting fragments when the threshold is exceeded to prevent severe fragmentation from causing OSD service abnormalities. However, all of these patents lack analysis of the impact on metadata indexes. OSD service storage space is divided into two parts: a data partition and a metadata partition. The metadata partition stores the log system, used to record the data distribution on the data partition. Log system updates are also obtained by requesting space on the metadata partition, which may be continuous or discontinuous. When the space requested by the log system is discontinuous and the fragmentation degree is high, the log system index will be very large, potentially exceeding the index space reserved for the log system by the OSD service. This can cause the log system to fail to boot, leading to OSD service malfunction. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, the present invention provides a storage engine status monitoring method, system, device, and storage medium.

[0005] In a first aspect, the present invention provides a method for monitoring the status of a storage engine, comprising:

[0006] Calculate the metadata index size of the current file system log generated by the storage engine during OSD service operation and the metadata index size of the file system log after log compression;

[0007] Calculate the first ratio of the current file system log metadata index size to the storage engine boot area size; calculate the second ratio of the file system log metadata index size to the storage engine boot area size after log compaction.

[0008] The first ratio and the second ratio are compared with the first threshold and the second threshold; the storage engine status is obtained based on the comparison results.

[0009] If the first ratio and the second ratio are less than the first threshold, the storage engine is in a healthy state; if the first ratio and the second ratio are greater than the second threshold, the storage engine is in an error state; if the first ratio and the second ratio are between the first threshold and the second threshold, the storage engine is in a warning state. Furthermore, when the OSD service is created, the first threshold and the second threshold are initialized and increased sequentially based on the current remaining space of the storage medium and the minimum allocation unit.

[0010] Furthermore, when the storage engine requests the required space for current file system logging, it records the number of segments of the requested space. After the current file system logging is completed, it multiplies the final number of segments of the current file system log by the size of the metadata unit corresponding to each space to obtain the metadata index size of the current file system log metadata.

[0011] Furthermore, when requesting space for re-recording the compressed file system log after log compaction, the total number of segments of the requested space is recorded. The metadata index size of the file system log after log compaction is the product of the total number of segments and the size of the metadata unit corresponding to each space.

[0012] Furthermore, after the storage engine's metadata space reaches the compaction condition and is compacted, it triggers the size of the metadata index of all file system logs to be reduced to zero, and calculates the size of the metadata index of the file system logs after log compaction.

[0013] Furthermore, the OSD service monitoring thread periodically obtains the storage engine status. If the storage engine status is a warning, an OSD exception alarm is issued; if the storage engine status is an error, an OSD exception alarm is issued and OSD service writes are prohibited, while read and delete operations are allowed; if the status changes from an error state to a healthy state, OSD service writes are restored.

[0014] Furthermore, the determination of the storage engine status comprehensively considers the degree of fragmentation of the space requested by the OSD service storage engine when writing file system logs: obtaining the fragmentation score of the file system logs; three preset reference score intervals; if the fragmentation score is in the first reference score interval and the first ratio and the second ratio are less than the first threshold, the storage engine status is determined to be healthy; if the first ratio and the second ratio are greater than the second threshold, or if the fragmentation score is in the third reference score interval, the storage engine status is determined to be incorrect; otherwise, the storage engine status is determined to be warning.

[0015] Secondly, the present invention provides a storage engine status monitoring system, comprising:

[0016] A configuration module, which is used to configure parameters, including a first threshold and a second threshold;

[0017] Metadata index size calculation module, which calculates the metadata index size of the current file system log generated during the OSD service operation and the metadata index size of the file system log after log compression;

[0018] The status generation module compares a first ratio of the current file system log metadata index size to the storage engine boot area size with a first threshold and a second threshold; it also compares a second ratio of the file system log metadata index size after log compaction with the storage engine boot area size with the first and second thresholds; based on the comparison results, the storage engine status is determined as follows: if the first ratio and the second ratio are less than the first threshold, the storage engine status is determined to be healthy; if the first ratio and the second ratio are greater than the second threshold, the storage engine status is determined to be incorrect; if the first ratio and the second ratio are between the first threshold and the second threshold, the storage engine status is determined to be warning.

[0019] The monitoring module periodically acquires the storage engine status. If the storage engine status is a warning, it issues an OSD exception alarm; if the storage engine status is an error, it issues an OSD exception alarm and disables OSD service writes, while allowing read and delete operations; if it transitions from an error state to a healthy state, it restores OSD service writes.

[0020] Thirdly, the present invention provides a storage engine status monitoring device, comprising: at least one processing unit, a storage unit, and a bus unit, wherein the bus unit connects the processing unit and the storage unit, the storage unit stores data and a computer program, and the computer program, when executed by the processing unit, implements the storage engine status monitoring method.

[0021] Fourthly, the present invention provides a storage medium for implementing a storage engine status monitoring method, wherein the storage medium stores a computer program, and the computer program implements the storage engine status monitoring method when executed by a processor.

[0022] The technical solutions provided in the embodiments of the present invention have the following advantages compared with the prior art:

[0023] This application calculates the metadata index size of the current file system log generated by the storage engine during OSD service operation; and, in the case of log shrinking, calculates the metadata index size of the file system log after shrinking; calculates a first ratio of the current file system log metadata index size to the boot area size of the storage engine; calculates a second ratio of the file system log metadata index size after shrinking to the boot area size of the storage engine; compares the first and second ratios with a first and a second threshold; and determines the storage engine status based on the comparison results: if the first and second ratios are less than the first threshold, the storage engine status is healthy; if the first and second ratios are greater than the second threshold, the storage engine status is incorrect; and if the first and second ratios are between the first and second thresholds, the storage engine status is a warning. This implementation considers the impact of the OSD service file system log metadata index size on the storage engine status, providing a more comprehensive monitoring of the storage engine status, timely detection and handling of storage engine anomalies, and preventing business losses caused by software-related storage engine anomalies. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart illustrating a storage engine status monitoring method provided in an embodiment of the present invention;

[0027] Figure 2 A flowchart illustrating the calculation of the metadata index size of the current file system log generated by the storage engine during the operation of the OSD service, provided in an embodiment of the present invention.

[0028] Figure 3 A flowchart illustrating the calculation of the metadata index size of the compressed file system log generated by the storage engine after log compression, provided as an embodiment of the present invention;

[0029] Figure 4 A flowchart provided in this embodiment of the invention compares a first ratio, a second ratio, and a first threshold and a second threshold; and obtains the storage engine state based on the comparison result.

[0030] Figure 5A flowchart for determining the storage engine status by integrating file system fragmentation score and file system log metadata index size, provided for embodiments of the invention;

[0031] Figure 6 This is a schematic diagram of a storage engine status monitoring system provided in an embodiment of the present invention;

[0032] Figure 7 This is a schematic diagram of a storage engine status monitoring device provided in an embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0035] Example 1

[0036] The OSD service storage space is divided into two parts: a data partition and a metadata partition. The metadata partition stores the file system log, which records the data distribution on the data partition. Updates to the file system log are also obtained by allocating space on the metadata partition, which may be contiguous or discontinuous. When the space allocated for the file system log is discontinuous and highly fragmented, the metadata index of the file system log will be very large, potentially exceeding the index space reserved by the OSD service for the file system log metadata index. This can cause the file system log to fail to boot, leading to a situation where the OSD service cannot function properly. (See also...) Figure 1 As shown, this embodiment of the invention provides a storage engine status monitoring method that considers the impact of OSD service file system log metadata index size on storage engine status, including:

[0037] S100 pre-defines three status levels for the storage engine of the OSD service in the distributed storage system: health, warning, and error.

[0038] S200, when the OSD service is created, initializes a first threshold and a second threshold that increase sequentially based on the current remaining space of the distributed storage system's storage medium (i.e., the disk) and the minimum allocation unit. For example, the initialized first threshold is 0.8 and the second threshold is 0.9.

[0039] S300, in the absence of log compaction, calculates the size of the metadata index of the current file system log generated by the storage engine during the OSD service operation each time the file system log is updated, and in the case of log compaction, calculates the size of the metadata index of the compacted file system log generated by the storage engine after log compaction.

[0040] See Figure 2 As shown, the process of calculating the metadata index size of the current file system log generated by the storage engine during OSD service operation includes:

[0041] S301: When the storage engine requests space for current file system logging, it records the number of segments in the requested space. Specifically, the service's storage engine is a journaling file system. Therefore, during OSD service operation, the storage engine continuously generates file system logs. When requesting space for the file system logs, the requested space is non-contiguous disk space. Each segment of disk space requires corresponding metadata indexes to assemble the data from the non-contiguous disk spaces into a complete file system log.

[0042] S302, after the current file system log is completed, the metadata index size of the current file system log is obtained by multiplying the final number of segments requested by the current file system log by the size of the metadata unit corresponding to each space.

[0043] See Figure 3 As shown, the process of calculating the metadata index size of the compressed file system log generated by the storage engine after log compaction includes:

[0044] S310, obtain the total number of segments of the file system log after log compaction; in the specific implementation process, the storage engine does not continuously increase the file system log. When the file system log increases to a certain condition, it will trigger the compaction process, that is, remove the useless file system logs in the file system log and retain the newly added file system logs; in this process, all current file system logs are merged and the merged logs are flushed to a non-contiguous space.

[0045] S320, the metadata index size of the compressed file system log is obtained by multiplying the total number of segments by the size of the metadata unit corresponding to each space. When requesting space to re-record the compressed file system log after log compression, the total number of segments of the requested space is recorded, and the metadata index size of the compressed file system log is the product of the total number of segments and the size of the metadata unit corresponding to each space.

[0046] S400 calculates a first ratio between the current file system log metadata index size and the storage engine boot region size; or, in the case of log compaction, calculates a second ratio between the file system log metadata index size and the storage engine boot region size after log compaction. The storage engine boot region size is a parameter of the storage engine, which can have a default value or be configured according to the storage device.

[0047] S500, compare the first ratio and the second ratio with the first threshold and the second threshold; obtain the storage engine status based on the comparison result:

[0048] See Figure 4 As shown, if no log compaction occurs, and the first ratio is less than the first threshold, the storage engine is considered healthy. If log compaction occurs, and the second ratio is less than the first threshold, the storage engine is considered healthy. If no log compaction occurs, and the first ratio is greater than the second threshold, the storage engine is considered faulty. If log compaction occurs, and the second ratio is greater than the second threshold, the storage engine is considered faulty. If no log compaction occurs, and the first ratio is between the first and second thresholds, the storage engine is considered to be in a warning state. If log compaction occurs, and the second ratio is between the first and second thresholds, the storage engine is considered to be in a warning state.

[0049] In the S600, the OSD service monitoring thread periodically obtains the storage engine status and executes corresponding processing strategies based on the storage engine status. Specifically, if the storage engine status obtained by the OSD service monitoring thread is a warning, an OSD exception alarm is issued; if the storage engine status obtained by the OSD service monitoring thread is an error, an OSD exception alarm is issued, and OSD service writes are prohibited, while read and delete operations are allowed; if the status changes from an error state to a healthy state, OSD service writes are restored.

[0050] As a feasible implementation method, the percentage of OSD service monitoring threads that are running normally is monitored. If the percentage of OSD service monitoring threads that are running normally is lower than a set threshold, it indicates that the OSD service monitoring threads cannot monitor the storage engine of the OSD service in the distributed storage system in a timely manner and issue corresponding alarms.

[0051] Example 2

[0052] This invention provides a storage engine status monitoring method that integrates the impact of file system log fragmentation score and file system log metadata index size on storage engine status. The difference between this method and embodiment 1 is as follows:

[0053] Obtain the fragmentation score of the file system logs of the OSD service. In the specific implementation, the distributed storage has a built-in API to obtain the fragmentation score. Taking BLUESTORE (a type of CEPH distributed storage) as an example: execute "ceph daemon osd.123bluestore allocator score block" or "ceph-bluestore-tool --path / var / lib / ceph / osd / ceph-123 --allocator block free-score" to obtain the fragmentation score of BLUESTORE. The score takes values ​​in the range [0, 1].

[0054] Three reference score intervals are preset, including: a first reference interval, a second reference interval, and a third reference interval; one feasible first reference interval is [0-0.7], a second reference interval is [0.7-0.9], and a third reference interval is [0.9,1].

[0055] The storage engine status is determined by combining the file system fragmentation score and the file system log metadata index size.

[0056] If the fragmentation score is in the first reference score range and the first ratio and the second ratio are less than the first threshold, the storage engine is determined to be in a healthy state; if the first ratio and the second ratio are greater than the second threshold, or if the fragmentation score is in the third reference score range, the storage engine is determined to be in an error state; otherwise, the storage engine is determined to be in a warning state.

[0057] In the specific implementation process, please refer to Figure 5 As shown, the process of determining the storage engine status by combining the file system fragmentation score and the file system log metadata index size includes:

[0058] S1: Is the fragmentation score within the first reference score range? If yes, proceed to S2; otherwise, proceed to S507.

[0059] S2 determines whether log compaction has occurred; otherwise, execute S3; otherwise, execute S5.

[0060] S3. Compare whether the first ratio is greater than the second threshold. If yes, determine that the storage engine status is incorrect; otherwise, execute S4.

[0061] S4. Compare whether the first ratio is less than the first threshold. If yes, determine that the storage engine is in a healthy state; otherwise, determine that the storage engine is in a warning state.

[0062] S5. Compare whether the second ratio is less than the first threshold. If yes, determine that the storage engine is healthy; otherwise, execute S6.

[0063] S6. Compare whether the second ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, determine that the storage engine status is a warning.

[0064] S7. Check if the fragmentation score is within the third reference score range. If yes, determine the storage engine status as an error; otherwise, proceed to S8.

[0065] S8: Determine if log compaction has occurred. If not, execute S9; otherwise, execute S10.

[0066] S9. Compare whether the first ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, determine that the storage engine status is a warning.

[0067] S10. Compare whether the second ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, determine that the storage engine status is a warning.

[0068] Example 3

[0069] See Figure 6 As shown, this embodiment of the invention provides a storage engine status monitoring system, including:

[0070] The configuration module is used to configure parameters, including a first threshold and a second threshold. When determining the storage engine status by considering both the file system fragmentation score and the file system log metadata index size, the configured parameters also include the value range of three reference score intervals.

[0071] The metadata index size calculation module calculates the metadata index size of the current file system log generated during the OSD service operation and the metadata index size of the file system log after log compression. The calculation method is as described in step S300 of Embodiment 1, and will not be repeated here.

[0072] The fragmentation score acquisition module acquires the fragmentation score of the file system log when determining the storage engine status by combining the fragmentation score of the file system and the file system log metadata index size.

[0073] The status generation module determines the storage engine status based on the file system log metadata index size: it compares a first ratio of the current file system log metadata index size to the storage engine boot area size with a first threshold and a second threshold; in the case of log shrinking, it compares a second ratio of the shrinked file system log metadata index size to the storage engine boot area size with the first threshold and the second threshold, and obtains the storage engine status based on the comparison results: if the first ratio and the second ratio are less than the first threshold, the storage engine status is determined to be healthy; if the first ratio and the second ratio are greater than the second threshold, the storage engine status is determined to be incorrect; if the first ratio and the second ratio are between the first threshold and the second threshold, the storage engine status is warning.

[0074] Alternatively, the status generation module may combine the file system fragmentation score and the file system log metadata index size to determine the storage engine status: if the fragmentation score is in the first reference score range and the first ratio and the second ratio are less than the first threshold, the storage engine status is determined to be healthy; if the first ratio and the second ratio are greater than the second threshold, or if the fragmentation score is in the third reference score range, the storage engine status is determined to be incorrect; otherwise, the storage engine status is determined to be a warning.

[0075] The monitoring module periodically acquires the storage engine status. If the storage engine status is a warning, it issues an OSD exception alarm; if the storage engine status is an error, it issues an OSD exception alarm and disables OSD service writes, while allowing read and delete operations; if it transitions from an error state to a healthy state, it restores OSD service writes.

[0076] Example 4

[0077] See Figure 7 As shown, an embodiment of the present invention provides a storage engine status monitoring device, including: at least one processing unit, a storage unit and a bus unit, wherein the bus unit connects the processing unit and the storage unit, the storage unit stores data and a computer program, and the computer program implements the storage engine status monitoring method when executed by the processing unit.

[0078] Example 5

[0079] This invention provides a storage medium for implementing a storage engine status monitoring method. The storage medium stores a computer program, which, when executed by a processor, implements the storage engine status monitoring method.

[0080] In the embodiments provided by this invention, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, structures, or units, and may be electrical, mechanical, or other forms.

[0081] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0082] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0083] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for monitoring the status of a storage engine, characterized in that, include: Calculate the metadata index size of the current file system log generated by the storage engine during OSD service operation and the metadata index size of the file system log after log compression; Calculate the first ratio of the current file system log metadata index size to the storage engine boot region size; The second ratio of the metadata index size of the file system log after log compaction to the boot area size of the storage engine is calculated. The first ratio and the second ratio are compared with the first threshold and the second threshold; the storage engine status is obtained based on the comparison results. If no log compaction occurs, and the first ratio is less than the first threshold, the storage engine is considered healthy. If log compaction occurs, and the second ratio is less than the first threshold, the storage engine is considered healthy. If no log compaction occurs, and the first ratio is greater than the second threshold, the storage engine is considered faulty. If log compaction occurs, and the second ratio is greater than the second threshold, the storage engine is considered faulty. If no log compaction occurs, and the first ratio is between the first and second thresholds, the storage engine status is a warning. If log compaction occurs, and the second ratio is between the first and second thresholds, the storage engine status is a warning.

2. The storage engine state monitoring method of claim 1, wherein, When the OSD service is created, the first and second thresholds are initialized sequentially based on the current remaining space size of the storage medium and the minimum allocation unit.

3. The storage engine state monitoring method of claim 1, wherein, When requesting space for current file system logging, the number of segments of the requested space is recorded. After the current file system logging is completed, the metadata index size of the current file system log is obtained by multiplying the final number of segments of the current file system log by the size of the metadata unit corresponding to each space.

4. The storage engine state monitoring method of claim 1, wherein, When requesting space to re-record the compressed file system log after log compaction, the total number of segments in the requested space is recorded. The metadata index size of the compressed file system log is the product of the total number of segments and the size of the metadata unit corresponding to each space.

5. The storage engine state monitoring method of claim 4, wherein, After the storage engine's metadata space reaches the compaction condition and is compacted, it triggers the size of the metadata index of all file system logs to be reduced to zero, and calculates the size of the metadata index of the file system logs after the log compaction.

6. The storage engine state monitoring method of claim 1, wherein, The OSD service monitoring thread periodically obtains the storage engine status. If the storage engine status is a warning, it issues an OSD exception alarm. If the storage engine is in an error state, an OSD exception alarm is issued and OSD service write operations are disabled, while read and delete operations are allowed; if it transitions from an error state to a healthy state, OSD service write operations are restored.

7. The storage engine state monitoring method of claim 1, wherein, The determination of the storage engine status comprehensively considers the fragmentation score of the OSD service storage engine's write file system log, including: obtaining the fragmentation score of the file system log; three preset reference score intervals; S1, checking whether the fragmentation score is within the first reference score interval, if yes, execute S2, otherwise execute S7; S2, determine whether log compaction has occurred; otherwise, execute S3; otherwise, execute S5. S3, compare whether the first ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, execute S4. S4. Compare whether the first ratio is less than the first threshold. If yes, determine that the storage engine is in a healthy state; otherwise, determine that the storage engine is in a warning state. S5. Compare whether the second ratio is greater than the second threshold. If yes, determine that the storage engine status is an error. Otherwise, execute S6. S6. Compare whether the second ratio is less than the first threshold. If yes, determine that the storage engine is in a healthy state; otherwise, determine that the storage engine is in a warning state. S7. Is the fragmentation score within the third reference score range? If yes, determine the storage engine status as an error; otherwise, execute S8. S8, determine whether log compaction has occurred; otherwise, execute S9; otherwise, execute S10. S9. Compare whether the first ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, determine that the storage engine status is a warning. S10. Compare whether the second ratio is greater than the second threshold. If yes, determine that the storage engine status is an error; otherwise, determine that the storage engine status is a warning.

8. A storage engine state monitoring system implementing the storage engine state monitoring method of any of claims 1-7, characterized by include: A configuration module, which is used to configure parameters, including a first threshold and a second threshold; Metadata index size calculation module, which calculates the metadata index size of the current file system log generated during the OSD service operation and the metadata index size of the file system log after log compression; The status generation module compares a first ratio of the current file system log metadata index size to the storage engine boot area size with a first threshold and a second threshold; it also compares a second ratio of the file system log metadata index size to the storage engine boot area size after log compaction with the first and second thresholds; based on the comparison results, the storage engine status is determined as follows: if no log compaction occurs, and the first ratio is less than the first threshold, the storage engine status is determined to be healthy; if log compaction occurs, and the second ratio is less than the first threshold, the storage engine status is determined to be healthy; if no log compaction occurs, and the first ratio is greater than the second threshold, the storage engine status is determined to be faulty; if log compaction occurs, and the second ratio is greater than the second threshold, the storage engine status is determined to be faulty. If no log compaction occurs, and the first ratio is between the first and second thresholds, the storage engine status is a warning. If log compaction occurs, and the second ratio is between the first and second thresholds, the storage engine status is a warning. The monitoring module periodically acquires the storage engine status of the storage engine. If the storage engine status is a warning, it issues an OSD abnormality alarm. If the storage engine is in an error state, an OSD exception alarm is issued, and OSD service writes are prohibited, while read and delete operations are allowed; if it transitions from an error state to a healthy state, OSD service writes are restored.

9. A storage engine state monitoring apparatus, characterized by, include: The system includes at least one processing unit, a storage unit, and a bus unit, wherein the bus unit connects the processing unit and the storage unit, the storage unit stores data and a computer program, and the computer program, when executed by the processing unit, implements the storage engine status monitoring method as described in any one of claims 1-7.

10. A storage medium for implementing a storage engine status monitoring method, the storage medium storing a computer program, characterized in that, The computer program, which is executed by a processor, implements the storage engine state monitoring method as claimed in any one of claims 1-7.

Images