Server hard disk state monitoring method, device and equipment and storage medium

Abstract

The application provides a server hard disk state monitoring method and device, equipment and a storage medium, relates to the technical field of server operation and maintenance, solves the problem that the hard disk state of the server cannot be efficiently detected in the related art, and can automatically find each hard disk in all servers in a list file and obtain the hard disk state, thereby achieving simple and rapid batch monitoring of the hard disk state of the server, effectively saving the manpower of operation and maintenance, improving the efficiency of operation and maintenance, and guaranteeing the quality of operation and maintenance.

Description

Technical Field

[0001] This application relates to the field of server operation and maintenance technology, and in particular to a method, device, equipment and storage medium for monitoring the status of server hard disks. Background Technology

[0002] Servers typically use RAID (Redundant Array of Independent Disks) technology at the hardware level to connect at least two hard drives to a RAID controller (also known as an array card), forming an array and virtualizing it as a single logical hard drive for the operating system to use. This achieves data verification and redundancy protection functions. For example, if one hard drive fails, the server can still continue to operate normally, ensuring business continuity.

[0003] However, for server maintenance personnel, the above methods only buy more time for server maintenance. If the faulty hard drive is not replaced in time, and a second or third hard drive fails, the server's hard drive array will become unsustainable. This will not only cause the server to crash and interrupt business operations, but also potentially result in the complete loss of data, leading to catastrophic consequences. Therefore, the server's hard drive status must be monitored so that failures can be detected and replaced as soon as possible.

[0004] In existing technologies, hard drive health status information is mainly obtained from the server's hardware management network port through SNMP (Simple Network Management Protocol) or Redfish (a new generation server hardware management standard based on HTTPS protocol communication). However, both of these methods have serious shortcomings: SNMP cannot obtain hard drive status information for some new server models, and Redfish is difficult to efficiently monitor the hard drive status of a large number of servers. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for monitoring the status of server hard drives, which solves the problem of difficulty in efficiently detecting the status of hard drives of a large number of servers in related technologies. This application can automatically search for the URL of each hard drive in all servers in the first list file and obtain the health status of the hard drives, realizing simple and fast batch monitoring of server hard drive status, effectively saving manpower for operation and maintenance, improving the efficiency of operation and maintenance, and ensuring the quality of operation and maintenance.

[0006] In a first aspect, this application provides a method for monitoring the status of a server hard drive, applied to an electronic device. The electronic device includes a first list file, a second list file, a first temporary file, and a second temporary file. The first list file includes login information corresponding to several servers. The method for monitoring the status of the server hard drive includes: Read the login information corresponding to one of the servers from the first list file, and determine the first initial parameter based on the login information; Based on the preset first resource address format and first initial parameters, a first URL is constructed, and the keyword information in the resource data corresponding to the obtained first URL is used as the initial value of the second initial parameters; Based on the preset second resource address format, first initial parameter and second initial parameter, the second URL is constructed in a loop and the keyword information in the resource data corresponding to the second URL is obtained to update the second initial parameter until the re-obtained keyword information belongs to the target resource path and is recorded in the first temporary file; If the first temporary file is not empty, read the keyword information from the first temporary file as the initial value of the third initial parameter, and construct the third URL in sequence according to the preset third resource address format, the first initial parameter and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and record it in the second temporary file. Keyword information is read from the second temporary file as the initial value of the fourth initial parameter. Based on the preset fourth resource address format, the first initial parameter and the fourth initial parameter, the fourth URL is constructed in sequence and recorded in the second list file. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. With all fourth URLs corresponding to all servers recorded in the second list file, the resource data corresponding to each fourth URL is accessed one by one to determine the hard disk status of the server based on the target keyword information.

[0007] Secondly, this application also provides a server hard disk status monitoring device applied to an electronic device, the electronic device including a first list file, a second list file, a first temporary file, and a second temporary file, the first list file including login information corresponding to several servers, and the server hard disk status monitoring device including: The first parameter acquisition module is configured to read the login information corresponding to one of the servers from the first list file, so as to determine the first initial parameter based on the login information; The second parameter acquisition module is configured to construct a first URL based on a preset first resource address format and a first initial parameter, and use the keyword information in the resource data corresponding to the acquired first URL as the initial value of the second initial parameter. The third parameter acquisition module is configured to construct a second URL and acquire keyword information from the resource data corresponding to the second URL in a loop according to the preset second resource address format, the first initial parameter and the second initial parameter, so as to update the second initial parameter until the reacquired keyword information belongs to the target resource path and is recorded in the first temporary file; The fourth parameter acquisition module is configured to read keyword information from the first temporary file as the initial value of the third initial parameter if the first temporary file is not empty, and construct the third URL in sequence according to the preset third resource address format, the first initial parameter and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and record it in the second temporary file. The information acquisition module is configured to read keyword information from the second temporary file as the initial value of the fourth initial parameter, and construct the fourth URL in sequence according to the preset fourth resource address format, the first initial parameter and the fourth initial parameter and record it in the second list file. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. The status detection module is configured to access the resource data corresponding to each fourth URL one by one, in order to determine the hard disk status of the server based on the target keyword information, provided that all fourth URLs corresponding to all servers are recorded in the second list file.

[0008] Thirdly, this application also provides an electronic device comprising: One or more processors; Memory, used to store one or more programs. When one or more programs are executed by one or more processors, the one or more processors implement the server hard disk status monitoring method of this application.

[0009] Fourthly, this application also provides a storage medium storing computer-executable instructions, which, when executed by a processor, are used to execute the server hard disk status monitoring method of this application.

[0010] This solution can automatically locate each hard drive and obtain its status for all servers in the first list file. Only the first list file containing the IP address, username, and password of the servers to be monitored needs to be maintained. This allows for quick and easy batch monitoring of the hard drive status of all servers in the first list file, effectively saving manpower in operations and maintenance, improving efficiency, and ensuring the quality of operations and maintenance. Attached Figure Description

[0011] Figure 1This is a schematic diagram illustrating the steps of a server hard disk status monitoring method provided in an embodiment of this application; Figure 2 A flowchart illustrating a server hard disk status monitoring method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a server hard disk status monitoring device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0012] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the scope of this application. Furthermore, it should be noted that, for ease of description, the accompanying drawings only show the parts related to the embodiments of this application, not all structures. Those skilled in the art, after reading this specification, should be able to conceive that any combination of technical features can constitute an optional implementation method, provided that the technical features do not contradict each other.

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects, not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship. In the description of this application, "multiple" means two or more, and "several" means one or more.

[0014] In existing monitoring technologies, the health status of hard drives is primarily obtained by accessing the server's hardware management network port (also known as an out-of-band management port or remote control card). When a server hard drive fails, in addition to the indicator lights on the hard drive showing the fault, corresponding parameter values ​​within the server will also change. For example, the parameter value representing the hard drive's health status might change from 1 to 2 (assuming 1 represents normal or healthy, and 2 represents fault or unhealthy), or from OK to Critical or Degraded (assuming OK represents normal, and Critical or Degraded represents fault or unhealthy). These parameters and their values ​​are defined by the server manufacturer before the server leaves the factory. It is only necessary to directly obtain the corresponding parameter values ​​through the hardware management network port to determine whether the server hard drive has failed. Furthermore, because server hard drives are generally RAID-enabled, the failure of one drive does not affect server operation, and failed hard drives can be replaced without downtime using online hot-swapping. Therefore, they can be replaced promptly after failure, without needing to analyze various underlying operational status data of the hard drive to predict whether a failure is imminent.

[0015] Currently, there are two main methods to obtain parameters representing the health status of a hard drive through the server's hardware management network port. The first method is to read the OID (Object Identifier) ​​values ​​related to the server's hard drive using the traditional SNMP (Simple Network Management Protocol). The specific OIDs representing the hard drive's health status and their meanings are detailed in the MIB (Management Information Base) files provided by various server manufacturers. However, this method is outdated and has serious shortcomings. For example, in production practice, it has been found that some new server models no longer define OIDs for hard drives, making it impossible to obtain the hard drive's health status via SNMP.

[0016] The second method uses Redfish (a next-generation server hardware management standard based on HTTPS) resource URLs (Uniform Resource Locators) to obtain hardware resource data. As a next-generation server hardware management standard, Redfish is widely supported by various server manufacturers, defining corresponding resource URLs for each component, including hard drives. For example, when using the curl tool (Client for URL, a commonly used command-line tool for accessing URLs) to access the URL of a hard drive, the server will return the resource data of the corresponding hard drive in JSON (JavaScript Object Notation, an easy-to-read data representation format), which includes the hard drive's health status information. When the hard drive's health status cannot be obtained through SNMP, it can be obtained through Redfish. However, in production practice, this method has the following shortcomings: the resource URL hierarchy within the server is numerous, making it inconvenient to obtain the hard drive's URL. Not only are the hard drive URLs different between different servers, but the URLs of each hard drive are also not fixed and may change in certain situations. IT (Information Technology) data centers often house hundreds or even thousands of servers, each with two or more hard drives. Manually collecting the URLs of each hard drive would be not only labor-intensive but also inflexible in terms of maintenance, making it difficult to achieve efficient hard drive status monitoring for a large number of servers.

[0017] This application provides a method for monitoring the status of server hard drives. This method can automatically find the URL of each hard drive and obtain the health status of the hard drives for all servers in a first list file, thus realizing simple and fast batch monitoring of the hard drive status of servers.

[0018] Figure 1This diagram illustrates the steps of a server hard drive status monitoring method according to an embodiment of this application. The method can be applied to an electronic device, which can be a server or a computer connected to a server. The electronic device includes a first list file, a second list file, a first temporary file, and a second temporary file. It is conceivable that the electronic device includes a processor and a memory. The first list file, second list file, first temporary file, and second temporary file can be stored in the memory of the electronic device, while the processor is used to execute the server hard drive status monitoring method provided in this application. The first list file includes login information corresponding to several servers, enabling the electronic device to perform hard drive checks on all servers recorded in the file according to the first list file. It should be noted that the first list file, second list file, first temporary file, and second temporary file can all record corresponding information line by line.

[0019] Understandably, electronic devices can periodically execute this hard drive status monitoring method on all servers listed in the first list file as a monitoring task, thereby monitoring the hard drive status of all servers recorded in the first list file and enabling timely detection of hard drive failures. For example... Figure 1 As shown, the specific steps of this method include steps S110-S160: Step S110: Read the login information corresponding to one of the servers from the first list file, so as to determine the first initial parameter based on the login information.

[0020] The first list file stored in the electronic device stores the login information for the corresponding servers. The first list file records login information for several servers, the specific number corresponding to the number of servers whose hard drive status needs to be checked. It should be understood that if it is necessary to add new servers requiring hard drive status checks or delete some servers that no longer require checks, this can be done by editing the first list file, such as adding or deleting the corresponding login information.

[0021] Login information, as required to access the server, includes necessary target fields or parameters for server access. For example, in one embodiment, the IP address, username, and password corresponding to the server's hardware management network port are necessary target fields for server access. These three target fields are then used as login information and recorded in the first list file. Correspondingly, when reading the first list file, the login information corresponding to one of the servers is read, and the target fields in the login information are used as the first initial parameters.

[0022] It is conceivable that in the first list file, login information corresponding to different servers can be distinguished in a corresponding way. Optionally, in one embodiment, the login information is recorded in the form of rows, that is, the login information recorded in each row corresponds to one server. For example, the three target fields in the login information can be separated by commas. Thus, when reading the login information corresponding to one of the servers, the electronic device reads it row by row.

[0023] As can be imagined, the initial content of the second list file is empty, and it is used to record the URLs of all hard drives of all servers in the first list file (i.e., the fourth URL). Since this solution can be used as a monitoring task that is executed on a schedule, and the latest URLs will be collected again each time it is executed, the second list file needs to be cleared before execution in order to record the latest collected URL information.

[0024] Step S120: Construct a first URL according to the preset first resource address format and first initial parameters, and use the keyword information in the resource data corresponding to the obtained first URL as the initial value of the second initial parameters.

[0025] After confirming the login information, the electronic device needs to construct a first URL. This involves filling in the corresponding first initial parameters according to a preset first resource address format to form the first URL, thereby accessing the server's resource data. For example, in one embodiment, the first initial parameters include three sub-parameters: the IP address corresponding to the server's hardware management network port, the username, and the password, represented by P1a, P1b, and P1c, respectively. During the construction of the first URL, the IP address in the first initial parameters is filled in according to the first resource address format, i.e., P1a, to form the first URL. By accessing the first URL, the corresponding resource data can be obtained. For example, the first resource address format is https: / / P1a / redfish / v1 / Systems. Since this URL requires login authentication, a username and password are needed to obtain the corresponding resource data. Therefore, when accessing it, two additional sub-parameters, P1b and P1c, are also required. For example, when using the curl tool to access it, the format "-u P1b:P1c" can be used with the username and password to access the first URL, such as: curl -u P1b:P1c https: / / P1a / redfish / v1 / Systems. This method is applicable to all situations in the following text that require the corresponding username and password to access the URL, which will not be elaborated on in detail below.

[0026] Furthermore, the electronic device can access the corresponding server through the first URL, thereby obtaining the server's resource data. In this regard, the electronic device can extract the corresponding keyword information from the obtained resource data and use the keyword information as the initial value of the second initial parameter.

[0027] Step S130: Based on the preset second resource address format, first initial parameter and second initial parameter, construct the second URL in a loop and obtain the keyword information in the resource data corresponding to the second URL to update the second initial parameter until the re-obtained keyword information belongs to the target resource path and is recorded in the first temporary file.

[0028] The electronic device can construct a second URL based on a preset second resource address format, the IP address in the first initial parameter, and the second initial parameter to obtain keyword information from the corresponding resource data. For example, if the preset second resource address format is https: / / P1aP2, where P2 is the second initial parameter, a second URL is constructed. Combined with the corresponding account and password, the electronic device can obtain the resource data corresponding to this second URL, and then obtain the keyword information within it, so as to construct a new second URL based on the obtained keyword information.

[0029] Understandably, the electronic device constructs a new second URL to obtain keyword information belonging to the target resource path from the resource data. After the initial acquisition of resource data, the electronic device extracts the corresponding keyword information to update the value of the second initial parameter, i.e., it obtains the latest second initial parameter. However, it's worth noting that after the second acquisition of resource data, the keyword information under the target resource path is obtained, and the electronic device no longer updates the second initial parameter; that is, it does not need to construct a new second URL. Instead, the keyword information belonging to the target resource path is recorded in the first temporary file.

[0030] Step S140: If the first temporary file is not empty, read the keyword information from the first temporary file as the initial value of the third initial parameter, and construct the third URL in sequence according to the preset third resource address format, the first initial parameter and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and record it in the second temporary file.

[0031] If the first temporary file is not empty, its content is read line by line and populated into the third initial parameter. For example, the first line of the first temporary file (containing the recorded keyword information) is used as the initial value of the third initial parameter. Based on the preset third resource address format, the IP address in the first initial parameter, and the third initial parameter, the third URL is constructed sequentially. This third URL is then combined with the corresponding account and password to obtain the keyword information from the resource data corresponding to the third URL, and recorded in the second temporary file. For example, if the preset third resource address format is https: / / P1aP3 and the third initial parameter is P3, the third URL is constructed.

[0032] In some embodiments, if the content of the first temporary file is empty, it indicates that after the electronic device obtains the corresponding resource data according to the second URL, it cannot obtain keyword information from the target resource data. This situation may be due to the server being shut down, the server lacking an RAID card, or other special circumstances preventing the hard drive status from being obtained. Therefore, subsequent steps are not executed. Optionally, in one embodiment, corresponding log information can be recorded in a log file so that maintenance personnel can determine the corresponding server and the server's hard drive status by querying the log file, thereby confirming whether the server is currently shut down or experiencing other abnormalities. Furthermore, after completing the recording in the log file, the electronic device rereads the login information corresponding to the server in the first list file, specifically the login information corresponding to the next server, thus initiating the detection of the hard drive status of the next server. It is conceivable that if the server being detected is the last server recorded in the first list file, the electronic device can end this round of monitoring.

[0033] Step S150: Read keyword information from the second temporary file as the initial value of the fourth initial parameter, and construct the fourth URL in sequence according to the preset fourth resource address format, the first initial parameter and the fourth initial parameter and record it in the second list file.

[0034] In the second temporary file, keyword information is also recorded line by line. The electronic device retrieves content line by line from the second temporary file and populates it into the fourth initial parameter. Based on the preset fourth resource address format, the IP address in the first initial parameter, and the fourth initial parameter, it constructs the fourth URL and records it in the second list file. For example, if the preset fourth resource address format is https: / / P1aP4 and the fourth initial parameter is P4, then the fourth URL is constructed.

[0035] Specifically, based on the keyword information recorded in the second temporary file, the electronic device first obtains the content of the first line as the value of the fourth initial parameter, and then constructs the fourth URL according to the preset fourth resource address format, the IP address in the first initial parameter and the fourth initial parameter and records it in the second list file. It can be understood that the resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status, that is, the fourth URL serves as the URL of the corresponding hard disk to facilitate the determination of the hard disk status.

[0036] Then, the content of the next line in the second temporary file is retrieved as the updated value of the fourth initial parameter. A new fourth URL is constructed again and recorded in the second list file. This process is repeated until the last line of the second temporary file. At this point, all URLs corresponding to all hard drives of the server have been recorded in the second list file.

[0037] It should be noted that in some embodiments, after recording all the fourth URLs corresponding to the hard drive of the same server each time, the device clears the first temporary file and the second temporary file once, so as to record the corresponding keyword information in the subsequent process of searching for the corresponding fourth URL of another server.

[0038] Step S160: With all the fourth URLs corresponding to all servers recorded in the second list file, access the resource data corresponding to each fourth URL one by one to determine the hard disk status of the server based on the target keyword information.

[0039] It can be inferred that after obtaining the fourth URLs corresponding to all hard drives of the same server, the electronic device searches the first list file to determine if there is login information for other servers. If login information for other servers is found, the login information for that other server is read from the first list file, and the previous steps are repeated to collect the fourth URLs corresponding to all hard drives of that other server into the second list file, until the collection of the last server in the first list file is completed. At this point, the fourth URLs corresponding to all hard drives of all servers have been recorded in the second list file.

[0040] In response, the electronic device can combine the account and password of the corresponding server recorded in the first list file to access the fourth URL one by one to obtain the corresponding resource data. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. Based on this target keyword information, the device can determine the hard disk status corresponding to the hard disk of the server.

[0041] Optionally, in one embodiment, the second list file records the information of the fourth URLs corresponding to all hard drives of all servers. For example, if the second list file records the fourth URLs line by line, the electronic device first reads the fourth URL from the first line and combines it with the corresponding account and password from the first list file to access the server. It then extracts target keyword information related to the hard drive status from the obtained resource data and fills it into the fifth initial parameter. The device then determines whether the value of the fifth initial parameter is OK. If OK, it directly reads the URL from the next line of the second list file for access; if not OK, it sends an alarm email to the relevant maintenance personnel and then reads the URL from the next line of the second list file for access. This process is repeated until the last line of the second list file is read, thus completing the detection of the status of all hard drives of all servers. As can be seen from the above solution, the proposed solution can automatically find the URL of each hard drive and obtain the hard drive health status for all servers in the first list file. This only requires maintaining the first list file containing the IP address, account, and password of the servers to be monitored. The solution can then quickly and automatically collect the URLs of all hard drives for all servers in the first list file and record them in the second list file. The hard drive status can then be obtained by accessing the URLs in the second list file one by one. This achieves simple and fast batch monitoring of server hard drive status, effectively saving manpower in operations and maintenance, improving operational efficiency, and ensuring the quality of operations and maintenance.

[0042] It is conceivable that, in addition to being executed periodically as a monitoring task as mentioned above, the server hard drive status monitoring method of this application can also be divided into two monitoring tasks, each executed periodically. Steps S110 to S150, as the first monitoring task, collect the latest URLs of all hard drives on all servers and record them in a second list file. Step S160, as the second monitoring task, checks the health status of each hard drive based on the latest second list file generated by the first monitoring task.

[0043] One advantage of splitting the monitoring into two separate, scheduled tasks is that the execution frequency can be set for each. For example, since the server hard drive URL typically doesn't change frequently, the execution frequency of the first monitoring task can be set relatively low, such as collecting data once a day, thus executing the first monitoring task once a day. Conversely, to detect hard drive failures more promptly, the execution frequency of the second monitoring task can be set relatively high, such as checking the hard drive status hourly, thus executing the second monitoring task hourly. It's conceivable that, since the second monitoring task depends on the second list file generated after the first monitoring task, the two tasks cannot be executed simultaneously; they must be executed at different times, with the first monitoring task executing first and the second monitoring task following.

[0044] Another advantage of splitting the monitoring into two scheduled tasks is that it further improves detection efficiency. This is because it eliminates the need to re-collect the hard drive URL each time; instead, the second monitoring task can directly detect the hard drive's health status, saving time spent collecting the URL and thus increasing efficiency. For example, in production testing, collecting the URL of one hard drive per server takes approximately 0.8 seconds, and checking the health status of one hard drive takes approximately 0.4 seconds, totaling about 1.2 seconds. By saving the time spent collecting the URL, the detection can be completed in approximately 0.4 seconds, representing an efficiency improvement of approximately 66.6% compared to 1.2 seconds.

[0045] Understandably, electronic devices can execute this hard drive health monitoring method as one or two continuously scheduled monitoring tasks to monitor the server's hard drive health status and promptly detect hard drive failures. Specifically, the monitoring task is performed as a scheduled task. After completing the hard drive health check of the last server, the monitoring of all servers (i.e., those recorded in the first list file) is paused, and a scheduled cycle begins. After the scheduled cycle ends, the hard drive health status of each server is re-checked according to the login information recorded in the first list file. Alternatively, the monitoring task can be divided into two timed tasks. The first monitoring task, after completing the collection of the hard drive URLs of the last server, pauses the collection of hard drive URLs of all servers (i.e., the servers recorded in the first list file) and then enters a timed cycle. After the timed cycle ends, the hard drive URLs of each server are collected again according to the login information recorded in the first list file. The second monitoring task, after completing the health status check of the last hard drive, pauses the health status check of all hard drives (i.e., the hard drive URL information recorded in the second list file) and then enters a timed cycle. After the timed cycle ends, the hard drive health status is checked again according to the hard drive URL information recorded in the second list file.

[0046] Therefore, by periodically monitoring hard drive health, electronic devices can regularly check and monitor the server's hard drive status. This allows maintenance personnel to promptly detect hard drive failures, enabling timely replacement of faulty drives, preventing potential problems, and reducing the likelihood of system failures. Furthermore, by performing hard drive status checks at appropriate time intervals, electronic devices can better and more rationally utilize their computing resources, improving system automation, user experience, and overall system performance.

[0047] During the construction of the first URL, a corresponding loop needs to be set up. As the server login information is recorded line by line in the first list file, the number of loop iterations corresponds to the number of lines of server login information recorded in the first list file. In each loop, the login information of one server is read from the first list file to determine the first initial parameter, and the IP address in the first initial parameter is filled in according to the first resource address format to form the first URL. The corresponding resource data is obtained by combining the corresponding account and password, and the quotation marks corresponding to the first keyword are extracted as keyword information.

[0048] In constructing the second URL, the keyword information obtained from accessing the first URL is used as the initial value of the second initial parameter. The IP address and second initial parameter from the first initial parameter are then filled in according to the second resource address format to form the second URL. Combined with the corresponding account and password, the resource data corresponding to the second URL is retrieved, and keyword information is extracted from it. If the keyword information does not belong to the target resource path, it is used as the updated value of the second initial parameter to reconstruct the second URL and retrieve the keyword information again. It can be expected that the process of constructing the second URL requires two loops to obtain the keyword information of the target resource path and record it in the first temporary file.

[0049] During the construction of the third URL, the device needs to set up a corresponding loop. The number of loop iterations corresponds to the number of lines of keyword information recorded in the first temporary file. In each loop, a line is read from the first temporary file as the value of the third initial parameter. The IP address and the third initial parameter are then filled in according to the third resource address format to form the third URL. The corresponding resource data is then obtained by combining the corresponding account and password, and the quoted content corresponding to the first keyword is extracted as keyword information and recorded in the second temporary file. As one can imagine, the corresponding keyword information is also recorded line by line in the second temporary file.

[0050] Furthermore, during the construction of the fourth URL, the device also needs to set up a corresponding loop. The number of loop iterations corresponds to the number of lines in the content recorded in the second temporary file, i.e., the number of lines in the keyword information obtained from the third URL. In each loop iteration, a line is read from the second temporary file as the value of the fourth initial parameter, and the IP address and the fourth initial parameter are filled in according to the fourth resource address format to construct the fourth URL and record it in the second list file.

[0051] After completing the search for the fourth URL corresponding to the hard drives of all servers and recording it in the second list file, the device similarly sets the number of loops according to the number of lines occupied by the content in the second list file. In each loop, it retrieves one line of content (i.e., a fourth URL) from the second list file and combines it with the corresponding account and password from the first list file to access the resource data. This resource data corresponds to the hard drive status of a hard drive on the server; that is, the resource data includes target keyword information for the corresponding hard drive status. The resource data is then parsed to extract the quotation marks corresponding to the second keyword as the target keyword information. Furthermore, the device can determine the corresponding hard drive status by parsing the target keyword. To better illustrate the solution of this application, combined with... Figure 2The following explanation uses the server-side hard disk status monitoring method of this application as an example. The server hard disk status monitoring method of this application is based on Redfish and is a method for batch monitoring of the server's hard disk status. It achieves the purpose of timely detection of faulty hard disks by automatically searching and accessing the server's hard disk resource data in batches and based on the obtained hard disk status.

[0052] The following explanation uses a server as an example. The server includes a first list file, a second list file, a first temporary file, and a second temporary file. The first list file records login information for all servers whose hard drive health needs to be checked. The second list file, the first temporary file, and the second temporary file are initially empty. To facilitate the periodic repetition of the monitoring method proposed in this application, the contents of the second list file need to be cleared before each execution to record the latest hard drive URLs in the second list file.

[0053] Specifically, the login information for each server in the first list file includes three fields: the server's out-of-band management port IP address, username, and password, separated by commas. The login information for each server is written on a single line in the first list file, such as: 10.16.1.1, user01, pass1234 10.16.1.2, user02, pass5678 ... Step S210: According to the set first loop, read the login information in the first list file to determine the first initial parameters.

[0054] The first loop is set up to continuously read login information from different servers in the first list file. After the first loop begins, the server selects a line of login information from the first list file, such as the first line of login information. Each loop reads one line to begin checking the hard drive status of the server corresponding to that line of login information. After determining the login information, the corresponding first initial parameters are filled in. The first initial parameters include three sub-parameters, which are then represented as P1a, P1b, and P1c respectively. In this case, P1a = 10.16.100.1, P1b = user01, and P1c = pass1234.

[0055] Step S211: Construct a first URL based on the first resource address format and the first initial parameter, and use the keyword information in the obtained resource data as the initial value of the second initial parameter.

[0056] A first URL is constructed based on a preset first resource address format and the IP address in the first initial parameters mentioned above, thereby accessing the server's resource data. For example, the preset first resource address format is https: / / P1a / redfish / v1 / Systems, thus obtaining the first URL (i.e., https: / / 10.16.1.1 / redfish / v1 / Systems).

[0057] Based on this, combining the corresponding account and password, i.e., combining the two sub-parameters P1b and P1c, the first URL is accessed to obtain the keyword information in the corresponding resource data. For example, when using the curl tool to access this first URL, the format "-u P1b:P1c" can be used to include the account and password, such as: curl -u user01:pass1234 https: / / 10.16.1.1 / redfish / v1 / Systems. From the returned JSON format resource data, the content of the Members data block is extracted. For example, in this embodiment, the content format of the Members data block is as follows: "Members":[{"@odata.id":" / redfish / v1 / Systems / 1 / "}] Then, extract the quotation marks corresponding to the first keyword as keyword information, where the first keyword is "odata.id" and the quotation marks correspond to the system resource path. Then, use the quotation marks as keyword information as the value of the second initial parameter. The second initial parameter is represented by P2, that is, in this embodiment, the second initial parameter P2 = / redfish / v1 / Systems / 1 / .

[0058] Step S212: Construct a second URL based on the second resource address format, the first initial parameter, and the second initial parameter, obtain the corresponding keyword information, update the second initial parameter, and reconstruct the second URL.

[0059] The server constructs a second URL based on a preset second resource address format, the IP address in the first initial parameter, and the second initial parameter. For example, the preset second resource address format is https: / / P1aP2, thus constructing the second URL (i.e., https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / ). Further, combining the corresponding username and password, i.e., combining the two sub-parameters P1b and P1c, the server accesses the second URL to obtain keyword information from the corresponding resource data. For example, when using the curl tool to access the second URL, the format "-u P1b:P1c" can be used to include the username and password, such as: curl -uuser01:pass1234 https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / . From the returned JSON-formatted resource data, the content of the Storage data block is extracted. For example, in this embodiment, the content format of the Storage data block is as follows: "Storage":[{"@odata.id":" / redfish / v1 / Systems / 1 / Storage"}] The quoted content corresponding to the first keyword is then extracted as keyword information, where the first keyword is "odata.id" and the quoted content corresponds to the storage resource path. The quoted content is then used as keyword information to update the value of the second initial parameter. In this embodiment, the second initial parameter P2 is now / redfish / v1 / Systems / 1 / Storage, and a new second URL (https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage) is then reconstructed.

[0060] Step S213: Access the updated second URL and record the keyword information corresponding to the obtained resource data line by line into the first temporary file.

[0061] Access the new second URL to retrieve keyword information from the corresponding resource data. For example, use the curl tool to access the updated second URL, using the format "-u P1b:P1c" to include the username and password, such as: curl -u user01:pass1234 https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage. Extract the content of the Members data block from the returned JSON-formatted resource data. For example, in this embodiment, the content format of the Members data block is as follows: "Members":[{"@odata.id":" / redfish / v1 / Systems / 1 / Storage / DE00B000"}] Next, the quoted content corresponding to the first keyword is extracted as keyword information, where the first keyword is "odata.id", and the quoted content corresponds to the StorageMembers resource path. This quoted content is then used as keyword information. This keyword information is recorded in the first temporary file, i.e., the content of the first temporary file in this embodiment is: / redfish / v1 / Systems / 1 / Storage / DE00B000 It is understandable that the StorageMembers resource path in the Members data block is the target resource path. In this embodiment, constructing the second URL twice can obtain the keyword information of the target resource path.

[0062] Step S214: Determine whether the first temporary file is empty.

[0063] If the first temporary file is empty, this may be due to the server being shut down or other situations that are beyond the expectations of this method. Therefore, subsequent steps do not need to be executed. In this case, logs can be recorded, and then the process can be directly returned to step S210 to execute the monitoring steps for the next server. If the first temporary file is not empty, then the next step (i.e., step S215) is executed.

[0064] Step S215: Based on the set second loop, read the contents of the first temporary file to determine the third initial parameters.

[0065] Since the content of the first temporary file in this embodiment is not empty, its content is read as the value of the third initial parameter. The third initial parameter can be represented by P3. It is conceivable that since the content of the first temporary file may contain multiple lines, a second loop is set up to read the content line by line and use it as the value of the third initial parameter, such as reading one line at a time until the last line. It should be noted that the second loop is a sub-loop of the first loop.

[0066] Since the first temporary file in the example above contains only one line, the second loop only needs to be read once to end. In this embodiment, the third initial parameter P3 = / redfish / v1 / Systems / 1 / Storage / DE00B000.

[0067] Step S216: Construct a third URL based on the third resource address format, the first initial parameter, and the third initial parameter, and record the keyword information in the resource data corresponding to the third URL through a second temporary file.

[0068] A third URL is constructed based on a preset third resource address format, the IP address in the first initial parameter, and the third initial parameter. For example, the third resource address format is: https: / / P1aP3. In this embodiment, after substituting the parameter values, the third URL becomes: https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000. The electronic device uses the curl tool in combination with the format "-u P1b:P1c" to access this URL with the username and password, such as: curl -uuser01:pass1234 https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000. From the returned JSON format resource data, the content of the "Drives" data block is extracted. For example, in this embodiment, the content format of the "Drives" data block is as follows: "Drives":[{"@odata.id":" / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0"}, {"@odata.id":" / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1"}] Next, extract the quoted content corresponding to the first keyword as keyword information. The first keyword is "odata.id", and the corresponding quoted content consists of two lines and corresponds to the drive's resource path. This content is then added to the second temporary file. The content of the second temporary file includes: / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1 Step S217: After the second loop ends, read the contents of the second temporary file according to the set third loop to determine the fourth initial parameter.

[0069] Since the second temporary file contains multiple lines of parameter information, a third loop is needed to retrieve its content line by line, reading one line at a time until the last line. It should be noted that the third loop is another sub-loop of the first loop. Specifically, in the first iteration of the loop, the first line of parameter information recorded in the second temporary file is used as the value of the fourth initial parameter. This fourth initial parameter is denoted by P4. For example, in this embodiment, the fourth initial parameter is specifically: P4= / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0.

[0070] Step S218: Construct the fourth URL and record it in the second list file according to the fourth resource address format, the first initial parameter and the fourth initial parameter.

[0071] The fourth URL is constructed based on the preset fourth resource address format, the IP address in the first initial parameter, and the fourth initial parameter. For example, the fourth resource address format is: https: / / P1aP4. After substituting the corresponding parameter values, the fourth URL becomes: https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0 This is recorded in the second list file. It's conceivable that in the third loop, if the second temporary file contains multiple lines of data, multiple fourth URLs can be constructed. Therefore, in the execution of the third loop, after each construction of the fourth URL, it's necessary to return to step S217 to read the next line of the second temporary file and use it as the value of the fourth initial parameter. In this embodiment, in the second loop, the fourth initial parameter P4 = / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1, thus obtaining the new fourth URL: https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1 Record this information in the second temporary file. Since the second temporary file only has two lines in this embodiment, the loop ends after the second iteration.

[0072] In this embodiment, after obtaining the second list file containing all the hard drive URLs of the first server, for example, the content of the current second list file includes: https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0 https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1 Step S219: After the third loop ends, clear the first temporary file and the second temporary file.

[0073] It is conceivable that after recording the fourth URL corresponding to all hard drives of the server (i.e., exiting the third loop), the first and second temporary files need to be cleared to facilitate recording the temporary information of the next server (such as the keyword information mentioned above). Return to step S210 to continue executing the first loop, read the login information of the next server in the first list file, and repeat the above steps until the last server is reached, at which point the first loop ends.

[0074] Step S220: After the first loop ends, according to the set fourth loop, read the contents of the second list file to determine the corresponding hard disk status and the fifth initial parameters.

[0075] In this embodiment, after the first loop is completed, a second list file containing all hard drive URLs of all servers is obtained. For example, the content of the second list file is as follows: https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 0 https: / / 10.16.1.1 / redfish / v1 / Systems / 1 / Storage / DE00B000 / Drives / 1 https: / / 10.16.1.2 / redfish / v1 / Systems / 1 / Storage / DE00C000 / Drives / 0 https: / / 10.16.1.2 / redfish / v1 / Systems / 1 / Storage / DE00C000 / Drives / 1 ...... In the fourth loop, the URL in the first line of the second list file is read first. Based on the IP address in the URL, the system searches the first list file for the corresponding username and password and accesses the resource data to obtain the target keyword information related to the hard drive health status. This information is then used as the value of the fifth initial parameter. For example, if the URL is accessed using the curl tool, the content of the "Status" data block is extracted from the returned JSON format resource data. For instance, in this embodiment, the content format of the "Status" data block is as follows: "Status":{"State":"Enabled","Health":"OK"} Next, the content containing the quotation marks corresponding to the second keyword is extracted from the "Status" data block as the target keyword information, and this is used as the value of the fifth initial parameter, which is represented by P5. Here, the second keyword is "Health," and the quotation marks corresponding to this keyword represent the hard drive's health status. In the above example, "OK" indicates that the hard drive is in a healthy state; therefore, in this embodiment, the fifth initial parameter P5 = OK.

[0076] Step S221: Determine whether the value of the fifth initial parameter is "OK".

[0077] If the value of the fifth initial parameter is OK, then return to step S220 to continue executing the fourth loop and read the next line. Since P5=OK at this time in this embodiment, the judgment result is yes. Therefore, return to step S220 to continue executing the fourth loop, read the next line URL of the second list file to access and obtain the resource data of the next hard disk.

[0078] If the content format of the "Status" data block obtained from the returned JSON format resource data is as follows: "Status":{"State": "Enabled", "Health": "Critical"} Then, extract the content containing the quotation marks corresponding to the second keyword "Health" from the content of the "Status" data block as the target keyword information to obtain the health status of the hard drive, and use it as the value of the fifth initial parameter. At this time, the fifth initial parameter P5 = Critical ≠ OK. The judgment result is no, indicating that the hard drive is faulty, and then step S222 is executed.

[0079] Step S222: Call the email sending interface to send a hard drive failure alarm email to the designated maintenance personnel's email address.

[0080] By sending a corresponding alarm email, the server's hard drive is notified of a failure. Then, the process returns to step S220 and continues the fourth loop, reading the next line of the second list file until the last line, to obtain the hard drive status and alarm judgment for all hard drives on all servers. It's conceivable that after detecting a hard drive failure and sending an alarm email, the relevant failure information can also be recorded in a log file for future reference.

[0081] Figure 3This is a schematic diagram of a server hard disk status monitoring device provided in an embodiment of this application. The device is used to execute the server hard disk status monitoring method provided in the above embodiment and has the corresponding functional modules and beneficial effects. The server hard disk status monitoring device is applied to an electronic device, which includes a first list file, a second list file, a first temporary file, and a second temporary file. The first list file includes login information corresponding to several servers. The device includes: a first parameter acquisition module 301, a second parameter acquisition module 302, a third parameter acquisition module 303, a fourth parameter acquisition module 304, an information acquisition module 305, and a status detection module 306.

[0082] The first parameter acquisition module 301 is configured to read the login information corresponding to one of the servers from the first list file, so as to determine the first initial parameter based on the login information; The second parameter acquisition module 302 is configured to construct a first URL based on a preset first resource address format and a first initial parameter, and use the keyword information in the resource data corresponding to the acquired first URL as the initial value of the second initial parameter. The third parameter acquisition module 303 is configured to construct a second URL and acquire keyword information from the resource data corresponding to the second URL in a loop according to the preset second resource address format, the first initial parameter and the second initial parameter, so as to update the second initial parameter until the reacquired keyword information belongs to the target resource path and is recorded in the first temporary file; The fourth parameter acquisition module 304 is configured to read keyword information from the first temporary file as the initial value of the third initial parameter when the first temporary file is not empty, and construct the third URL in sequence according to the preset third resource address format, the first initial parameter and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and record it in the second temporary file. The information acquisition module 305 is configured to read keyword information from the second temporary file as the initial value of the fourth initial parameter, and construct the fourth URL in sequence according to the preset fourth resource address format, the first initial parameter and the fourth initial parameter and record it in the second list file. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. The status detection module 306 is configured to access the resource data corresponding to each of the fourth URLs one by one, in order to determine the hard disk status of the server based on the target keyword information, provided that all the fourth URLs corresponding to all servers are recorded in the second list file.

[0083] Based on the above embodiments, the first initial parameters include the IP address, username, and password corresponding to the server hardware management network port, and the second parameter acquisition module 302 is specifically configured as follows: The number of loops is determined by the number of lines occupied by the contents of the first list file, and the login information corresponding to each server is read line by line in the first list file as the value of the first initial parameter in each loop. In each loop, the IP address in the first initial parameter is filled in according to the first resource address format to form the first URL, and the account and password in the first initial parameter are used to access the first URL to obtain the corresponding resource data; Based on the resource data obtained corresponding to the first URL, the quoted content corresponding to the first keyword is extracted as keyword information, and the keyword information is used as the initial value of the second initial parameter.

[0084] Based on the above embodiments, the third parameter acquisition module 303 is specifically configured as follows: According to the second resource address format, fill in the IP address and the second initial parameter in the first initial parameter to form the second URL, and combine the account and password in the first initial parameter to access the second URL to obtain the corresponding resource data; Based on the obtained resource data corresponding to the second URL, the quotation marks corresponding to the first keyword are extracted as keyword information; If the obtained keyword information belongs to the target resource path, record the keyword information line by line in the first temporary file; If the obtained keyword information does not belong to the target resource path, update the value of the second initial parameter with the keyword information to reconstruct the second URL and obtain the keyword information again.

[0085] Based on the above embodiments, the first initial parameters include IP address, username, and password. The fourth parameter acquisition module 304 is specifically configured as follows: The number of loop iterations is determined by the number of lines occupied by the contents of the first temporary file, and the contents of the first temporary file are read line by line to serve as the value of the third initial parameter in each loop iteration; In each loop, the IP address and the third initial parameter in the first initial parameter are filled in according to the third resource address format to form the third URL and obtain the resource data corresponding to the third URL by combining the account and password in the first initial parameter; Based on the resource data obtained from the corresponding third URL, the quoted content corresponding to the first keyword is extracted as keyword information and recorded line by line in the second temporary file.

[0086] Based on the above embodiments, the information acquisition module 305 is specifically configured as follows: The number of loop iterations is determined by the number of lines occupied by the content of the second temporary file, and the content of the second temporary file is read line by line to serve as the value of the fourth initial parameter in each loop. In each loop, the IP address and the fourth initial parameter in the first initial parameter are filled in according to the fourth resource address format to form the fourth URL.

[0087] Based on the above embodiments, the information acquisition module 305 is also configured with: After recording all the fourth URLs corresponding to the same server each time, the first and second temporary files are cleared to make room for recording the corresponding keyword information.

[0088] Based on the above embodiments, the state detection module 306 is specifically configured as follows: The number of loop iterations is determined by the number of lines occupied by the contents of the second list file; In each loop, the fourth URL is read line by line from the second list file and combined with the corresponding account and password from the first list file to access the resource data of the fourth URL corresponding to the hard drive of each server. Based on the resource data of the corresponding hard drive URL, the quotation marks corresponding to the second keyword are extracted and used as the target keyword information; the target keyword is parsed to determine the corresponding hard drive status.

[0089] It is worth noting that in the embodiments of the above-mentioned device, the modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each module are only for easy differentiation and are not used to limit the protection scope of the embodiments of this application.

[0090] Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. The device is used to execute the server hard drive status monitoring method provided in the above embodiment and has corresponding functional modules and beneficial effects for executing the method. As shown in the figure, the electronic device includes a processor 401, a memory 402, an input device 403, and an output device 404. The number of processors 401 can be one or more; one processor 401 is shown as an example in the figure. The processor 401, memory 402, input device 403, and output device 404 can be connected via a bus or other means; a bus connection is shown as an example in the figure. The memory 402, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the server hard drive status monitoring method in this embodiment. The processor 401 executes various corresponding functional applications and data processing by running the software programs, instructions, and modules stored in the memory 402, thereby realizing the above-mentioned server hard drive status monitoring method.

[0091] The memory 402 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data recorded or created during use. Furthermore, the memory 402 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 402 may further include memory remotely located relative to the processor 401, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0092] The input device 403 can be used to input corresponding digital or character information to the processor 401, and to generate key signal inputs related to the user settings and function control of the device; the output device 404 can be used to send or display key signal outputs related to the user settings and function control of the device, such as sending an alarm email to the user when the hard drive fails.

[0093] This application also provides a storage medium storing computer-executable instructions, which, when executed by a processor, are used to perform related operations in the server hard disk status monitoring method provided in any embodiment of this application.

[0094] Computer-readable storage media include both permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

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

[0096] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for monitoring the status of a server hard drive, characterized in that, Applied to electronic devices, the electronic devices include a first list file, a second list file, a first temporary file, and a second temporary file. The first list file includes login information corresponding to several servers. The server hard disk status monitoring method includes: Read the login information corresponding to one of the servers from the first list file, and determine the first initial parameter based on the login information; Based on the preset first resource address format and the first initial parameter, a first URL is constructed, and the keyword information in the resource data corresponding to the first URL is used as the initial value of the second initial parameter. The keyword information in the resource data corresponding to the first URL is the information of the system resource path in the resource data corresponding to the first URL. According to the preset second resource address format, the first initial parameter and the second initial parameter, the second URL is constructed in a loop and the keyword information in the resource data corresponding to the second URL is obtained to update the second initial parameter until the keyword information obtained again belongs to the target resource path and is recorded in the first temporary file. The keyword information in the resource data corresponding to the second URL is the information of the corresponding storage resource path in the resource data corresponding to the second URL. If the first temporary file is not empty, keyword information is read from the first temporary file as the initial value of the third initial parameter, and according to the preset third resource address format, the first initial parameter and the third initial parameter, the third URL is constructed in sequence to obtain the keyword information in the resource data corresponding to the third URL, and recorded in the second temporary file; Keyword information is read from the second temporary file as the initial value of the fourth initial parameter, and the fourth URL is constructed and recorded in the second list file according to the preset fourth resource address format, the first initial parameter and the fourth initial parameter. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. With all fourth URLs corresponding to all servers recorded in the second list file, the resource data corresponding to each fourth URL is accessed one by one to determine the hard disk status of the server based on the target keyword information.

2. The server hard disk status monitoring method according to claim 1, characterized in that, The first initial parameters include the IP address, username, and password corresponding to the server hardware management network port. The step of constructing a first URL based on a preset first resource address format and the first initial parameters, and using keyword information from the resource data corresponding to the obtained first URL as the initial value of the second initial parameters, includes: The number of iterations is determined by the number of lines occupied by the contents of the first list file, and the contents of the first list file are read line by line to serve as the value of the first initial parameter in each iteration. In each loop, the IP address in the first initial parameter is filled in according to the first resource address format to form the first URL, and the account and password in the first initial parameter are used to access the first URL to obtain the corresponding resource data; Based on the obtained resource data corresponding to the first URL, the quotation marks corresponding to the first keyword are extracted as keyword information, and the keyword information is used as the initial value of the second initial parameter.

3. The server hard disk status monitoring method according to claim 1 or 2, characterized in that, The step of cyclically constructing a second URL and obtaining keyword information from the resource data corresponding to the second URL based on a preset second resource address format, the first initial parameter, and the second initial parameter, to update the second initial parameter, until the re-obtained keyword information belongs to the target resource path and is recorded in the first temporary file, includes: According to the second resource address format, fill in the IP address in the first initial parameter and the second initial parameter to form the second URL, and combine the account and password in the first initial parameter to access the second URL to obtain the corresponding resource data; Based on the obtained resource data corresponding to the second URL, the quotation mark content corresponding to the first keyword is extracted as keyword information; If the obtained keyword information belongs to the target resource path, the keyword information is recorded line by line in the first temporary file; If the obtained keyword information does not belong to the target resource path, update the value of the second initial parameter with the keyword information to reconstruct the second URL and obtain the keyword information again.

4. The server hard disk status monitoring method according to claim 1, characterized in that, The first set of initial parameters includes the IP address, username, and password; When the first temporary file is not empty, keyword information is read from the first temporary file as the initial value of the third initial parameter, and a third URL is constructed sequentially according to the preset third resource address format, the first initial parameter, and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and recorded in the second temporary file, including: The number of loops is determined according to the number of lines occupied by the content of the first temporary file, and the content of the first temporary file is read line by line to be used as the value of the third initial parameter in each loop; In each loop, the IP address in the first initial parameter and the third initial parameter are filled in according to the third resource address format to form the third URL and the resource data corresponding to the third URL are obtained by combining the account and password in the first initial parameter; Based on the obtained resource data corresponding to the third URL, the quotation marks corresponding to the first keyword are extracted as keyword information and recorded line by line in the second temporary file.

5. The server hard disk status monitoring method according to claim 1 or 4, characterized in that, The step of reading keyword information from the second temporary file as the initial value of the fourth initial parameter, and constructing the fourth URL and recording it in the second list file according to the preset fourth resource address format, the first initial parameter, and the fourth initial parameter, includes: The number of loops is determined according to the number of lines occupied by the content of the second temporary file, and the content of the second temporary file is read line by line to be used as the value of the fourth initial parameter in each loop; In each loop, the IP address in the first initial parameter and the fourth initial parameter are filled in according to the fourth resource address format to form the fourth URL.

6. The server hard disk status monitoring method according to claim 5, characterized in that, After reading keyword information from the second temporary file as the initial value of the fourth initial parameter, and constructing the fourth URL and recording it in the second list file according to the preset fourth resource address format, the first initial parameter, and the fourth initial parameter, the method further includes: After recording all the fourth URLs corresponding to the same server each time, the first temporary file and the second temporary file are cleared to allow for the recording of the corresponding keyword information.

7. The server hard disk status monitoring method according to claim 1, characterized in that, In the case that all fourth URLs corresponding to all servers are recorded in the second list file, the resource data corresponding to each fourth URL is accessed one by one to determine the hard disk status of the server based on the target keyword information, including: The number of loop iterations is determined by the number of lines occupied by the contents of the second list file; In each loop, a line of the fourth URL is read from the second list file and combined with the corresponding account and password in the first list file to access the resource data of the fourth URL corresponding to the hard drive of each server. Based on the resource data of the corresponding hard disk URL obtained, the quotation mark content corresponding to the second keyword is extracted and used as the target keyword information; The target keyword is parsed to determine the corresponding hard drive status.

8. A server hard drive status monitoring device, characterized in that, Applied to electronic devices, the electronic devices include a first list file, a second list file, a first temporary file, and a second temporary file. The first list file includes login information corresponding to several servers. The server hard disk status monitoring device includes: The first parameter acquisition module is configured to read login information corresponding to one of the servers from the first list file, so as to determine the first initial parameter based on the login information; The second parameter acquisition module is configured to construct a first URL based on a preset first resource address format and the first initial parameter, and use the keyword information in the resource data corresponding to the first URL as the initial value of the second initial parameter. The keyword information in the resource data corresponding to the first URL is the information of the system resource path in the resource data corresponding to the first URL. The third parameter acquisition module is configured to construct a second URL in a loop according to the preset second resource address format, the first initial parameter and the second initial parameter, and obtain the keyword information in the resource data corresponding to the second URL to update the second initial parameter, until the re-obtained keyword information belongs to the target resource path and is recorded in the first temporary file. The keyword information in the resource data corresponding to the second URL is the information of the corresponding storage resource path in the resource data corresponding to the second URL. The fourth parameter acquisition module is configured to read keyword information from the first temporary file as the initial value of the third initial parameter when the first temporary file is not empty, and to construct the third URL in sequence according to the preset third resource address format, the first initial parameter and the third initial parameter to obtain the keyword information in the resource data corresponding to the third URL, and record it in the second temporary file. The information acquisition module is configured to read keyword information from the second temporary file as the initial value of the fourth initial parameter, and construct the fourth URL in sequence according to the preset fourth resource address format, the first initial parameter and the fourth initial parameter and record it in the second list file. The resource data corresponding to the fourth URL includes target keyword information associated with the hard disk status. The status detection module is configured to access the resource data corresponding to each of the fourth URLs in turn, in order to determine the hard disk status of the server based on the target keyword information, provided that all the fourth URLs corresponding to all servers are recorded in the second list file.

9. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the server hard disk status monitoring method as described in any one of claims 1-7.

10. A storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a processor, are used to perform the server hard disk status monitoring method as described in any one of claims 1-7.

Images