Log management method, electronic device, storage medium and product

Abstract

The present application discloses a log management method, electronic device, storage medium and product, which relate to the field of computer technology. The method comprises the following steps: determining the fault level of the first server when a fault occurs in the first server; determining a log transmission interface corresponding to the fault level; transmitting the fault log in the first server to a target server through a transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; and when the fault of the first server is repaired, performing log recovery based on the fault log stored in the target server, so that the first server stores the recovered fault log, thereby realizing hierarchical transmission of fault logs in a server cluster environment, effectively avoiding the risk of single point failure, and ensuring the integrity and recoverability of the fault log even when fluctuations or interruptions occur in a complex network environment, thereby significantly improving the operation and maintenance reliability of the server cluster.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to log management methods, electronic devices, storage media, and products. Background Art

[0002] With the continuous advancement of server technology, server clusters are becoming increasingly large. While this large-scale cluster architecture improves system performance and processing capabilities, it also poses numerous challenges to cluster maintainability. When a server fails, a fault log is generated and transmitted to a management server via the network or a specific interface. The management server consolidates the information and provides feedback to operations and maintenance personnel for troubleshooting.

[0003] Currently, related technologies primarily focus on decentralized log storage and data verification. Regarding data transmission, these technologies still rely on cluster management servers and central network nodes to establish data transmission channels. This single transmission path and reliance on cluster management servers and central network nodes make it difficult to ensure the stability and reliability of log collection in complex network environments, increasing operational and maintenance challenges. Summary of the Invention

[0004] The present application provides a log management method, electronic device, storage medium and product to at least solve the problem in related technologies of single data transmission and easy loss of key alarm information.

[0005] This application provides a log management method, including:

[0006] When a failure occurs in the first server, determining a failure level of the first server;

[0007] Determine the log transmission interface corresponding to the fault level;

[0008] Transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log;

[0009] When the fault repair of the first server is completed, log recovery is performed based on the fault log stored in the target server, so that the first server stores the restored fault log.

[0010] This application also provides a log management device, including:

[0011] a level determination unit, configured to determine a fault level of the first server when a fault occurs to the first server;

[0012] An interface determination unit, configured to determine a log transmission interface corresponding to a fault level;

[0013] a transmission unit, configured to transmit the fault log in the first server to the target server through a transmission channel corresponding to the log transmission interface, so that the target server stores the fault log;

[0014] The recovery unit is configured to perform log recovery based on the fault log stored in the target server when the fault repair of the first server is completed, so that the first server stores the restored fault log.

[0015] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned log management methods when executing the computer program.

[0016] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned log management methods are implemented.

[0017] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned log management methods when executed by a processor.

[0018] Through the present application, when a fault occurs in the first server, the fault level of the first server is determined; the log transmission interface corresponding to the fault level is determined; the fault log in the first server is transmitted to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; when the fault of the first server is repaired, log recovery is performed based on the fault log stored in the target server, so that the first server stores the restored fault log, thereby realizing hierarchical transmission of fault logs in a server cluster environment, effectively avoiding the risk of single point failure, and ensuring the integrity and recoverability of the fault log even when fluctuations or interruptions occur in a complex network environment, thereby significantly improving the operation and maintenance reliability of the server cluster. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 A flow chart of a log management method provided in an embodiment of the present application;

[0021] Figure 2 A flow chart of a log management method provided in an embodiment of the present application;

[0022] Figure 3A flow chart of a log management method provided in an embodiment of the present application;

[0023] Figure 4 A flow chart of a log management method provided in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of a log management system provided in an embodiment of the present application;

[0025] Figure 6 A flow chart of a specific log management provided in an embodiment of the present application;

[0026] Figure 7 A schematic diagram of the structure of a log management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0028] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0029] With the continuous advancement of server technology, server clusters are becoming increasingly large. While this large-scale cluster architecture improves system performance and processing capabilities, it also poses numerous challenges to cluster maintainability. When a server fails, a fault log is generated and transmitted to a management server via the network or a specific interface. The management server consolidates the information and provides feedback to operations and maintenance personnel for troubleshooting.

[0030] Currently, related technologies mainly focus on decentralized log storage and data verification. In terms of data transmission, related technologies still rely on cluster management servers and central network nodes to build data transmission channels.

[0031] As can be seen, the related technology has a single transmission path, relying on cluster management servers and central network nodes. This makes it difficult to ensure the stability and reliability of log collection in complex network environments. Especially in high-threat scenarios, the time window for sending server fault logs is extremely limited, and there is usually only one opportunity to transmit fault information before the server crashes. Once a network or system anomaly occurs, even if the management server successfully captures the fault log, it cannot retrieve the log information again through repeated handshakes, resulting in the loss of critical fault information and increasing the difficulty of operation and maintenance.

[0032] The following briefly introduces several log management methods in related technologies:

[0033] Solution A proposes a data storage method that includes data identification and verification, including data classification and verification; encrypted data storage, including both encryption and data storage; and real-time behavior monitoring and anti-tampering mechanisms. The combination of data encryption and decentralized storage effectively reduces the risk of data leakage and tampering. By rationally combining symmetric and asymmetric encryption technologies and introducing decentralized storage, the computational burden of traditional public key encryption storage solutions is reduced.

[0034] Solution B proposes a blockchain-based inter-module call logging method and system. This includes deploying a blockchain platform: building a decentralized blockchain database on a server; writing call logs to the chain: when modules call each other, the call log data is written to the chain to ensure data security and integrity; locating anomalies: when inter-module data interaction issues arise, the offending module is quickly located by comparing the log data of the two organizations on the blockchain; and log data mining. The system includes a blockchain platform deployment unit, a call log writing unit, anomaly locating unit, and a log data mining unit.

[0035] Solution C proposes a fault detection method and server. This relates to the field of blockchain technology. It includes: obtaining a heartbeat message to be verified sent by a terminal to be verified from the blockchain network; obtaining a heartbeat log file sent by a heartbeat server from the blockchain network, the heartbeat log file including N preset heartbeat keepalive messages, where N is an integer greater than or equal to 1; and detecting whether the terminal to be verified is in a faulty state based on the heartbeat message to be verified and the preset heartbeat keepalive message. By utilizing the decentralized nature of the blockchain network, the heartbeat log file is guaranteed to be tamper-proof. Based on the heartbeat message to be verified and the preset heartbeat keepalive message, it is detected whether the terminal to be verified is in a faulty state. Heartbeat information can be obtained through different channels, and the security of the terminal to be verified can be monitored in real time, thereby improving the security of the terminal to be verified. The management behavior of the heartbeat server is made traceable through the heartbeat log file.

[0036] The above solution has the following defects:

[0037] (1) Considering only decentralized log storage and data verification, the data acquisition path still relies on the cluster management server and central network nodes, and cannot avoid log collection in complex network environments.

[0038] (2) Decentralization in data storage and verification cannot avoid the impact of centralized management of hardware physical links. The design function premise is based on the normal server network environment, especially the central node. The access is single and the overall maintainability of the cluster is weak.

[0039] (3) Although the introduction of various algorithms has improved the overall log distribution and retrieval efficiency, it cannot offset the exponential consumption of network resources compared to traditional log monitoring. The lack of a reasonable hierarchical storage system has led to high decentralized storage and verification costs, resulting in additional resource usage.

[0040] Therefore, the above solutions cannot save cluster logs in the event of network fluctuations or management machine abnormalities, and cannot reproduce faults in such situations, which reduces the maintainability of the cluster.

[0041] In order to solve the problems existing in the related solutions, an embodiment of the present application provides a log management method, including: when a first server fails, determining the fault level of the first server; determining a log transmission interface corresponding to the fault level; transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; when the first server fault is repaired, performing log recovery based on the fault log stored in the target server, so that the first server stores the recovered fault log, realizing hierarchical transmission of fault logs in a server cluster environment, effectively avoiding the risk of single point failure, and ensuring the integrity and recoverability of the fault log even when fluctuations or interruptions occur in a complex network environment, thereby significantly improving the operation and maintenance reliability of the server cluster.

[0042] The log management method provided by the embodiments of the present disclosure can be applied to fields such as cloud computing, financial transactions, industrial Internet of Things, Internet of Vehicles, and medical data management, which have strict requirements on high availability, strong consistency, and complex network disaster recovery.

[0043] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0044] Figure 1 A flow chart of a log management method provided by an embodiment of the present disclosure.

[0045] like Figure 1As shown, the method comprises the following steps:

[0046] Step 101: When a first server fails, determine the failure level of the first server.

[0047] In some embodiments, the present disclosure can utilize the built-in monitoring capabilities of the server's firmware or operating system to automatically detect and identify the specific type of the current fault (e.g., hardware failure, software crash, network outage, etc.). Based on a pre-configured mapping between fault type and fault level, the identified fault type is converted to the corresponding fault level.

[0048] Step 102: Determine the log transmission interface corresponding to the fault level.

[0049] In some embodiments, the present disclosure can select an appropriate log transmission interface based on the fault level to ensure that critical logs can still be reliably transmitted to the target server in a fault scenario. The log transmission interface in the present disclosure includes a first interface, a second interface, and a third interface. The first interface is specifically a BMC (Baseboard Management Controller) interface, the second interface is specifically an OS (Operating System) interface, and the third interface is specifically a hardware-level interface.

[0050] If the fault level is less than or equal to the first fault level, the log transmission interface is determined to be the first interface; if the fault level is greater than the first fault level and the fault is less than or equal to the second fault level, the log transmission interface is determined to be the first interface, the second interface and the third interface; if the fault level is greater than the second fault level, the log transmission interface is determined to be the first interface.

[0051] The first fault level and the second fault level in the present disclosure can be preset based on experience and are not limited in the embodiments of the present disclosure.

[0052] Step 103: The fault log in the first server is transmitted to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log.

[0053] In some embodiments, when a fault occurs, the server firmware and the server operating system will record a relevant alarm log, and the relevant alarm log is the fault log in the present disclosure.

[0054] When a fault occurs, the server firmware and operating system generate an alarm log (i.e., a fault log) recording detailed fault information. The log is transmitted to the target server via the interface determined in step 102 for storage and subsequent analysis and recovery. This includes transmitting the log via the server's BMC interface transmission channel (primary channel (BMC / IPMI, bandwidth 10 Mbps)); the OS interface transmission channel (alternative channel (OS network stack TCP / IP, bandwidth 1 Gbps)); and the hardware-level interface transmission channel (emergency channel (hardware-level NetConsole, bandwidth 1 Mbps)).

[0055] After receiving the fault log, the target server stores it in a local storage device (such as a hard disk) for subsequent analysis.

[0056] The target server in the present disclosure may include a management server and a second server. The present disclosure may transmit the fault log directly to the management server; or transmit the fault log to the second server, and then transmit the fault log to the management server via the second server.

[0057] Step 104 : When the fault repair of the first server is completed, log recovery is performed based on the fault log stored in the target server, so that the first server stores the restored fault log.

[0058] In some embodiments, after the first server fault is repaired, log recovery is required through the fault log stored in the target server to ensure that the first server can fully retain the log records during the fault period, which is crucial for subsequent fault analysis, auditing, and problem reproduction.

[0059] Specifically, when the first server detects that its status has been restored to "normal" or "repaired", the log recovery process is automatically triggered, or the administrator manually initiates the recovery operation.

[0060] The first server requests the target server to obtain the stored fault log, that is, sends a data collection request to the target server to obtain the fault log sent by the target server based on the data collection request.

[0061] During the log recovery process, the first server may also perform integrity verification (such as MD5 verification) on the recovered fault log to ensure that the log has not been tampered with or lost.

[0062] In the embodiment of the present disclosure, since the target server includes the management server and the second server, there may be some differences when performing log recovery.

[0063] If the fault log is transmitted to the management server through the transmission channel of the first interface, the fault log is only stored on the management server. When the first server performs log recovery, a data collection request can be directly sent to the management server to obtain the fault log sent by the management server based on the data collection request.

[0064] If the fault log is transmitted to the target server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface, the fault log is stored in the management server and / or the second server. When the first server performs log recovery, it can directly send a data collection request to the management server and the second server to obtain the fault log sent by the management server and the second server based on the data collection request.

[0065] If the fault log is transmitted to the second server through the transmission channel corresponding to the first interface (i.e., the broadcast storage mechanism), the fault log is only stored in the second server. When the first server performs log recovery, a data collection request can be sent to each second server; the data block sent by each second server based on the data collection request is obtained, and hash verification is performed based on the hash value stored in the blockchain and the hash value of each data block to obtain data blocks with consistent hash values; based on the erasure code technology, the data blocks with consistent hash values ​​are reorganized, and the reorganized data is used as the fault log.

[0066] Furthermore, for servers that haven't experienced any failures, the present disclosure can also perform real-time failure prediction for these servers. To more accurately predict server failures and enable timely action, the present disclosure also incorporates the MTBF / MTTR metric system. This system builds a failure prediction model by combining real-time data collected by hardware sensors, such as temperature, voltage, and ECC error rate. This model can assess the server's health in real time and predict the probability of server downtime (i.e., the failure probability in this disclosure). When the predicted failure probability exceeds a preset probability threshold (e.g., 70%), the present disclosure immediately initiates firmware-level emergency transmission to ensure that as much critical log information as possible is transmitted before the server fails, providing sufficient data support for subsequent troubleshooting. Specifically, this includes: when a first server hasn't experienced any failures, collecting sensor data from the first server; predicting the failure probability of the first server based on this sensor data and a preset failure prediction model; determining the first interface as the log transmission interface if the failure probability of the first server is greater than or equal to the preset probability threshold; and transmitting the fault log to the target server via the transmission channel corresponding to the first interface, i.e., the broadcast storage mechanism in this disclosure.

[0067] In non-emergency situations (i.e., the first server in this disclosure is not experiencing a failure), the cluster management server uses the traffic monitoring system to gain visibility into traffic conditions across various network segments and monitor the quality of each channel in real time, including key metrics such as bandwidth, latency, and packet loss rate. Based on this real-time monitoring data, this disclosure dynamically adjusts transmission priorities. For example, when the network quality of the primary channel (BMC / IPMI) is good, this channel is prioritized for log transmission. If the primary channel fails or network quality degrades, the system automatically switches the transmission task to the backup channel (OS network stack). If the backup channel also fails, the emergency channel (hardware-level NetConsole) is activated to ensure the successful transmission of critical logs. Specifically including: when the first server has not failed, determining the network quality data of the transmission channel corresponding to each of the first interface, the second interface and the third interface based on the preset channel quality scoring model; adjusting the transmission channel priority based on the network quality data of the transmission channel corresponding to each interface; adjusting the current log transmission channel according to the adjusted transmission channel priority, so as to transmit the fault log to the target server according to the adjusted log transmission channel, and the adjusted log transmission channel is any one of the transmission channel corresponding to the first interface, the transmission channel corresponding to the second interface and the transmission channel corresponding to the third interface. Among them, the channel quality scoring model can be pre-constructed by real-time monitoring of the packet loss rate (packet loss rate ≤ 5% is excellent), delay (delay ≤ 50ms is excellent), and bandwidth utilization (bandwidth utilization ≤ 80% is excellent) of each channel. In the present disclosure, the switching delay of adjusting the log transmission channel needs to be controlled within 200ms to ensure the continuity of log transmission.

[0068] In summary, through the present application, when a fault occurs in the first server, the fault level of the first server is determined; the log transmission interface corresponding to the fault level is determined; the fault log in the first server is transmitted to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; when the fault of the first server is repaired, log recovery is performed based on the fault log stored in the target server, so that the first server stores the restored fault log, thereby realizing hierarchical transmission of fault logs in a server cluster environment, effectively avoiding the risk of single point failure, and ensuring the integrity and recoverability of the fault log even when fluctuations or interruptions occur in a complex network environment, thereby significantly improving the operation and maintenance reliability of the server cluster.

[0069] Figure 2 The following further illustrates a flow chart of a log management method proposed in the present disclosure. Figure 1 In the embodiment shown, step 103 is further explained, the target server includes a management server, Figure 2 The following steps may be included.

[0070] Step 201: If the fault level is less than or equal to the first fault level, the fault log is transmitted to the management server through the transmission channel corresponding to the first interface.

[0071] In some embodiments, the first fault level indicates that the current fault is relatively minor.

[0072] At this point, if the first server's fault level is less than or equal to the first fault level, the first server will, in accordance with established rules, send a fault log containing detailed fault information to the management server via a transmission channel specifically associated with the first interface (i.e., the primary channel corresponding to the BMC interface). Management servers are typically used to centrally collect, store, and analyze operation logs and fault information from various devices or systems, allowing operations and maintenance personnel to promptly understand system operating conditions and take appropriate action.

[0073] Step 202: If the confirmation information fed back by the management server is not received within the preset period, the fault log is transmitted to the management server through the first interface until the confirmation information is received within the preset period.

[0074] In the present disclosure, the confirmation information is fed back by the management server based on the transmission channel corresponding to the first interface.

[0075] In some embodiments, if the number of times that the confirmation information is not received within the preset time period meets the preset number of times, the log transmission interface is determined to be the first interface, the second interface, and the third interface; the fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface, and the third interface. In other words, after the fault log is sent to the management server through the transmission channel corresponding to the first interface, the present disclosure will set a preset time period (for example, 10 seconds, 30 seconds, etc.) and wait for the management server to feedback confirmation information. The confirmation information is a handshake confirmation information, which is a notification returned to the sender through the transmission channel corresponding to the first interface after the management server successfully receives the fault log.

[0076] If no confirmation information is received within the preset period, the present disclosure will assume that the fault log may not have been successfully transmitted to the management server, and will therefore send the fault log again through the first interface. This process will be repeated until a confirmation information is successfully received from the management server within the preset period, thereby ensuring that the fault log can be reliably transmitted to the management server.

[0077] Furthermore, if the number of times confirmation information is not received within the preset time period meets the preset number, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server for each data block is determined; each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0078] When the number of times that the confirmation information fed back by the management server is not received within the preset time period reaches a preset number of times (for example, 3 times, 5 times, etc.), the present disclosure will consider that there may be a greater risk in transmitting the fault log through a single first interface, which may result in log loss. In order to improve the reliability of fault log transmission, the present disclosure will simultaneously select the first interface, the second interface and the third interface as log transmission interfaces. Then, the fault log is transmitted to the management server and the second server at the same time through the transmission channels corresponding to these three interfaces respectively. The second server refers to the server in the server cluster other than the first server. In this way, the present disclosure can ensure that the fault log can be received by as many servers as possible, reducing the risk of log loss.

[0079] If the number of times the confirmation information is not received within the preset time period meets the preset number of times, the broadcast storage mechanism is started, that is, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server for each data block is determined; each data block is transmitted to the second server through the transmission channel corresponding to the first interface, so as to further improve the flexibility and reliability of the fault log transmission, and it is also conducive to more detailed storage and management of the fault log.

[0080] In addition, the present disclosure can monitor in real time the network delay when transmitting the fault log through the transmission channel corresponding to the log transmission interface. Network delay refers to the time required for data to be transmitted from the sending end to the receiving end, that is, the network round-trip time RTT. When it is monitored that the duration of the network delay is greater than or equal to a pre-set preset delay duration (for example, 50 milliseconds, etc.), it means that there may be a problem with the current network condition, which may cause the failure of the fault log transmission or excessive delay. In order to deal with this situation, the present disclosure will start the broadcast storage mechanism and select the first interface as the log transmission interface to transmit the fault log to the second server through the first interface. Specifically, the present disclosure can detect the network delay of transmitting the fault log through the transmission channel corresponding to the log transmission interface; when the duration of the network delay is greater than or equal to the preset delay duration, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server of each data block is determined; each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0081] In summary, the present disclosure can select the corresponding transmission results based on the current fault level for lower fault levels, and flexibly adjust the log transmission interface and transmission strategy according to network conditions and transmission failures, ensuring that the fault log can be reliably and timely transmitted to the target server, providing strong support for system operation and management.

[0082] Figure 3 The following further illustrates a flow chart of a log management method proposed in the present disclosure. Figure 1 In the embodiment shown, step 103 is further explained, the target server includes a management server and a second server, Figure 3 The following steps may be included.

[0083] Step 301: If the fault level is greater than the first fault level and the fault level is less than or equal to the second fault level, the fault log is transmitted to the management server through the transmission channel corresponding to the first interface and the transmission channel corresponding to the second interface, and the fault log is transmitted to the second server through the transmission channel corresponding to the third interface. The second fault level is greater than the first fault level.

[0084] In some embodiments, the first fault level represents a minor fault, and the second fault level represents a more serious fault (for example, a sudden surge in the server CPU temperature). In this disclosure, a fault level greater than the first fault level and less than or equal to the second fault level is regarded as a medium fault level, representing a medium fault.

[0085] The present disclosure allows fault logs to be transmitted to a management server simultaneously via the transmission channel corresponding to the first interface and the transmission channel corresponding to the second interface. Using multiple interfaces for transmission improves data transmission reliability and prevents the failure of fault logs to be transmitted to the management server due to a single interface failure. Simultaneously, the fault log is transmitted to the second server via the transmission channel corresponding to the third interface, ensuring that fault information can be retrieved by multiple servers, enabling more comprehensive fault handling and analysis.

[0086] Step 302: If the confirmation information fed back by the management server is not received within the preset period, the fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface until the confirmation information is received within the preset period.

[0087] In the present disclosure, the confirmation information is fed back by the management server through any one of the transmission channel corresponding to the first interface and the transmission channel corresponding to the second interface and / or the second server through the transmission channel corresponding to the third interface.

[0088] In some embodiments, if the confirmation information fed back by the management server is not received within the preset time period, the present disclosure may adopt a repeated transmission strategy to simultaneously transmit the fault log to the management server and the second server through the transmission channels corresponding to the first interface, the second interface, and the third interface until the confirmation information is received within the preset time period. This repeated transmission strategy increases the probability of the fault log being successfully transmitted to the target server and ensures that the fault information is not lost due to transmission problems. The preset time period is to give the recipient sufficient time to process the fault log and feedback confirmation information. If the confirmation information is still not received after this period, it is considered that there may be a transmission problem.

[0089] Furthermore, after multiple attempts, there may be more serious transmission problems, and the transmission method of the fault log needs to be more strictly handled, that is, a broadcast storage mechanism is adopted, specifically including: if the number of times the confirmation information is not received within the preset time period meets the preset number of times, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server for each data block is determined; each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0090] Data block division can improve the flexibility and reliability of fault log transmission. If a data block fails to be transmitted, only the data block can be retransmitted without retransmitting the entire fault log. The second server for each data block can be reasonably allocated based on the content of the data block and the processing capacity of the second server. Each data block is transmitted to the second server separately through the transmission channel corresponding to the first interface. This transmission method further increases the reliability of data transmission and ensures that each data block can be successfully transmitted to the second server. It should be noted that in the present disclosure, each data block can be repeatedly transmitted to a preset number of second servers.

[0091] In addition, in order to ensure the transmission of fault logs even when the network delay is large and avoid the problem of fault information not being able to be transmitted in a timely manner due to network delay, the present invention can detect the network delay in transmitting the fault log through the transmission channel corresponding to the log transmission interface; when the duration of the network delay is greater than or equal to the preset delay duration, a broadcast storage mechanism is adopted to determine the log transmission interface as the first interface; the fault log is divided into multiple data blocks, and the second server for each data block is determined; and each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0092] In summary, this disclosure flexibly adjusts the fault log transmission method and channel based on factors such as fault severity, confirmation information reception, preset times, and network latency, ensuring reliable transmission of fault logs to the management server and secondary server. This allows operations and maintenance personnel to promptly understand the system's operating status and take appropriate action. This comprehensive consideration of fault severity, transmission reliability, and timeliness improves system stability and maintainability.

[0093] Figure 4 The following further illustrates a flow chart of a log management method proposed in the present disclosure. Figure 1 In the embodiment shown, step 103 is further explained, the target server includes a second server, Figure 4 The following steps may be included.

[0094] Step 401: If the fault level is greater than the second fault level, the fault log is divided into multiple data blocks, and the second server of each data block is determined.

[0095] In the present disclosure, the second fault level is greater than the first fault level.

[0096] Step 402: Transmit each data block to the second server through the transmission channel corresponding to the first interface.

[0097] In some embodiments, the present disclosure regards faults greater than the second fault level as high-risk level faults. At this time, the present disclosure adopts the BMC to adopt the network segment broadcast method to send relevant logs to all receivable devices in the network domain. Taking into account the situation that the server network segment and the BMC network segment are separated in the server cluster, the BMC will synchronize the operating system in the network segment and also adopt broadcast transmission, that is, the broadcast storage mechanism in the present disclosure.

[0098] The broadcast storage mechanism disclosed herein uses a blockchain-style storage structure to store key logs. Specifically, the fault log is divided into multiple data blocks (i.e., N data blocks) according to a preset size, and a cross-rack storage topology awareness algorithm is used to automatically calculate the topological relationship between different server nodes and management machine nodes in the cluster (i.e., the preset cluster node relationship in this disclosure). Based on the network delay and remaining storage space between the server nodes in the preset cluster node relationship, the preset number of second servers corresponding to each data block is determined, and each data block is sent to a different preset number (e.g., at least 3) of second servers. In order to further improve the disaster recovery effect, the preset number of second servers corresponding to each data block in this disclosure needs to ensure that these second servers are not in the same computer room or the same row.

[0099] The second server in this disclosure refers to a physical node, which can be a management server, a second server, or the BMC storage space in the transmission channel corresponding to the first interface. This distributed storage method greatly improves the reliability and availability of log data, and even if individual nodes fail, the integrity of the log data will not be affected.

[0100] When transmitting each data block to a corresponding preset number of second servers, the present disclosure ensures that the data is recoverable and reliable through the tamper-proof nature of the blockchain and the redundancy of distributed storage. The hash value corresponding to each data block can also be stored in the blockchains corresponding to multiple data blocks at the same time.

[0101] Specifically, the log file is first segmented into fixed-size data blocks (e.g., 256KB). Each data block is distributed across multiple secondary servers using the IPFS sharding storage mechanism. A unique hash value (e.g., SHA-3) is generated and written to the blockchain as evidence. To establish logical connections between blocks, the present disclosure can also construct a chained hash pointer structure. For example, the hash values ​​of adjacent data blocks can be embedded in the data header, or multiple data blocks can be aggregated through a Merkle tree to generate a root hash and store it on the blockchain. This ensures that the log sequence is irreversible and any tampering will cause the hash chain to break.

[0102] In order to speed up the location of decentralized stored data blocks, the present disclosure can also maintain a key-value index table (such as LevelDB) outside the chain to record the storage node address, timestamp and redundant copy location of each data block. The smart contract calculates the overall hash value of the index table at every fixed data block period (such as every 100 data blocks) and writes it into the blockchain, forming a double anti-tampering protection: an attacker needs to modify the index table content and its corresponding on-chain hash at the same time to destroy the data addressability, and the distributed consensus mechanism makes such attacks almost impossible to implement in a decentralized network.

[0103] In addition, when determining the second server for each data block, the present disclosure also needs to consider whether the second server fails. If the second server of the first data block fails, based on the election protocol, a third server is determined from multiple alternative servers connected to the first server, and the number of node votes of the third server within the preset election period is greater than or equal to the preset number of votes.

[0104] Specifically, to ensure that the present disclosure can continue to function even if some secondary servers fail, the present disclosure uses an election protocol (Raft) to implement dynamic storage server elections. By combining pre-set cluster node relationships, the leader, follower, and candidate nodes are configured, and a new leader node (i.e., the third server) is dynamically elected. This enables decentralized log storage in various scenarios and ensures that log integrity is maintained even if 50% of the nodes fail. The election process requires that the candidate node receive votes from at least 50% of the nodes within a random timeout of 150-300ms.

[0105] In summary, for high-risk fault levels, a log storage and broadcast mechanism can be implemented based on the current fault level to ensure that the fault log can be transmitted to the target server reliably and promptly, providing strong support for system operation, maintenance and management.

[0106] Based on the above Figures 1 to 4 The embodiment shown, as Figure 5 As shown, the present disclosure provides a schematic diagram of a log management system.

[0107] In an embodiment of the present disclosure, the log management system of the present disclosure includes a first server (ie Figure 5 The target server includes the management server and the second server (i.e. Figure 5 other servers in the .

[0108] The first server and the second server both include a first interface (i.e. Figure 5 BMC interface in the Figure 5 The OS interface in the Figure 5 The management server includes a first interface and a second interface.

[0109] When the fault level of the first server is less than or equal to the first fault level, the transmission channel (i.e. Figure 5 The network channel of the primary channel corresponding to the BMC interface in the switch is combined with the switch to transmit the fault log to the management server.

[0110] When the fault level of the first server is greater than the first fault level and less than or equal to the second fault level, the first interface and the second corresponding transmission channel (i.e. Figure 5 The network channel of the main channel corresponding to the BMC interface and the network channel of the alternative channel corresponding to the OS interface) are combined with the switch to transmit the fault log to the management server, and at the same time, the fault log is transmitted to the management server through the transmission channel corresponding to the third interface (i.e. Figure 5 The hardware-level connection of the emergency channel corresponding to the hardware-level interface in the communication channel) transmits the fault log to the second server.

[0111] When the fault level of the first server is greater than the second fault level, the log broadcast storage mechanism is adopted, that is, the fault log is divided into multiple data blocks, and the second server corresponding to each data block is selected and transmitted through the transmission channel corresponding to the first interface (i.e. Figure 5 The network channel of the primary channel corresponding to the BMC interface in the BMC) combines with the switch to transmit each data block to the corresponding second server.

[0112] For the specific log management methods of the log management system, please refer to Figures 1 to 4 The embodiments shown are not described in detail here.

[0113] based on Figures 1 to 5 In the embodiment shown, Figure 6 As shown, the present disclosure provides a specific flow chart of log management.

[0114] In the embodiment of the present disclosure, it is determined whether a server in the server cluster has failed. If the first server fails, the failure level of the first server is determined; if the first server does not fail, the log is transmitted to the management server (i.e., Figure 6 Determine whether the failure level of the first server is greater than the first failure level (i.e. Figure 6 If the fault level is less than or equal to the first fault level, the fault log is transmitted to the management server through the transmission channel corresponding to the first interface (i.e. Figure 6 If the fault level is greater than the first fault level, it is further determined whether the fault level is greater than the second fault level (i.e. Figure 6 If the fault level is greater than P2, and less than or equal to the second fault level, the fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface, and the third interface (i.e. Figure 6 If the fault level is greater than the second fault level, the fault log is divided into multiple data blocks through the broadcast storage mechanism, and the second server of each data block is determined. Each data block is transmitted to the second server through the transmission channel corresponding to the first interface (i.e. Figure 6 Fault logs are delivered to the cluster through a broadcast mechanism).

[0115] Among them, when the fault log is transmitted to the management server through the transmission channel corresponding to the first interface, and the fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface, it can be further determined whether the management server and / or the second server normally feedback confirmation information (i.e. Figure 6 In the process of judging whether the return value of the management machine is correct, the correct handshake information is returned, and judging whether the correctness of the return value is returned). If the confirmation information is not fed back normally, a higher level log transmission method is further adopted until the broadcast storage mechanism is adopted.

[0116] against Figure 6For ease of understanding, the embodiment shown in this disclosure uses a server failure involving a sudden spike in CPU temperature as an example. The specific log management method is as follows: The CPU temperature of a first server suddenly spikes. The log management system determines the first server's fault level to be severe (P2). This fault level is the same as the second fault level, meaning it is less than or equal to the second fault level (P2). The fault log is first transmitted via the transmission channels corresponding to the first, second, and third interfaces. However, due to network congestion, no response is received. After a preset period (5 seconds), the transmission channel corresponding to the first interface is automatically switched to, successfully splitting the log into three data blocks. Based on intelligent location selection rules, the three data blocks are stored in servers located in Cabinet 1 of Room A, Cabinet 3 of Room B, and Cabinet 5 of Room C. That afternoon, a power outage in Room B caused data loss on two servers. The log management system automatically collected data fragments from Rooms A and C, as well as two other functioning servers. Using a mathematical algorithm, the complete log is successfully restored, verifying the authenticity of the 10GB of data.

[0117] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0118] The embodiment of the present application further provides a log management device 700, Figure 7 A structural diagram of a log management device provided by an embodiment of the present disclosure is shown in FIG. Figure 7 Shown, including:

[0119] The level determination unit 710 is configured to determine a fault level of the first server when a fault occurs on the first server;

[0120] An interface determination unit 720 is configured to determine a log transmission interface corresponding to a fault level;

[0121] The transmission unit 730 is configured to transmit the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log;

[0122] The recovery unit 740 is configured to perform log recovery based on the fault log stored in the target server when the fault repair of the first server is completed, so that the first server stores the restored fault log.

[0123] The log management device disclosed herein determines the fault level of the first server when a fault occurs on the first server; determines the log transmission interface corresponding to the fault level; transmits the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; when the fault of the first server is repaired, performs log recovery based on the fault log stored in the target server, so that the first server stores the restored fault log, thereby realizing hierarchical transmission of fault logs in a server cluster environment, effectively avoiding the risk of single point failure, and ensuring the integrity and recoverability of the fault log even when fluctuations or interruptions occur in a complex network environment, thereby significantly improving the operation and maintenance reliability of the server cluster.

[0124] Furthermore, in a possible implementation of the embodiment of the present disclosure, the interface determination unit 720 is used to determine that the log transmission interface is the first interface if the fault level is less than or equal to the first fault level; if the fault level is greater than the first fault level, determine that the log transmission interface is the first interface, the second interface, and the third interface; if the fault level is greater than the second fault level, determine that the log transmission interface is the first interface.

[0125] Furthermore, in a possible implementation of the embodiment of the present disclosure, the target server includes a management server, and a transmission unit 730 is used to transmit the fault log to the management server through the transmission channel corresponding to the first interface if the fault level is less than or equal to the first fault level; if the confirmation information fed back by the management server is not received within the preset time period, the fault log is transmitted to the management server through the first interface until the confirmation information is received within the preset time period, and the confirmation information is fed back by the management server based on the transmission channel corresponding to the first interface.

[0126] Furthermore, in a possible implementation of the embodiment of the present disclosure, the target server includes a management server and a second server, and the transmission unit 730 is used to transmit the fault log to the management server through the transmission channel corresponding to the first interface and the transmission channel corresponding to the second interface if the fault level is greater than the first fault level and the fault level is less than or equal to the second fault level, and to transmit the fault log to the second server through the transmission channel corresponding to the third interface, and the second fault level is greater than the first fault level; if the confirmation information fed back by the management server is not received within the preset time period, the fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface until the confirmation information is received within the preset time period, and the confirmation information is fed back by the management server through any one of the transmission channels corresponding to the first interface and the second interface and / or the second server through the transmission channel corresponding to the third interface.

[0127] Furthermore, in a possible implementation of the embodiment of the present disclosure, the target server includes a second server, and a transmission unit 730 is used to divide the fault log into multiple data blocks and determine the second server for each data block if the fault level is greater than the second fault level, and the second fault level is greater than the first fault level; each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0128] Furthermore, in a possible implementation of the embodiment of the present disclosure, the transmission unit 730 is also used to, after the fault log is transmitted to the target server through the first interface, if the number of times the confirmation information is not received within the preset time period meets the preset number of times, determine that the log transmission interface is the first interface, the second interface and the third interface; and transmit the fault log to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface.

[0129] Furthermore, in a possible implementation of the embodiment of the present disclosure, the transmission unit 730 is also used to transmit the fault log to the target server through the transmission channels corresponding to the first interface, the second interface and the third interface. If the number of times the confirmation information is not received within the preset time period meets the preset number of times, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server of each data block is determined; and each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0130] Furthermore, in a possible implementation of the embodiment of the present disclosure, the device also includes: a fault prediction unit, which is used to collect sensor data of the first server when no fault occurs in the first server; based on the sensor data, combined with a preset fault prediction model, predict the failure probability of the first server; if the failure probability of the first server is greater than a preset probability threshold, determine that the log transmission interface is the first interface; and transmit the fault log to the target server through the transmission channel corresponding to the first interface.

[0131] Furthermore, in a possible implementation of the embodiment of the present disclosure, the transmission unit 730 is used to divide the fault log into multiple data blocks according to a preset size; based on the network delay and remaining storage space between the server nodes in the preset cluster node relationship, determine the preset number of second servers corresponding to each data block, and store the hash value corresponding to each data block in the blockchain corresponding to the multiple data blocks.

[0132] Furthermore, in a possible implementation of the embodiment of the present disclosure, the transmission unit 730 is used to detect the network delay in transmitting the fault log through the transmission channel corresponding to the log transmission interface; when the duration of the network delay is greater than the preset delay duration, the log transmission interface is determined to be the first interface; the fault log is divided into multiple data blocks, and the second server for each data block is determined; each data block is transmitted to the second server through the transmission channel corresponding to the first interface.

[0133] Furthermore, in a possible implementation of the embodiment of the present disclosure, the transmission unit 730 is used to determine a third server from multiple alternative servers connected to the first server based on an election protocol if the second server of the first data block fails, and the number of node votes of the third server within the preset election period is greater than the preset number of votes.

[0134] Furthermore, in a possible implementation of the embodiment of the present disclosure, the recovery unit 740 is configured to send a data collection request to each second server; obtain the data block sent by each second server based on the data collection request, and perform hash verification based on the hash value stored in the blockchain and the hash value of each data block to obtain data blocks with consistent hash values; based on erasure code technology, reorganize the data blocks with consistent hash values, and use the reorganized data as a fault log.

[0135] For the description of the features in the embodiment corresponding to the log management device, please refer to the relevant description of the embodiment corresponding to the log management method, and will not be repeated here.

[0136] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above-mentioned log management method embodiments.

[0137] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned log management method embodiments when running.

[0138] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0139] 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 of any of the above-mentioned log management method embodiments are implemented.

[0140] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned log management method embodiments are implemented.

[0141] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0142] The above is a detailed introduction to a log management method, electronic device, storage medium and product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A log management method, characterized in that: The method comprises: When a first server fails, determining a failure level of the first server; If the fault level is less than or equal to the first fault level, determining the log transmission interface to be the first interface; If the fault level is greater than the first fault level and the fault level is less than or equal to the second fault level, determining the log transmission interface to be the first interface, the second interface, and the third interface; If the fault level is greater than the second fault level, determining that the log transmission interface is the first interface; wherein the log transmission interface includes a first interface, a second interface, and a third interface, the first interface is a baseboard management controller interface, the second interface is an operating system, and the third interface is a hardware-level interface; Transmitting the fault log in the first server to a target server through a transmission channel corresponding to the log transmission interface, so that the target server stores the fault log; wherein the target server includes a management server and a second server, and the second server is a server in the server cluster other than the first server; When the fault repair of the first server is completed, performing log recovery based on the fault log stored in the target server, so that the first server stores the restored fault log; The step of transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface includes: If the fault level is greater than the first fault level and the fault level is less than or equal to the second fault level, the fault log is transmitted to the management server through the transmission channel corresponding to the first interface and the transmission channel corresponding to the second interface. and transmitting the fault log to the second server through the transmission channel corresponding to the third interface, wherein the second fault level is greater than the first fault level; If the confirmation information fed back by the management server is not received within the preset time period, the fault log will be transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface until the confirmation information is received within the preset time period; wherein, the confirmation information is fed back by the management server through any one of the transmission channels corresponding to the first interface and the transmission channel corresponding to the second interface and / or the second server through the transmission channel corresponding to the third interface.

2. The method according to claim 1, characterized in that The target server includes a management server, and transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface includes: If the fault level is less than or equal to the first fault level, transmitting the fault log to the management server through the transmission channel corresponding to the first interface; If the confirmation information fed back by the management server is not received within the preset time period, the fault log will be transmitted to the management server through the first interface until the confirmation information is received within the preset time period. The confirmation information is fed back by the management server based on the transmission channel corresponding to the first interface.

3. The method according to claim 1, characterized in that The target server includes a second server, and transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface includes: If the fault level is greater than the second fault level, dividing the fault log into a plurality of data blocks and determining a second server corresponding to each data block, and the second fault level is greater than the first fault level; Each of the data blocks is transmitted to the second server through the transmission channel corresponding to the first interface.

4. The method according to claim 2, characterized in that After transmitting the fault log to the target server through the first interface, the method further includes: If the number of times that the confirmation information is not received within the preset time period meets the preset number, determining that the log transmission interface is the first interface, the second interface, and the third interface; The fault log is transmitted to the management server and the second server through the transmission channels corresponding to the first interface, the second interface and the third interface.

5. The method according to claim 1 or 4, characterized in that After transmitting the fault log to the management server and the second server through the transmission channels corresponding to the first interface, the second interface, and the third interface, the method further includes: If the number of times that the confirmation information is not received within the preset time period meets the preset number of times, determining that the log transmission interface is the first interface; Dividing the fault log into a plurality of data blocks, and determining a second server corresponding to each data block; Each of the data blocks is transmitted to the second server through the transmission channel corresponding to the first interface.

6. The method according to claim 1, characterized in that The method further comprises: When the first server is not faulty, collecting sensor data of the first server; Predicting a failure probability of the first server based on the sensor data and in combination with a preset failure prediction model; If the failure probability of the first server is greater than or equal to a preset probability threshold, determining the log transmission interface to be the first interface; The fault log is transmitted to the target server through the transmission channel corresponding to the first interface.

7. The method according to claim 3, characterized in that Dividing the fault log into a plurality of data blocks and determining the second server corresponding to each data block includes: Dividing the fault log into multiple data blocks according to a preset size; Based on the network delay and remaining storage space between the server nodes in the preset cluster node relationship, a preset number of second servers corresponding to each data block is determined, and the hash value corresponding to each data block is stored in the blockchain corresponding to the multiple data blocks.

8. The method according to any one of claims 1 and 2, characterized in that The transmitting the fault log in the first server to the target server through the transmission channel corresponding to the log transmission interface includes: Detecting a network delay in transmitting the fault log through a transmission channel corresponding to the log transmission interface; When the duration of the network delay is greater than or equal to the preset delay duration, determining that the log transmission interface is the first interface; Dividing the fault log into a plurality of data blocks, and determining a second server corresponding to each data block; Each of the data blocks is transmitted to the second server through the transmission channel corresponding to the first interface.

9. The method according to claim 3, characterized in that Determining the second server corresponding to each data block includes: If the second server corresponding to the first data block fails, a third server is determined from multiple alternative servers connected to the first server based on the election protocol, and the number of node votes of the third server within the preset election period is greater than or equal to the preset number of votes.

10. The method according to claim 7, characterized in that The performing log recovery based on the fault log stored in the target server includes: sending a data collection request to each second server; Obtaining the data blocks sent by each second server based on the data collection request, and performing hash verification based on the hash value stored in the blockchain and the hash value of each data block to obtain data blocks with consistent hash values; Based on the erasure code technology, data blocks with consistent hash values ​​are reorganized, and the reorganized data is used as the fault log.

11. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the log management method according to any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the log management method according to any one of claims 1 to 10.

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the log management method according to any one of claims 1 to 10 are implemented.

Images