Data detection method and apparatus, device, and readable storage medium

Abstract

The application discloses a data detection method, device and equipment and a readable storage medium, and the method comprises the following steps: obtaining target server target downtime alarm information; the target downtime alarm information contains a current downtime classification result of the target server; collecting a model customized log corresponding to the target server according to the model of the target server; obtaining a downtime classification log matching library associated with the current downtime classification result from M downtime classification log matching libraries as a target downtime classification log matching library; if a matching downtime log matched with the model customized log is found in the target downtime classification log matching library, a downtime fault cause corresponding to the matching downtime log is determined as a target downtime fault cause of the target server. According to the application, the diagnosis accuracy of the server downtime fault cause can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data detection method, apparatus, device, and readable storage medium. Background Technology

[0002] With the rapid development of the internet, people's demand for online business applications has gradually increased, and the complexity of these applications has also continued to rise. Consequently, the scale of server clusters supporting these applications has gradually expanded to hundreds of thousands or even millions. However, the larger the server cluster, the more servers will experience downtime during operation.

[0003] Current diagnostic procedures for server downtime typically involve analyzing machine logs to determine the cause of the downtime. However, different causes of downtime require different types of logs to be analyzed. Due to the uncertainty of the cause, the diagnostic process often involves analyzing numerous machine logs unrelated to the specific cause of the downtime. These unrelated logs may then report errors or anomalies due to the server downtime, affecting the diagnostic results. Furthermore, some logs may correspond to multiple causes of downtime. Therefore, analyzing multiple log types can easily yield multiple possible causes of downtime. In such cases, operations engineers need to combine their experience to test and verify these multiple possible causes to arrive at a more accurate diagnosis, resulting in significant manpower and time costs. Summary of the Invention

[0004] This application provides a data detection method, apparatus, device, and readable storage medium, which can improve the accuracy of diagnosing server downtime faults and reduce labor and time costs.

[0005] This application provides a data detection method, which is executed by a detection service node and includes:

[0006] Retrieve target server crash alarm information; target crash alarm information includes the current crash classification result of the target server; the current crash classification result belongs to M crash classification results, where M is a positive integer; each crash classification result is associated with a crash classification log matching library; a crash classification log matching library contains one or more crash logs and the crash failure cause corresponding to each crash log;

[0007] Collect customized logs corresponding to the target server's model;

[0008] Obtain the crash classification log matching library associated with the current crash classification result from M crash classification log matching libraries, and use it as the target crash classification log matching library;

[0009] If a matching crash log that matches the machine-specific customized log is found in the target crash classification log matching library, the crash failure cause corresponding to the matching crash log is determined as the target server's target crash failure cause.

[0010] Specifically, it involves collecting customized logs for the target server based on its specific model, including:

[0011] From N customized log identifiers for different machine models, obtain the customized log identifier for the target server that matches the machine model, and use it as the customized log identifier for the target machine model; N is a positive integer;

[0012] Collect logs corresponding to the target machine model's customized log identifier from the target server, and use them as the target machine model's customized logs.

[0013] Among them, the target model customized log identifier includes out-of-band customized log identifier and in-band customized log identifier;

[0014] Logs corresponding to the target machine model's customized log identifier are collected from the target server and used as the target server's model-customized logs, including:

[0015] Logs corresponding to out-of-band customized log names are collected from the target server through an out-of-band network channel and used as out-of-band customized logs. The out-of-band network channel refers to a network channel that is independent of the in-band network channel. The in-band network channel refers to the network channel used by the target server to transmit business data.

[0016] Restart the target server;

[0017] If the target server fails to restart, the out-of-band customized logs will be determined as the customized logs for the target server's corresponding machine model.

[0018] If the target server restarts successfully, the logs corresponding to the in-band customized log names are collected from the target server through the in-band network channel and used as in-band customized logs. The out-of-band customized logs and in-band customized logs are identified as the model-specific customized logs for the target server.

[0019] The data detection methods also include:

[0020] When the cumulative detection time for downtime detection processing of the detected server cluster reaches the cumulative period, the number of downtime servers corresponding to the downtime servers is determined; a downtime server refers to a server in the detected server cluster that has experienced a downtime; downtime servers include the target server.

[0021] If the number of downed servers is less than the threshold for large-scale alarms, then proceed with the step of obtaining the target downed alarm information for the target server.

[0022] If the number of downed servers is greater than or equal to the threshold for large-scale alarms, then large-scale downtime fault diagnosis and handling will be performed on the downed servers.

[0023] The data detection methods also include:

[0024] If no matching crash log matching the machine model customization is found in the target crash classification log matching library, the controller operation result of the baseboard management controller corresponding to the target server is determined.

[0025] If the controller operation result is that the controller has been restarted, then the power supply unit of the target server is subjected to fault analysis and processing to obtain the power fault analysis result;

[0026] If the power failure analysis result is a power failure result, then the cause of the power failure is determined as the cause of the target server's downtime failure.

[0027] If the power supply failure analysis result is that the power supply is not faulty, then the motherboard failure is determined as the cause of the target server's downtime failure.

[0028] The data detection methods also include:

[0029] If no matching crash log matching the machine model is found in the target crash classification log matching library, and the current crash classification result is a logical disk read-only result, then the logical disk of the target server will be partitioned into read-only partitions to obtain the partition read-only result.

[0030] If the partition read-only determination result is a single partition read-only result, then the file system failure is determined to be the cause of the target server's crash failure.

[0031] If the partition read-only judgment result is multiple partition read-only, then the hard disk failure is determined to be the cause of the target server's downtime failure.

[0032] One embodiment of this application provides a data detection device, which is operated by a detection service node, and the device includes:

[0033] The first acquisition module is used to acquire the target server's target downtime alarm information; the target downtime alarm information includes the target server's current downtime classification result; the current downtime classification result belongs to M downtime classification results, where M is a positive integer; one downtime classification result is associated with one downtime classification log matching library; one downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log;

[0034] The data collection module is used to collect customized logs corresponding to the target server's machine model.

[0035] The second acquisition module is used to acquire the crash classification log matching library associated with the current crash classification result from M crash classification log matching libraries, and use it as the target crash classification log matching library;

[0036] The matching module is used to determine the cause of the downtime failure corresponding to the matching downtime log as the cause of the downtime failure of the target server if a matching downtime log that matches the customized log for the machine model is found in the target downtime category log matching library.

[0037] One embodiment of this application provides a computer device, including: a processor, a memory, and a network interface;

[0038] The processor is connected to the memory and the network interface. The network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiments of this application.

[0039] One aspect of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor and executing the methods described in this application.

[0040] One aspect of this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in this application.

[0041] In this embodiment, target server downtime alarm information is obtained. This target downtime alarm information includes the current downtime classification result of the target server. The current downtime classification result belongs to M downtime classification results. Each downtime classification result is associated with a downtime classification log matching library. Each downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log. Then, according to the target server's model, model-customized logs corresponding to the target server are collected, and the downtime classification log matching library associated with the current downtime classification result is obtained from the M downtime classification log matching libraries as the target downtime classification log matching library. Finally, if a matching downtime log that matches the model-customized log is found in the target downtime classification log matching library, the downtime fault cause corresponding to the matching downtime log is determined as the target downtime fault cause of the target server. The method provided in this application combines the crash classification results and the crash classification log matching library to avoid association issues. Specifically, a dedicated crash classification log matching library is built for a specific crash classification result, thereby preventing logs unrelated to the current crash classification result from interfering with the diagnostic results in the model-customized logs. This improves the accuracy of diagnosing server crash failures and reduces manpower and time costs. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram illustrating an application scenario of a data detection method provided in an embodiment of this application;

[0045] Figure 3 This is a flowchart illustrating a data detection method provided in an embodiment of this application;

[0046] Figure 4 This is a flowchart illustrating a data detection method provided in an embodiment of this application;

[0047] Figure 5 This is a schematic diagram of a comprehensive process for diagnosing downtime in a million-level server cluster, provided in an embodiment of this application.

[0048] Figure 6 This is a schematic diagram illustrating the result of restarting a target server according to an embodiment of this application;

[0049] Figure 7 This is a schematic diagram of the structure of a data detection device provided in an embodiment of this application;

[0050] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0051] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0052] To facilitate understanding, the following terms will be explained first:

[0053] The Baseboard Management Controller (BMC) is a server-specific management controller. One of the BMC's main functions is to automatically detect the server's operating status, primarily including the health status of each hardware component. By monitoring the health status of each hardware component and acquiring its information, the BMC helps maintenance personnel understand the server's operational status in a timely manner, ensuring the server's normal operation. When server problems occur, the BMC sends fault information to maintenance personnel through logs, assisting them in fault location.

[0054] Out-of-band communication: Using a dedicated channel (which can be called an in-band network channel) independent of the server's main data communication channel, it allows administrators to manage and monitor the server remotely without directly accessing the server's physical terminal. This is usually done through a serial port, IPMI, or a similar interface.

[0055] Out-of-band communication: Using a dedicated channel (which can be called an out-of-band network channel) that is independent of the server's main data communication channel, administrators can manage and monitor the server remotely without directly accessing the server's physical terminal. This is usually done through a serial port, IPMI, or similar interface.

[0056] For details, please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 1 As shown, this network architecture may include a detection service node 2000 and a server cluster. The server cluster may specifically include one or more servers; the number of servers in the server cluster is not limited here. Figure 1As shown, the multiple servers may specifically include server 3000a, server 3000b, server 3000c, ..., server 3000n; server 3000a, server 3000b, server 3000c, ..., server 3000n can communicate with the detection service node 2000 through a network (i.e., through a medium that provides a communication link via wired, wireless communication links or fiber optic cables, etc.) so that each server can interact with the detection service node 2000.

[0057] In this system, multiple servers in the server cluster will collaborate and work together via network connections, presenting themselves as a unified whole to provide services and process tasks. By integrating the computing power and storage resources of multiple servers, it can meet the needs of large-scale business applications for high concurrency, high reliability, high scalability, and powerful data processing capabilities. User requests from business applications will be rationally distributed to different servers in the server cluster for processing, thereby achieving load balancing. These business applications include, but are not limited to, games, video editing, social networking, instant messaging, live streaming, short video, video, music, shopping, novel, payment, and browsers.

[0058] Among them, the detection service node 2000 can be a computer device used to detect whether the servers in the server cluster have crashed and to diagnose the cause of the crash. The computer device can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0059] For ease of understanding, the embodiments of this application may be described in detail below. Figure 1 The server in the server cluster shown is selected as the target server from among multiple servers. For example, embodiments of this application can... Figure 1 The server 3000a shown is used as the target server.

[0060] like Figure 1As shown, when the target server crashes, the detection service node 2000 can use the data detection method provided in this application to determine the cause of the target server crash. Specifically, the data detection method can be as follows: Obtain the target server's target crash alarm information, which includes the target server's current crash classification result; the current crash classification result belongs to M crash classification results, where M is a positive integer; each crash classification result is associated with a crash classification log matching library; each crash classification log matching library contains one or more crash logs and the crash failure cause corresponding to each crash log; then, collect the model-customized logs corresponding to the target server's model; obtain the crash classification log matching library associated with the current crash classification result from the M crash classification log matching libraries, and use it as the target crash classification log matching library; finally, if a matching crash log matching the model-customized log is found in the target crash classification log matching library, the crash failure cause corresponding to the matching crash log is determined as the target server's target crash failure cause.

[0061] To facilitate understanding of the above data detection process, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating an application scenario of a data detection method provided in an embodiment of this application. For example... Figure 2 The detection service node 20a shown can be the above Figure 1 The detection service node 2000 in the corresponding embodiment, such as Figure 2 The server 20b shown can be the one described above. Figure 1 The target server in the corresponding embodiment. For ease of understanding, this application embodiment uses the data detection method executed by the detection service node 20a as an example for illustration.

[0062] like Figure 2 As shown, when the detection service node 20a detects that server 20b has crashed, it will obtain the crash alarm information A1 corresponding to server 20b (e.g., Figure 2 As shown in S211a), the downtime alarm information A1 will contain the current downtime classification result of server 20b, assuming it is downtime classification result E1. After obtaining the downtime alarm information A1 of server 20b, the detection service node 20a will collect the model-customized log C1 corresponding to the model of server 20b (e.g., Figure 2 (as shown in S212a).

[0063] like Figure 2As shown, the detection service node 20a can maintain a crash classification log matching library associated with different crash classification results. Assuming the server's crash classification results mainly include crash classification result E1, crash classification result E2, and crash classification result E3, then the detection service node 20a can contain a crash classification log matching library 201a associated with crash classification result E1, a crash classification log matching library 202a associated with crash classification result E2, and a crash classification log matching library 203a associated with crash classification result E3. It can be understood that because the current crash classification result of server 20b is crash classification result E1, the detection service node 20a selects the crash classification log matching library 201a associated with crash classification result E1 for subsequent log matching (e.g., ...). Figure 2 (As shown in S213a).

[0064] like Figure 2 As shown, the crash classification log matching library 201a can contain one or more crash logs, each with a corresponding crash fault cause. For example, crash log R1 corresponds to crash fault cause Y1, crash log R2 corresponds to crash fault cause Y2, and so on. The detection service node 20a will search the crash classification log matching library 201a for a matching crash log that matches the machine-customized log C1, and then obtain the crash fault cause corresponding to the matching crash log as the target crash fault cause 204a (e.g., Figure 2 (As shown in S214a). For example, assuming that the matching crash log that matches the machine-customized log C1 is crash log R3, then the target crash fault cause 204a is crash fault cause Y3.

[0065] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant regions.

[0066] It is understood that the above scenarios are merely examples and do not constitute a limitation on the application scenarios of the technical solutions provided in the embodiments of this application. The technical solutions of this application can also be applied to other scenarios. For example, as those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0067] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a data detection method provided in an embodiment of this application. The method can be implemented by a detection service node (e.g., the one described above). Figure 1 The detection service node 2000 in the corresponding embodiment executes the method. The following description uses the execution of this method by the detection service node as an example. This data detection method may include at least the following steps S101-S104:

[0068] Step S101: Obtain target downtime alarm information of the target server; the target downtime alarm information includes the current downtime classification result of the target server; the current downtime classification result belongs to M downtime classification results, where M is a positive integer; one downtime classification result is associated with one downtime classification log matching library; one downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log.

[0069] Specifically, the target server can be any server in the server cluster detected by the detection service node that has experienced a crash. The target crash alarm information refers to the crash alarm information corresponding to the target server. The detection service node can continuously detect whether the target server is down and simultaneously determine the current crash classification result of the target server, thereby generating the target crash alarm information for the target server.

[0070] Specifically, based on the actual operation of the server cluster, the downtime of the server can be pre-classified into M categories based on the fault symptoms. For example, in a common large-scale server cluster operation mode, server cluster downtime can be divided into three categories based on the fault symptoms: ping unreachable, agent (network proxy data) reporting timeout, and logical disk read-only. Ping unreachable means that the ping server cluster (usually containing 3 servers) cannot ping the target server within a certain period, so the current downtime classification of the target server is considered ping unreachable. Agent reporting timeout means that when the target server can be pinged, but the agent data on the target server cannot be reported to the backend system, the current downtime classification of the target server is considered agent reporting timeout. Logical disk read-only means that the agent periodically touches (creates) files on different partitions; when it cannot touch files, the current downtime classification of the target server is considered logical disk read-only. It is understandable that some failures that do not affect server usage are not considered downtime, such as failures of redundant disks, power supplies, or fans. Therefore, it is unnecessary to create a separate downtime category for these. The detection service node itself can be a server cluster, and the pingserver (service) cluster can be a smaller server cluster within it, or it can be a standalone server cluster; this application does not impose any restrictions on this.

[0071] Understandably, classifying server downtime is done to build different downtime classification log matching libraries for different classification results. This prevents logs unrelated to the classification from affecting the final cause diagnosis. For example, if the downtime classification result is logical disk read-only, there's no need to consider whether the power log is abnormal, as the two are unrelated. The logical disk read-only log matching library will not contain downtime logs related to power logs, thus avoiding an inaccurate diagnosis of power failure. When maintaining the downtime classification log matching library, it's necessary to avoid correlations between phenomena and case libraries. For example, common downtime causes in the ping unreachable log matching library mainly include uncorrectable memory errors, uncorrectable CPU errors, and uncorrectable network card errors. The downtime logs included in the ping unreachable log matching library mainly reflect these causes. Similarly, common downtime causes in the logical disk read-only log matching library include hard drive disconnection alarms and hard drive media errors.

[0072] Optionally, the detection service node can continuously perform downtime detection processing on the detected server cluster. When the cumulative detection time corresponding to the downtime detection processing of the detected server cluster reaches the periodic cumulative time, the number of downtime servers corresponding to the downtime servers is determined. A downtime server refers to a server in the detected server cluster that has experienced a downtime. The downtime servers include the target server. If the number of downtime servers is less than the large-scale alarm quantity threshold, the step of obtaining the target server's target downtime alarm information is executed. If the number of downtime servers is greater than or equal to the large-scale alarm quantity threshold, large-scale downtime fault diagnosis processing is performed on the downtime servers. The periodic cumulative time can be set based on the actual situation. For example, the periodic cumulative time can be ten minutes, one minute, or one hour, etc., and this application does not impose any restrictions. The large-scale alarm quantity threshold can also be set based on the actual situation. For example, if the number of servers in the detected server cluster is one hundred, the large-scale alarm quantity threshold can be set to 80 or 60, and this application does not impose any restrictions. It is understandable that when the number of downed servers is greater than or equal to the threshold for large-scale alarms, it is likely that the large number of alarms are caused by infrastructure failures, such as power outages in the data center, switch failures, or fiber optic failures in the data center. Such failures caused by infrastructure do not require individual diagnosis of the target servers. Instead, large-scale downtime fault diagnosis and handling can be performed on all downed servers, thereby saving downtime fault diagnosis time.

[0073] Step S102: Collect the model-customized logs corresponding to the target server according to the model of the target server.

[0074] Specifically, after confirming that the target server has crashed, customized logs can be collected based on the target server's model. These logs can potentially reveal the cause of the crash. For example, most models have the PSU (Power Supply Unit) E5 / E6 register logs, which can be used to determine the power-on time and the last restart time; AMD models have SyncFlood (a type of network attack) logs, which can be used to determine whether the last restart was caused by hardware; and Intel models have CPU (Central Processing Unit) temperature monitoring logs / Hyper-Threading technology status logs.

[0075] Specifically, a feasible implementation process for collecting customized logs for the target server based on its model can be as follows: From N customized log identifiers, obtain the customized log identifier that matches the target server's model, and use this as the target model customized log identifier; N is a positive integer. Collect the logs corresponding to the target model customized log identifier from the target server, and use these as the target server's model customized logs. Specifically, based on the characteristics of different models, different log types to be collected can be customized for different models, and different model customized identifiers corresponding to different models can be recorded in the detection service node. That is, one model customized log identifier can be associated with one model, and one model customized log identifier can contain one or more log identifiers. One log identifier is used to identify a log type, and the detection service node can obtain the target server's model customized logs based on the target model customized log identifier.

[0076] Specifically, the target model customized log identifier includes out-of-band customized log identifiers and in-band customized log identifiers. A feasible implementation process for collecting logs corresponding to the target model customized log identifiers from the target server as the target server's corresponding model customized logs can be as follows: Collect logs corresponding to the out-of-band customized log names from the target server via an out-of-band network channel as out-of-band customized logs; the out-of-band network channel refers to a network channel independent of the in-band network channel; the in-band network channel refers to the network channel used by the target server to transmit business data; restart the target server; if the target server restart fails, the out-of-band customized logs are identified as the target server's corresponding model customized logs; if the target server restarts successfully, collect logs corresponding to the in-band customized log names from the target server via an in-band network channel as in-band customized logs, and identify both the out-of-band and in-band customized logs as the target server's corresponding model customized logs. Out-of-band customized logs typically include SEL (System Event Log), SDR (Sensor Data Record), SNMPtrap (Simple Network Management Protocol Trap), power black box logs, out-of-band one-click logs, etc. SEL is a log file used by servers, network devices, or other computer systems to record important events occurring in the system, including hardware failures, system errors, configuration changes, and power status changes. SDR is a record of sensor data from sensors used to monitor the system's hardware status, containing information such as sensor type, location, measurement range, and current measurement value. SNMPtrap is a standard protocol used to manage and monitor network devices. When a network device (such as a router, switch, or server) detects a specific event or anomaly, it proactively sends an SNMP Trap message to a pre-configured management station. In-band customized logs can typically include messages, dmesg (a command in Unix-like systems), crash_dump (system crash dump), smart (Self-Monitoring, Analysis and Reporting Technology), and other component-level logs.Among these, `message` often appears in system log files, used to record various messages generated by the system and applications, including system startup and shutdown information, service status changes, user login and logout records, application runtime information, and error messages; `dmesg` is mainly used to display kernel messages during the system startup process and various diagnostic information and status messages generated by the kernel during system operation, including hardware detection information, driver loading status, system exceptions, and error messages; `crash_dump` saves critical information such as the system's memory state, register contents, and program execution status to disk when a serious error occurs (such as a kernel crash or application crash). A file or collection of data; SMART allows hard drives to automatically monitor and report their own health status, including key indicators such as disk temperature, head seek time, sector error rate, and remaining lifespan. It is understood that in this application, in addition to obtaining out-of-band customized logs via an out-of-band network channel after the target server crashes, the target server can also be restarted first, and upon successful restart, in-band customized logs can be obtained via an in-band network channel. Obtaining logs through both in-band and in-band methods can increase the coverage of software / hardware conditions reflected in the obtained machine-customized logs, thereby improving the success rate of subsequently determining the cause of the target server's crash based on the machine-customized logs.

[0077] Step S103: Obtain the crash classification log matching library associated with the current crash classification result from the M crash classification log matching libraries, and use it as the target crash classification log matching library.

[0078] Specifically, as shown in step S101 above, different crash classification log matching libraries are constructed for different crash classification results. A crash classification log matching library contains crash logs that represent the crash failure causes associated with the crash classification results. In other words, if a crash log reflects a crash failure cause that cannot lead to a certain crash classification result, that crash log will not be written into the crash log matching library associated with that crash classification result. For example, a data disk error cannot lead to a ping unreachable result; therefore, logs used to analyze data disk errors do not need to be added to the ping unreachable log matching library. It can be understood that in this application, by combining the correlation between crash classification results and crash failure causes to construct the crash classification log matching library, many logs unrelated to the crash classification results can be filtered out from being written into the crash classification log matching library. During log matching, interference from these log reports of anomalies or errors can be filtered out, thereby improving the accuracy of the final target crash failure cause.

[0079] Step S104: If a matching crash log that matches the customized log of the machine model is found in the target crash classification log matching library, then the crash failure cause corresponding to the matching crash log is determined as the target crash failure cause of the target server.

[0080] Specifically, the customized logs for a given device model can contain N logs, where N is a positive integer. The detection server can match these N logs with the crash logs in the target crash classification log matching library. If a successfully matched crash log is found, it is identified as the matched crash log. A successful match can mean that one or more of the N logs contain the same log content as the crash log. Optionally, to speed up the matching process, keyword comparison can be used.

[0081] Optionally, if no matching crash log matching the machine-specific log is found in the target crash classification log matching library, and the current crash classification result is a logical disk read-only result, then the logical disk of the target server is subjected to partition read-only judgment processing to obtain a partition read-only judgment result; if the partition read-only judgment result is a single partition read-only result, then the file system failure is determined to be the cause of the target server's target crash failure; if the partition read-only judgment result is multiple partition read-only results, then the hard disk failure is determined to be the cause of the target server's target crash failure. Here, a logical disk read-only result means that the logical disk of the target server can only read files and cannot touch files.

[0082] Optionally, if no matching crash log matching the customized log for the machine model is found in the target crash classification log matching library, and the current crash classification result is a read-only result for the logical disk, then the logical disk of the target server is restarted to determine the restart result of the logical disk of the target server. If the restart result is a read-only result, the hard disk failure can be determined as the cause of the target server's crash failure. A read-only result means that after restarting, the logical disk of the target server can still only read files and cannot touch files.

[0083] Optionally, for servers in a server cluster, some servers may have batch issues, including hardware and firmware problems. If the cause of the target server's downtime is not determined through the preceding process, it can be determined that the target server is associated with a batch issue. Then, it is determined whether the batch issue of the target server leads to the current downtime classification result of the target server. If so, the batch issue associated with the target server is determined as the cause of the target server's downtime. For example, when a machine experiences a BMC reset (referring to a baseboard manager reset), if it happens to be a motherboard within the batch issue range (e.g., a capacitor malfunction causing a power supply malfunction), it will be judged as a motherboard failure; if the machine's logical drive is read-only, and the machine's firmware happens to be on the batch issue vulnerability list, it will be diagnosed as a hard drive failure.

[0084] The method provided in this application constructs multiple crash classification log matching libraries for different crash classification results based on the correlation between crash classification results and crash failure causes. These crash classification log matching libraries do not contain crash logs corresponding to crash failure causes that cannot lead to the current crash classification result, thereby achieving irrelevant log avoidance. That is, it avoids log interference from machine-customized logs that are unrelated to the current crash classification result, thereby improving the diagnostic accuracy of the crash failure cause of the target server and reducing manpower and time costs.

[0085] Further, please see Figure 4 , Figure 4 This is a flowchart illustrating a data detection method provided in an embodiment of this application. The method can be implemented by a detection service node (e.g., the one described above). Figure 1 The detection service node 2000 in the corresponding embodiment executes the method. The following description uses the execution of this method by the detection service node as an example. This data detection method may include at least the following steps S201-S207:

[0086] Step S201: Obtain target downtime alarm information of the target server; the target downtime alarm information includes the current downtime classification result of the target server; the current downtime classification result belongs to M downtime classification results, where M is a positive integer; one downtime classification result is associated with one downtime classification log matching library; one downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log.

[0087] Step S202: Collect the model-customized logs corresponding to the target server according to the model of the target server.

[0088] Step S203: Obtain the crash classification log matching library associated with the current crash classification result from the M crash classification log matching libraries, and use it as the target crash classification log matching library.

[0089] Step S204: If a matching crash log that matches the customized log of the machine model is found in the target crash classification log matching library, then the crash failure cause corresponding to the matching crash log is determined as the target crash failure cause of the target server.

[0090] Specifically, the implementation process of steps S201-S204 can be found in the implementation process of steps S101-S104 above, and will not be repeated here.

[0091] Step S205: If no matching crash log matching the customized log of the model is found in the target crash classification log matching library, then the controller operation result of the baseboard management controller corresponding to the target server is determined.

[0092] Specifically, if no matching crash logs matching the customized logs for the target server are found in the target crash classification log matching library, it is very likely that the target server's baseboard management controller has encountered a problem (such as the baseboard management controller restarting or hanging). Because the machine's logging capability drops drastically when the target server's baseboard management controller malfunctions, with most logs being completely absent both in-band and out-of-band, the log matching steps described above may not be sufficient to determine whether the target server crash was caused by a hardware failure. Therefore, the detection service node can then retrieve the baseboard management controller's execution results to determine whether the baseboard management controller has restarted or hung.

[0093] Optionally, a feasible implementation process for determining whether the baseboard management controller has restarted can be as follows: by matching keywords in out-of-band logs, for example, by matching the restart keyword in the path of the BMC restart log of a certain model, thereby determining the time of the last restart of the baseboard management controller; if it occurred after the target server crashed, then the controller operation result of the baseboard management controller can be determined as the controller has restarted.

[0094] Optionally, a feasible implementation process for determining whether the baseboard management controller has restarted can be as follows: by judging through the SDR (Software Defined Radio) logs collected in real time in the background, the server cluster may be subjected to minute-level task collection. If data was collected normally before the crash, but no data is reported after the crash, it can be determined that the controller operation result of the baseboard management controller is that the controller has restarted.

[0095] Optionally, a feasible implementation process for determining whether the baseboard management controller has restarted can be as follows: judge by the restart result after the target server crashes. After the crash, the process will call out-of-band to restart. If the return is that the out-of-band network address cannot be pinged, it can also prove that it is an out-of-band restart or hangs. At this time, it can be determined that the controller operation result of the baseboard management controller is that the controller has restarted.

[0096] Step S206: If the controller operation result is that the controller has been restarted, then the power supply unit of the target server is subjected to fault analysis processing to obtain the power fault analysis result.

[0097] Specifically, the main causes of the baseboard management controller restart are PSU (Power Supply Unit) failure or motherboard failure. PSU failures are generally traceable; therefore, a fault analysis of the target server's power supply unit can be performed first to obtain the power supply fault analysis results. One feasible implementation for fault analysis of the target server's power supply unit is to obtain the target server's E5 / E6 registers and power black box logs to determine whether the target server's PSU is faulty.

[0098] Step S207: If the power failure analysis result is a power failure result, then the power failure cause is determined as the target server's target downtime failure cause; if the power failure analysis result is a power failure result, then the motherboard failure cause is determined as the target server's target downtime failure cause.

[0099] The method provided in this application embodiment can determine the cause of a target server's target server failure by using a target server failure classification log matching library associated with the current failure matching result when relatively complete machine-customized logs are available. It can also analyze the cause of a target server failure by combining the controller operation results of the target server's baseboard management controller when the cause of the target server failure cannot be determined by machine-customized logs. This further improves the success rate of analyzing the cause of a target server failure through automated processes, reduces human intervention, and thus saves labor costs.

[0100] Further, please see Figure 5 , Figure 5 This is a schematic diagram illustrating a comprehensive process for diagnosing downtime in a million-level server cluster, provided in an embodiment of this application. Figure 5 As shown, this integrated process can be executed by the detection service node, and the entire integrated process can include the following steps:

[0101] Step S51: Determine if a large-scale outage has occurred in the server cluster.

[0102] Specifically, server outages are mainly categorized into three types: ping unreachable, agent reporting timeout, and logical disk read-only, which will be used to explain the subsequent process. First, detecting service nodes requires determining whether the server cluster has experienced a large-scale outage; the determination process can be found above. Figure 3 The optional description of step S101 in the corresponding embodiment will not be repeated here.

[0103] Step S52: Collect customized logs from the target server.

[0104] Specifically, the customized logs refer to the customized logs for the aforementioned machine models. The implementation logic involves collecting out-of-band customized logs via out-of-band JobsVR (the machine managing the BMC cluster) or in-band customized logs via an in-band agent channel (collected after crash recovery; for example, SyncFlood logs can be collected under the OS after a machine reboot). The specific collection process can be found above. Figure 3 The specific description of step S102 in the corresponding embodiment will not be repeated here.

[0105] Step S53: Determine the restart result of the target server.

[0106] Specifically, upon obtaining business authorization, downed servers can be restarted first to allow for business migration and backup, minimizing business impact. Furthermore, in-band customized logs can only be obtained after a successful restart; therefore, restarting the target server is essential, and this process can also yield a lot of useful information, such as whether BMC has restarted and whether it can be started, which can be used for subsequent process analysis.

[0107] Optional, for ease of understanding, please also refer to Figure 6 , Figure 6 This is a schematic diagram illustrating the result of restarting a target server according to an embodiment of this application. Figure 6 As shown, after the target server restarts the node, there are two possible outcomes: one is a successful restart, which can be further divided into two types: one is that the server goes off (power off) after restarting, which is more related to hardware; the other is that the server is on (powered on) after restarting. However, the on-server can be further divided into two types: one is that the server is on and can be pinged, which is the most common type and is equivalent to a successful restart; the other is that the server remains unreachable after restarting, which is more related to the network card and hard drive. Another major category is that the server was off before restarting, which is also more related to hardware.

[0108] Step S54: Select the target outage classification log matching library for log matching based on the current outage classification result of the target server.

[0109] Specifically, the implementation process of step S54 can be found above. Figure 3 The specific description of step S104 in the corresponding embodiment will not be repeated here.

[0110] Step S55: Determine whether the log matching is successful. If yes, proceed to step S56; otherwise, proceed to step S57.

[0111] Step S56: When the cause of the crash corresponding to the crash matching log is determined to be the cause of the target crash, the process ends.

[0112] Step S57: Determine whether the baseboard management controller has been restarted. If yes, proceed to step S58; otherwise, proceed to step S59.

[0113] Step S58: Execute the baseboard management controller restart analysis sub-process. If the cause of the target shutdown failure is not found, proceed to step S59; if the cause of the target shutdown failure is found, end the process.

[0114] Specifically, the board management controller restart analysis subprocess is as described above. Figure 4 The processes described in steps S205-S207 of the corresponding embodiments will not be repeated here.

[0115] Step S59: Determine whether the logical disk is read-only; if yes, proceed to step S510; if no, proceed to step S511.

[0116] Step S510: Execute the logical disk read-only analysis sub-process. If the cause of the target crash is not found, proceed to step S511. If the cause of the target crash is found, end the process.

[0117] Specifically, the implementation process of the baseboard management controller restart analysis sub-process can be found above. Figure 3 The optional description of step S104 in the corresponding embodiment will not be repeated here.

[0118] Step S511: Determine if a batch issue has been detected; if yes, proceed to step S512; if no, proceed to step S513.

[0119] Step S512: Execute the batch problem analysis sub-process. If the cause of the target downtime failure is not found, proceed to step S513; if the cause of the target downtime failure is found, the process ends.

[0120] Specifically, the implementation process of the batch problem analysis sub-process can be found above. Figure 3 The optional description of step S104 in the corresponding embodiment will not be repeated here.

[0121] Step S513: Execute other special diagnostic rules.

[0122] Specifically, other special diagnostic rules refer to other diagnostic logics and solutions that contribute to fault diagnosis. These are generally fallback solutions, such as the syncflood logs of AMD models. This can clearly determine whether it is related to hardware, but it does not belong to the analysis process mentioned above. Only through the diagnostic results mentioned above can it be determined whether the collected logs are related to hardware.

[0123] The embodiments of this application provide more than 10 methods, including out-of-band / in-band / fault phenomena / active detection / batch problem association, to diagnose and analyze out-of-network servers in an automated manner, which greatly improves the proportion of automated analysis, reduces manpower input, and provides feasibility for large-scale operational analysis.

[0124] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a data detection device provided in an embodiment of this application. The data detection device can be a computer program (including program code) running on a computer device; for example, the data detection device is an application software. The data detection device 1 can be used to execute corresponding steps in the data detection method provided in the embodiment of this application. Figure 7 As shown, the data detection device 1 may include: a first acquisition module 110, a collection module 120, a second acquisition module 130, and a matching module 140.

[0125] The first acquisition module 110 acquires the target server's target downtime alarm information; the target downtime alarm information includes the target server's current downtime classification result; the current downtime classification result belongs to M downtime classification results, where M is a positive integer; each downtime classification result is associated with a downtime classification log matching library; a downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log;

[0126] The data collection module 120 collects customized logs corresponding to the target server model based on the target server model.

[0127] The second acquisition module 130 acquires a crash classification log matching library associated with the current crash classification result from M crash classification log matching libraries, and uses it as the target crash classification log matching library.

[0128] If the matching module 140 finds a matching crash log that matches the machine-customized log in the target crash classification log matching library, then the crash failure cause corresponding to the matching crash log is determined as the target crash failure cause of the target server.

[0129] In one possible implementation, when the collection module 120 collects model-customized logs corresponding to the target server based on the target server's model, it specifically performs the following operations:

[0130] From N customized log identifiers for different machine models, obtain the customized log identifier for the target server that matches the machine model, and use it as the customized log identifier for the target machine model; N is a positive integer;

[0131] Collect logs corresponding to the target machine model's customized log identifier from the target server, and use them as the target machine model's customized logs.

[0132] In one possible implementation, the target model customized log identifier includes an out-of-band customized log identifier and an in-band customized log identifier;

[0133] When the acquisition module 120 collects logs corresponding to the target machine model's customized log identifier from the target server, it is specifically used to perform the following operations:

[0134] Logs corresponding to out-of-band customized log names are collected from the target server through an out-of-band network channel and used as out-of-band customized logs. The out-of-band network channel refers to a network channel that is independent of the in-band network channel. The in-band network channel refers to the network channel used by the target server to transmit business data.

[0135] Restart the target server;

[0136] If the target server fails to restart, the out-of-band customized logs will be determined as the customized logs for the target server's corresponding machine model.

[0137] If the target server restarts successfully, the logs corresponding to the in-band customized log names are collected from the target server through the in-band network channel and used as in-band customized logs. The out-of-band customized logs and in-band customized logs are identified as the model-specific customized logs for the target server.

[0138] In one possible implementation, the data detection device 1 further includes a large-scale judgment module 150, which is used to perform the following operations:

[0139] When the cumulative detection time for downtime detection processing of the detected server cluster reaches the cumulative period, the number of downtime servers corresponding to the downtime servers is determined; a downtime server refers to a server in the detected server cluster that has experienced a downtime; downtime servers include the target server.

[0140] If the number of downed servers is less than the threshold for large-scale alarms, then proceed with the step of obtaining the target downed alarm information for the target server.

[0141] If the number of downed servers is greater than or equal to the threshold for large-scale alarms, then large-scale downtime fault diagnosis and handling will be performed on the downed servers.

[0142] In one possible implementation, the data detection device 1 further includes: a first analysis module 160, which is used to perform the following operations:

[0143] If no matching crash log matching the machine model customization is found in the target crash classification log matching library, the controller operation result of the baseboard management controller corresponding to the target server is determined.

[0144] If the controller operation result is that the controller has been restarted, then the power supply unit of the target server is subjected to fault analysis and processing to obtain the power fault analysis result;

[0145] If the power failure analysis result is a power failure result, then the cause of the power failure is determined as the cause of the target server's downtime failure.

[0146] If the power supply failure analysis result is that the power supply is not faulty, then the motherboard failure is determined as the cause of the target server's downtime failure.

[0147] In one possible implementation, the data detection device 1 further includes a second analysis module 170, which is used to perform the following operations:

[0148] If no matching crash log matching the machine model is found in the target crash classification log matching library, and the current crash classification result is a logical disk read-only result, then the logical disk of the target server will be partitioned into read-only partitions to obtain the partition read-only result.

[0149] If the partition read-only determination result is a single partition read-only result, then the file system failure is determined to be the cause of the target server's crash failure.

[0150] If the partition read-only judgment result is multiple partition read-only, then the hard disk failure is determined to be the cause of the target server's downtime failure.

[0151] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 8 As shown, the above Figure 7The data detection device 1 in the corresponding embodiment can be applied to a computer device 1000, which may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 8 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0152] In such Figure 8 In the computer device 1000 shown, the network interface 1004 provides network communication elements; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0153] Retrieve target server crash alarm information; target crash alarm information includes the current crash classification result of the target server; the current crash classification result belongs to M crash classification results, where M is a positive integer; each crash classification result is associated with a crash classification log matching library; a crash classification log matching library contains one or more crash logs and the crash failure cause corresponding to each crash log;

[0154] Collect customized logs corresponding to the target server's model;

[0155] Obtain the crash classification log matching library associated with the current crash classification result from M crash classification log matching libraries, and use it as the target crash classification log matching library;

[0156] If a matching crash log that matches the machine-specific customized log is found in the target crash classification log matching library, the crash failure cause corresponding to the matching crash log is determined as the target server's target crash failure cause.

[0157] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 4 The description of the data detection method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0158] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data detection device 1. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 4 The description of the data detection method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0159] The aforementioned computer-readable storage medium can be the data detection device provided in any of the foregoing embodiments or the internal storage unit of the aforementioned computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0160] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 4 The method provided in any of the corresponding embodiments.

[0161] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0162] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0163] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0164] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data detection method, characterized in that, The method is executed by the detection service node, and the method includes: Obtain target outage alarm information of the target server; the target outage alarm information includes the current outage classification result of the target server; the current outage classification result belongs to M outage classification results, where M is a positive integer; one outage classification result is associated with one outage classification log matching library; one outage classification log matching library contains one or more outage logs and the outage failure cause corresponding to each outage log; Collect customized logs corresponding to the target server model; Obtain the target crash classification log matching library from M crash classification log matching libraries that are associated with the current crash classification result; If a matching crash log that matches the customized log for the specified machine model is found in the target crash classification log matching library, then the crash failure cause corresponding to the matching crash log is determined as the target crash failure cause for the target server.

2. The method according to claim 1, characterized in that, The step of collecting customized logs corresponding to the target server's model based on the target server's model includes: From N customized log identifiers for different machine models, obtain the customized log identifier for the machine model that matches the target server, and use it as the target customized log identifier; where N is a positive integer; Logs corresponding to the customized log identifier of the target machine model are collected from the target server and used as the customized logs of the target machine model corresponding to the target server.

3. The method according to claim 2, characterized in that, The target model customized log identifier includes out-of-band customized log identifier and in-band customized log identifier; The step of collecting logs corresponding to the customized log identifier of the target machine model from the target server as the customized logs for the target machine model includes: Logs corresponding to the out-of-band customized log names are collected from the target server via an out-of-band network channel and used as out-of-band customized logs; the out-of-band network channel refers to a network channel independent of the in-band network channel; the in-band network channel refers to the network channel used by the target server to transmit business data; Restart the target server; If the target server fails to restart, the out-of-band customized log will be identified as the machine model customized log corresponding to the target server. If the target server restarts successfully, the logs corresponding to the in-band customized log names are collected from the target server through the in-band network channel as in-band customized logs. The out-of-band customized logs and the in-band customized logs are identified as the model-specific customized logs corresponding to the target server.

4. The method according to claim 1, characterized in that, Also includes: When the cumulative detection time for the downtime detection processing of the detected server cluster reaches the cumulative period, the number of downtime servers corresponding to the downtime servers is determined. The downed server refers to a server in the detected server cluster that has experienced a downtime; the downed server includes the target server; If the number of downed servers is less than the threshold for the number of large-scale alarms, then the step of obtaining the target downed alarm information of the target server is executed. If the number of downed servers is greater than or equal to the threshold for the number of large-scale alarms, then large-scale downtime fault diagnosis and processing will be performed on the downed servers.

5. The method according to claim 1, characterized in that, Also includes: If no matching crash log matching the customized log of the target crash category is found in the target crash classification log matching library, the controller operation result of the baseboard management controller corresponding to the target server is determined. If the controller operation result is that the controller has been restarted, then the power supply unit of the target server is subjected to fault analysis and processing to obtain the power fault analysis result; If the power failure analysis result is a power failure result, then the cause of the power failure is determined as the cause of the target server's downtime failure. If the power supply failure analysis result is that the power supply is not faulty, then the motherboard failure cause is determined as the target server downtime failure cause.

6. The method according to claim 1, characterized in that, Also includes: If no matching crash log matching the customized log of the machine model is found in the target crash classification log matching library, and the current crash classification result is a logical disk read-only result, then the logical disk of the target server is subjected to partition read-only judgment processing to obtain the partition read-only judgment result. If the partition read-only determination result is a single partition read-only result, then the file system failure cause is determined to be the target server's target downtime failure cause; If the partition read-only determination result is a multi-partition read-only result, then the hard disk failure cause is determined to be the target server's target downtime failure cause.

7. A data detection device, characterized in that, The device is operated by a detection service node, and the device includes: The first acquisition module is used to acquire target downtime alarm information of the target server; the target downtime alarm information includes the current downtime classification result of the target server; the current downtime classification result belongs to M downtime classification results, where M is a positive integer; one downtime classification result is associated with one downtime classification log matching library; one downtime classification log matching library contains one or more downtime logs and the downtime fault cause corresponding to each downtime log; The data collection module is used to collect customized logs corresponding to the target server based on the target server's model. The second acquisition module is used to acquire, from M crash classification log matching libraries, a crash classification log matching library associated with the current crash classification result, as the target crash classification log matching library; The matching module is used to determine the cause of the downtime failure corresponding to the matching downtime log as the cause of the downtime failure of the target server if a matching downtime log that matches the customized log of the machine model is found in the target downtime classification log matching library.

8. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method of any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they can perform the method described in any one of claims 1-6.

Images