A monitoring method and system based on a Redfish protocol, an electronic device, and a storage medium

Abstract

The present disclosure provides a Redfish protocol-based monitoring method and system, electronic equipment and storage medium, relating to the technical field of computer. The method comprises the following steps: obtaining an internet protocol (IP) address and authentication information of a baseboard management controller (BMC) of a server; establishing a communication connection with the BMC through an HTTPS protocol based on the IP address of the BMC, and completing Redfish login authentication with the BMC based on the authentication information and obtaining a session token; determining a Redfish URI path and a field position corresponding to a hardware resource of the BMC; splitting a hardware data collection task of the server into a sensor data collection task and a fan data collection task, and performing the sensor data collection task and the fan data collection task in parallel through a thread pool based on the session token, the Redfish URI path and the field position; and synchronously obtaining collection results obtained by the sensor data collection task and the fan data collection task based on a Future object. Thus, the monitoring efficiency and versatility are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a monitoring method, system, electronic device, and storage medium based on the Redfish protocol. Background Technology

[0002] In the field of server cooling, real-time monitoring of hardware status data (such as temperature, voltage, power, fan speed, etc.) is a core means of preventing hardware failures, ensuring system reliability, optimizing system performance, and taking appropriate measures based on power consumption curves. With the surge in the number of data center servers and the diversification of server models, the demand for hardware status monitoring is increasing daily.

[0003] Existing hardware status monitoring solutions for servers suffer from several significant problems when dealing with the large number and diversity of servers. First, they lack compatibility and universality. The lack of a unified standard for hardware monitoring interfaces (such as IPMI) across different brands and models of servers means that existing scripts often only adapt to specific models, requiring the development of dedicated tools for each server or frequent field modifications. Furthermore, the lack of flexible command-line parameter configuration makes it difficult to support future functional expansion. Second, they suffer from low data collection efficiency and real-time performance. Traditional solutions often employ a single-threaded serial polling mechanism with polling intervals typically lasting 5-10 seconds or even longer. This fails to capture sudden hardware status changes (such as sudden temperature increases or fan failures) during processor load testing, easily missing fault warning opportunities and failing to accurately monitor temperature overshoots. In addition, existing technologies have significant shortcomings in supporting special scenarios. They cannot monitor fan curves when the server S5 is powered off (usually requiring additional hardware assistance, which is costly), and they do not support out-of-band script data recording, making monitoring impossible on servers without specific tools installed or in intranet environments. Finally, the data integration capability is weak, multi-dimensional data is scattered and lacks correlation analysis, some tools are complex and have poor adaptability to cross-environment deployment, and there is a lack of logging function, which makes it difficult to locate problems and makes it difficult to meet the needs of modern data centers for comprehensive, real-time and efficient monitoring of hardware status. Summary of the Invention

[0004] This disclosure provides a monitoring method, system, electronic device, and storage medium based on the Redfish protocol to at least solve the above-mentioned technical problems existing in the prior art.

[0005] According to a first aspect of this disclosure, a monitoring method based on the Redfish protocol is provided, comprising: Obtain the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server; Based on the IP address of the BMC, a communication connection is established with the BMC via the HTTPS protocol, and Redfish login authentication with the BMC is completed and a session token is obtained based on the authentication information; Determine the Redfish URI path and field location corresponding to the hardware resources of the BMC; The hardware data acquisition task of the server is split into sensor data acquisition task and fan data acquisition task, and the sensor data acquisition task and fan data acquisition task are executed in parallel through a thread pool based on the session token, Redfish URI path and field position. The acquisition results obtained from the sensor data acquisition task and the fan data acquisition task are obtained synchronously based on the Future object; The collected results are standardized to obtain the hardware status information of the server.

[0006] According to a second aspect of this disclosure, a monitoring system based on the Redfish protocol is provided, comprising: The acquisition module is used to acquire the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server; The communication module is used to establish a communication connection with the BMC via the HTTPS protocol based on the BMC's IP address, and to complete Redfish login authentication with the BMC and obtain a session token based on the authentication information. The determination module is used to determine the Redfish URI path and field location corresponding to the hardware resources of the BMC; The concurrency module is used to split the server's hardware data acquisition task into sensor data acquisition task and fan data acquisition task, and to execute the sensor data acquisition task and fan data acquisition task in parallel through a thread pool based on the session token, Redfish URI path and field position. The acquisition module synchronously acquires the acquisition results obtained from the sensor data acquisition task and the fan data acquisition task based on the Future object; The processing module performs standardized processing on the collected results to obtain the hardware status information of the server.

[0007] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described in this disclosure.

[0008] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in this disclosure.

[0009] This disclosure discloses a monitoring method, system, electronic device, and storage medium based on the Redfish protocol. By employing the Redfish protocol and HTTPS encrypted communication, this application solves the problems of poor compatibility and insufficient communication security of traditional server monitoring interfaces. By automatically determining the Redfish URI path and field positions, it resolves the cumbersome adaptation and low universality issues caused by manual configuration of interface paths and data fields for different manufacturers and versions of BMC. By splitting the collection tasks and using a thread pool for parallel execution, it solves the problems of long time consumption and low monitoring efficiency in traditional single-threaded sequential hardware data collection. By synchronously blocking the acquisition of collection results using Future objects, it ensures the integrity and temporal consistency of multi-threaded collection results, solving the problems of data loss and unusable results that easily occur in asynchronous collection. By standardizing the collected data, it solves the problems of messy original hardware data formats, inconsistent types, and disordered sorting, which make it difficult to display intuitively and for subsequent analysis and utilization.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0012] Figure 1 A flowchart illustrating a monitoring method based on the Redfish protocol according to an embodiment of this disclosure is shown. Figure 2 A schematic diagram of the structure of a monitoring system based on the Redfish protocol according to an embodiment of this disclosure is shown; Figure 3 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0013] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0014] Figure 1 A flowchart illustrating a monitoring method based on the Redfish protocol according to an embodiment of this disclosure is shown, as follows: Figure 1 As shown, a monitoring method based on the Redfish protocol includes: Step S101: Obtain the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server.

[0015] In this embodiment, the management node of the server to be monitored is first located, and the information required for identity verification is obtained. The Baseboard Management Controller (BMC) is an embedded management module on the server that runs independently of the main central processing unit (CPU) and operating system. Its Internet Protocol (IP) address is the network address used by the BMC to provide out-of-band management services and establish network communication links. The authentication information is the identity verification data necessary to access the BMC, used to pass the BMC's security verification and obtain hardware data acquisition permissions. In actual execution, the BMC's IP address and authentication information can be obtained through external input, local reading, etc., to ensure that subsequent access can accurately point to the target server's BMC and complete legitimate access. For example, for a rack-mounted server, its BMC's IP address can be set to 192.168.100.100, and the authentication information is the legitimate identity credential for accessing the BMC's management interface, used for subsequent login verification.

[0016] Step S102: Based on the BMC's IP address, establish a communication connection with the BMC via the HTTPS protocol, and complete Redfish login authentication with the BMC and obtain a session token based on the authentication information.

[0017] In this embodiment, the BMC's IP address is used as the communication target, and a connection request is initiated using Hypertext Transfer Protocol Secure (HTTPS). HTTPS ensures the security of communication data through encrypted transmission, preventing authentication information and hardware data from being stolen or tampered with during transmission, thus complying with the secure communication requirements of the Redfish protocol. After the connection is established, the authentication information obtained in the previous step is encapsulated according to the format specified by the Redfish protocol and sent to the BMC's login interface. The BMC verifies the authentication information, and upon successful verification, generates and returns a session token. This session token serves as temporary identity credentials for this legitimate session, and all subsequent hardware data acquisition requests must carry this token for authentication. Redfish is an open standard protocol based on the Representational State Transfer Application Programming Interface (RESTful API), designed to provide modern intelligent management for data center hardware (such as servers, storage, and network devices). It utilizes HTTPS transmission and JSON data format to replace the traditional Intelligent Platform Management Interface (IPMI) protocol, thereby achieving more secure, efficient, and easily integrated hardware monitoring and remote control.

[0018] Step S103: Determine the Redfish URI path and field location corresponding to the hardware resources of the BMC.

[0019] In this embodiment, different versions of the BMC may correspond to different Redfish URI paths and field locations for hardware resources. Different hardware resources (temperature, fan, power, etc.) correspond to exclusive Redfish URI paths, and the hardware status data is carried in JSON format, with different monitoring indicators corresponding to specific field locations in the JSON data. By accessing the Redfish service interface of the BMC, the URI paths corresponding to the hardware resources such as temperature sensors, fans, and power modules on the server can be traversed and matched. Simultaneously, the returned JSON data structure can be parsed to determine the field locations of each hardware status parameter, providing accurate access addresses and extraction locations for subsequent data collection. The Uniform Resource Identifier (URI) is a unique string used to identify resources (such as web pages, files, or service interfaces) on the Internet. In the Redfish protocol, the URI serves as a path address, used to accurately locate and access specific hardware resources in the BMC. Step S104: The server's hardware data acquisition task is split into sensor data acquisition task and fan data acquisition task.

[0020] In this embodiment, the overall hardware data acquisition work needs to be broken down into two independent tasks according to data type. The sensor data acquisition task is responsible for acquiring sensor data such as temperature, voltage, and power, while the fan data acquisition task is responsible for acquiring fan-related data such as fan speed and pulse width modulation (PWM) duty cycle. The two tasks are independent of each other and have no execution dependency.

[0021] Step S105: Based on the session token, Redfish URI path, and field location, the sensor data acquisition task and the fan data acquisition task are executed in parallel using a thread pool.

[0022] In this embodiment, the session token is used as an identity credential, the Redfish URI path as the data access address, and the field location as the data extraction basis, all bound to the corresponding data acquisition task. Both types of tasks are submitted to a thread pool for parallel processing. The thread pool simultaneously schedules multiple threads to execute the two types of tasks, avoiding the latency issues of single-threaded serial execution. For example, the thread pool can simultaneously run two threads: one thread performs data acquisition from sensors such as temperature and voltage, and the other thread performs data acquisition from fans such as fan speed and status; the two types of acquisition operations are performed synchronously.

[0023] Step S106: Synchronously acquire the acquisition results obtained from the sensor data acquisition task and the fan data acquisition task based on the Future object.

[0024] In this embodiment, it is also necessary to uniformly obtain the execution results of parallel tasks to ensure data integrity. The Future object serves as a carrier for encapsulating the execution results of asynchronous tasks. Each parallel acquisition task corresponds to a Future object, used to store the acquired data and execution status of that task. By calling the result retrieval interface of the Future object, the system waits in a blocking manner until both the sensor data acquisition task and the fan data acquisition task have completed execution before uniformly extracting the acquisition results of the two tasks. This ensures that complete and uninterrupted hardware data is obtained, avoiding data incompleteness issues caused by differences in task execution speeds. For example, after both the sensor data acquisition task and the fan data acquisition task have completed execution, the temperature, voltage, and fan speed data are obtained through the corresponding Future objects, completing result synchronization. Here, the Future object represents the result of asynchronous computation, acting as a placeholder for unfinished tasks. It allows the program to return immediately after submitting a time-consuming task, and later query the status, wait, and obtain the results through this object, thereby achieving non-blocking asynchronous programming.

[0025] Step S107: Standardize the collected results to obtain the server's hardware status information.

[0026] In this embodiment, the standardization process includes data filtering, sorting, and format unification. First, data is filtered by data type, categorized as temperature, power, voltage, and fan speed. Then, each category of data is sorted according to preset rules. Finally, the data format is unified, such as retaining a fixed number of decimal places for numerical values ​​and marking missing data items with a uniform identifier. This ultimately generates standardized, easy-to-view, and easily analyzable server hardware status information. For example, the collected scattered temperature and fan data are sorted by air inlet, CPU, and memory; temperature data is sorted by fan number; and fan data is uniformly retained to two decimal places, forming complete hardware status information.

[0027] In this embodiment, by employing the Redfish protocol and HTTPS encrypted communication, the problems of poor compatibility and insufficient communication security of traditional server monitoring interfaces are solved. By automatically determining the Redfish URI path and field position, the problem of cumbersome adaptation and low universality caused by manual configuration of interface paths and data fields for different manufacturers and versions of BMC is solved. Through the Redfish protocol and BMC out-of-band management capabilities, the technical features of fan data acquisition and fan curve monitoring in S5 state can be achieved through BMC without relying on the server's main operating system and main CPU. By splitting the acquisition task and using a thread pool for parallel execution, the problem of long time consumption and low monitoring efficiency of traditional single-threaded sequential acquisition of hardware data is solved. By synchronously blocking the acquisition results through Future objects, the integrity and timing consistency of multi-threaded acquisition results are guaranteed, and the problems of data loss and unusable results caused by asynchronous acquisition are solved. By standardizing the acquired data, the problems of messy original hardware data formats, inconsistent types, and disordered sorting, which make it difficult to display intuitively and for subsequent analysis and utilization, are solved.

[0028] In another embodiment, step S101, "obtaining the Internet Protocol IP address and authentication information of the server's Baseboard Management Controller (BMC)," includes: Obtain the BMC's IP address, username, and password based on configuration files or command-line arguments; The configuration file and command-line parameters contain the default account password for BMC and sensor field parameters; the sensor field parameters include the mapping relationship between the sensor type identifier and the corresponding Redfish standard field of the sensor.

[0029] In this embodiment, the configuration file is a pre-written parameter file stored locally. It uses a structured format to store fixed information such as the BMC's IP address, username, and password. When the monitoring program runs, it directly reads the file content to acquire information. Command-line parameters are the BMC's IP address, username, and password appended directly to the terminal command that starts the monitoring program. The program parses the terminal input command in real time to extract the corresponding information upon startup. These two acquisition methods are independent and can be flexibly selected according to the usage scenario, completing information collection without relying on other external systems or interfaces. For example, the BMC's IP address can be written as 192.168.1.100, the username as admin, and the password as admin by editing the local configuration file; alternatively, the IP address, username, and password can be directly appended as parameters when executing the program on the terminal.

[0030] In this embodiment, in addition to carrying the target server BMC's dedicated IP address, username, and password, the configuration file and command-line parameters also include preset default BMC username and password combinations, covering the standard default authentication information of mainstream server manufacturers in the industry. This allows for adaptation to the authentication requirements of conventional servers without manual addition. It also includes sensor field parameters, which serve as the basis for matching fields in hardware data acquisition and are used to subsequently identify and extract corresponding hardware indicator data. Both the default username and password and the sensor field parameters are pre-configured and can be directly called, reducing the complexity of parameter configuration. For example, the configuration file presets commonly used default usernames and passwords such as admin / admin and Administrator / Admin@123, and also includes fixed parameter items related to sensors.

[0031] In this embodiment, the sensor type identifier is a marker character used to distinguish different types of sensors such as temperature, voltage, and power, and is the core basis for identifying the sensor category. The Redfish standard field mapping relationship corresponding to the sensor is a pre-established matching rule that binds the sensor type identifier to the standard field name and field path of the corresponding hardware data in the Redfish protocol. This ensures accurate matching and extraction of target data during data acquisition without the need to redefine field matching rules for different servers. This mapping relationship is a standardized configuration that adapts to the general data structure of the Redfish protocol, ensuring data acquisition compatibility in multi-server scenarios.

[0032] In this embodiment, the IP address and authentication information of the BMC are obtained through two flexible methods: configuration files and command-line parameters. At the same time, the default account password and standardized sensor field parameters are built-in, which simplifies the parameter configuration process before monitoring and ensures the compatibility and accuracy of data collection through standardized mapping relationships. Basic configuration can be completed without manually writing adaptation rules, which improves the ease of use and deployment efficiency of the monitoring method.

[0033] In another embodiment, step S102, "completing Redfish login authentication with BMC based on authentication information and obtaining a session token," includes: Send a POST request carrying authentication information to the Redfish session service URI of BMC; the authentication information includes the BMC username and password; Receive the session token and session URI returned by the BMC; Establish and maintain an authentication session with the BMC based on the session token and session URI, and cache the session token during the validity period of the authentication session.

[0034] In this embodiment, the Redfish session service URI of the BMC is a fixed interface address defined by the Redfish standard for creating login sessions. All BMCs supporting the Redfish protocol will expose this URI for session creation. Using HTTPS as the transport layer protocol, a POST request message conforming to the Redfish format is constructed, encapsulating the obtained username and password as identity credentials in the request body, and sent to the BMC's session service interface. This POST request provides the BMC with all the information required to verify identity and is a necessary operation for establishing a legitimate session.

[0035] In this embodiment, after receiving a POST request carrying authentication information, the BMC verifies the validity of the username and password. Upon successful verification, it automatically generates a unique temporary identity credential for the current session, namely a session token, and returns the corresponding session URI for subsequent maintenance, cancellation, and other operations. The system passively receives the response data returned by the BMC without modifying the data or performing any logical processing; it only temporarily stores the session token and session URI to prepare for subsequent session maintenance and data collection. For example, after successful verification, the BMC returns a session token of type X-Auth-Token in the response header and the URI address of the corresponding session in the response body.

[0036] In this embodiment, a session token is used as the identity identifier and the session URI as the session management address to formally establish an authentication session with the BMC. Throughout the monitoring process, the session token is continuously used to initiate data collection requests, maintaining the session in a valid state. Simultaneously, the session token is cached in local memory to avoid repeated login operations, reducing BMC interaction overhead and network latency. Caching is only performed within the validity period of the authentication session; the cache is cleared after the session expires or the user actively logs out. For example, the acquired session token can be stored in the program's runtime memory, and each subsequent request to the BMC can be directly read from the cache and include the token.

[0037] In this embodiment, login authentication is completed through the Redfish session process, HTTPS ensures transmission security, session tokens enable continuous access without repeated logins, and token caching improves interaction efficiency. Overall, it achieves secure, stable, and efficient BMC authentication and session management, providing a reliable identity foundation for subsequent hardware data collection.

[0038] In another embodiment, step S103, "determining the Redfish URI path and field location corresponding to the BMC's hardware resources," includes: Obtain the Redfish root service documentation for BMC; Based on the resource links in the Redfish root service documentation, detect and match the hardware resource URI path corresponding to the current BMC firmware version; Parse the JSON Schema or sample response of the hardware resources to determine the location of the fields used to extract status data, and establish a dynamic mapping table between the field locations and the monitoring metric types.

[0039] In this embodiment, the Redfish root service document is a top-level service description file provided by the BMC that conforms to the Distributed Management Task Force (DMTF) standard. It is used to inform clients of the entry addresses of all accessible hardware resources. By sending a standard GET request to the BMC's Redfish root path, the complete content of the root service document can be directly obtained. This document contains the link entry points and basic version information of all sub-resources and is the sole basis for subsequent resource retrieval.

[0040] In this embodiment, the program can traverse the standard resource links such as Chassis, Thermal, and Power from the acquired Redfish root service documentation. The program automatically reads the firmware version number, manufacturer information, and model information of the current BMC, and then compares it with internally preset path matching rules to filter out hardware resource URI paths that are fully compatible with the current BMC. This process automatically completes path detection and BMC version matching, covering path differences between different manufacturers and different versions of BMC.

[0041] In this embodiment, a data read request can be initiated for the matched hardware resource URI path to obtain JSON formatted data, or the JSON Schema specification document corresponding to the resource can be directly parsed to parse the storage level and key name of data such as temperature, fan speed, voltage, and power field by field. Then, the parsed field positions are bound one-to-one with the monitoring indicator types (such as CPU temperature, system fan speed, 12V voltage) to generate a dynamic mapping table. This mapping table can be directly called during program execution for quickly extracting target data.

[0042] In this disclosure, by automatically obtaining the root service, matching the URI path with the version, and parsing the JSON structure to establish field mapping, fully automatic hardware resource location for different BMC versions is achieved. No manual configuration modification or separate adaptation for different servers is required, which greatly improves the compatibility and versatility of the monitoring method and reduces the configuration cost for on-site use.

[0043] In another embodiment, step S104, "splitting the server's hardware data acquisition task into a sensor data acquisition task and a fan data acquisition task," includes: Generate an independent sensor data acquisition task for each sensor resource to be monitored in the server; the sensor data acquisition task includes at least one of the following: temperature sensor acquisition subtask, voltage sensor acquisition subtask, and power sensor acquisition subtask. Generate an independent fan data acquisition task for each fan resource to be monitored in the server. The fan data acquisition task includes a fan speed acquisition subtask and a fan health status acquisition subtask. Add all data collection subtasks to the execution queue and assign a unique task identifier to each data collection task.

[0044] In this embodiment, server hardware monitoring includes various sensor resources, each corresponding to an independent data acquisition target. A separate acquisition task can be created for each monitored sensor based on its physical quantity and type, ensuring that data acquisition from each sensor is independent. The sensor data acquisition task is further broken down into the smallest execution unit, i.e., subtasks, including temperature sensor acquisition subtasks, voltage sensor acquisition subtasks, and power sensor acquisition subtasks. One or more of these subtasks can be selected and combined for execution based on actual monitoring needs. For example, if the server includes 4 CPU temperature sensors, 3 voltage sensors, and 2 power sensors, corresponding temperature, voltage, and power acquisition subtasks can be created for each of these sensors.

[0045] In this embodiment, each fan in the server is an independent hardware resource. A separate fan data acquisition task can be created for each fan to be monitored, based on the physical number of fans, ensuring that the status of each fan can be independently collected and tracked. The fan data acquisition task is further divided into two standard subtasks: a fan speed acquisition subtask to obtain operating parameters such as the current fan speed and PWM duty cycle, and a fan health status acquisition subtask to obtain health status information such as fan presence, faults, and alarms. These two subtasks together complete the full status acquisition of a single fan. For example, if the server is configured with six cooling fans, a separate fan speed acquisition subtask and a health status acquisition subtask are created for each fan.

[0046] In this embodiment, all the sensor acquisition subtasks and fan acquisition subtasks generated above can be aggregated and added sequentially to the thread pool's execution queue, forming an ordered task waiting list for thread pool scheduling and execution. Simultaneously, a globally unique task identifier is assigned to each independent acquisition subtask. This identifier is used to distinguish different tasks, track task execution status, and match task return results, avoiding confusion, errors, or loss when multiple tasks are executed in parallel. For example, temperature sensor subtasks can be labeled as TEMP_001 and TEMP_002, and fan subtasks as FAN_001 and FAN_002, using numerical numbering or string encoding.

[0047] In this embodiment, by splitting independent acquisition subtasks according to hardware resource granularity, the acquisition logic is decoupled and standardized. Tasks are managed uniformly through a queue to be executed, and the accuracy of multi-task parallelism is ensured through a unique identifier. This provides a stable task foundation for subsequent high-concurrency and conflict-free execution of the thread pool, thereby improving the controllability and stability of the acquisition process.

[0048] In another embodiment, step S105, "based on the session token, Redfish URI path, and field location, performs parallel execution of the sensor data acquisition task and the fan data acquisition task using a thread pool," includes: Retrieve collection subtasks from the queue to be executed, and bind the collection subtasks with the corresponding session tokens, Redfish URI paths and field positions to generate collection instructions; The acquisition command is submitted to the thread pool. The thread pool starts multiple execution threads simultaneously based on the core thread count and the maximum thread count, and each thread calls the acquisition command to send a data read request to the BMC.

[0049] In this embodiment, sensor data acquisition subtasks or fan data acquisition subtasks can be sequentially retrieved from the queue to be executed. The session token, Redfish URI path, and field extraction location required for each subtask are then bound together to form a complete, independent acquisition command that can be directly issued to the BMC. The session token is used for identity verification, the Redfish URI path is used to locate hardware resources, and the field location is used to specify the data items to be extracted; all three are indispensable.

[0050] In this embodiment, the assembled acquisition instructions can be submitted to a pre-initialized thread pool. The thread pool automatically allocates idle threads to handle the acquisition instructions according to the configured core thread count and maximum thread count. The thread pool simultaneously starts multiple independent execution threads, each thread invoking its corresponding acquisition instruction and sending a standard GET type data read request to the BMC via the HTTPS protocol, achieving parallel multi-task acquisition. The number of threads can be dynamically adjusted according to the server hardware scale, with a default maximum of 8 working threads to ensure a balance between acquisition efficiency and system resource consumption. For example, the thread pool can simultaneously allocate 4 threads to execute temperature, voltage, power, and fan acquisition instructions respectively, sending 4 requests to the BMC in parallel to obtain data.

[0051] In this embodiment, standardized collection instructions are generated by binding tasks with key information, and then executed concurrently by a thread pool. This significantly shortens the overall collection time, enables millisecond-level parallel acquisition of hardware data, effectively solves the problems of high latency and inability to capture sudden state changes in traditional single-threaded collection, and improves the utilization rate of system resources.

[0052] In another embodiment, step S106, "synchronously acquiring the acquisition results obtained from the sensor data acquisition task and the fan data acquisition task based on the Future object," includes: The execution results of each collection subtask are encapsulated using Future objects; The result retrieval interface of the Future object is called in a blocking manner to wait for all collection subtasks to complete before retrieving the collection results in a unified manner. Mutex locks are used to protect thread-shared resources during parallel acquisition.

[0053] In this embodiment, the Future object serves as a carrier for the execution status and return data of asynchronous tasks. Each data acquisition subtask submitted to the thread pool creates a unique Future object upon startup. This object continuously tracks the running status of its assigned subtask, including waiting to execute, executing, completed, and exception handling, and stores the hardware data or error information ultimately acquired by the subtask within the object, thus encapsulating the results. The encapsulated Future object does not affect the execution of other tasks; it independently maintains the result data of its own task. For example, a separate Future object is created for each temperature acquisition subtask and each fan acquisition subtask to separately store the temperature value, fan speed value, or task error information for that task.

[0054] In this embodiment, the result acquisition interface provided by each Future object can also be actively called. This interface adopts a blocking waiting mechanism, that is, if the corresponding acquisition subtask has not been completed, the program will pause the current process and wait until the subtask is completely finished. Only when all the subtasks contained in the sensor data acquisition task and the fan data acquisition task have been completed will the encapsulated acquisition results be extracted from each Future object in sequence to achieve a unified summary of all results. This avoids data loss or corruption caused by differences in task execution speed.

[0055] In this embodiment, when multiple data acquisition threads run in parallel, they may simultaneously access shared resources such as the task queue, result storage area, and log files. Without proper control, this can lead to data overwriting, conflicts, or program crashes. A mutex lock is a thread synchronization protection mechanism. Before a thread needs to operate on a shared resource, it requests a lock on the resource. During the lock period, other threads cannot access the resource. Once the current thread completes its operation, it releases the lock, allowing other threads to continue accessing it. By adding mutex lock control to the shared resource access logic, it can be ensured that only one thread operates on the shared resource at a time.

[0056] In this embodiment, the results of asynchronous tasks are managed in a standardized manner through Future objects, data integrity is ensured through blocking and waiting, and multi-threaded concurrency safety is guaranteed through mutex locks. This improves the efficiency of data collection, ensures data accuracy and stable program operation, and avoids data conflicts and abnormal states in concurrent scenarios.

[0057] In another embodiment, step S107, "standardizing the collected results to obtain the server's hardware status information," includes: The collected results are filtered and categorized using keywords to obtain the classification results; the categories in the classification results include temperature, power, voltage, and fan. The data in the classification results are sorted according to preset rules; among them, temperature data are sorted in the order of air inlet, CPU, memory and other hardware, power data and voltage data are sorted in the order of coding, and fan data are sorted in the order of number, direction and speed level. The sorted data is formatted to obtain hardware status information.

[0058] In this embodiment, all collected raw hardware status data can be traversed, matched and filtered according to preset keyword rules, and the data can be divided into corresponding categories. For example, data containing the keywords "Temp" and "_T" is classified as temperature; data containing the keyword "Power" is classified as power; data starting with "P" and containing "Volts" is classified as voltage; and data containing the keyword "Fan" is classified as fan. After filtering and classification, all data is organized into four main types, realizing centralized management of similar data, which facilitates subsequent processing and viewing.

[0059] In this embodiment, a preset sorting rule needs to be applied to each type of data. Specifically, temperature data is sorted first by inlet air temperature, then CPU temperature, then memory temperature, with remaining sensor data grouped under other hardware order. Power and voltage data are sorted in ascending order of sensor number and physical channel code. Fan data is sorted first by fan number, then by direction of rotation within the same number, and finally by fan speed level. The sorted data conforms to the server hardware layout logic, facilitating administrators to quickly locate the status of critical components.

[0060] In this embodiment, the formatting process includes: all numerical data are uniformly retained to two decimal places; items with no collected values, sensor malfunctions, or no data are uniformly marked as "None"; and data names, units, and values ​​are structurally combined to form items with a fixed format. After formatting, all hardware status information has a uniform style, is easy to read, and facilitates recording and comparative analysis, ultimately forming standardized server hardware status information.

[0061] In this embodiment, the scattered, disordered, and inconsistently formatted raw data is transformed into hardware status information that is clearly categorized, reasonably sorted, and formatted in a standardized manner through a three-step process of filtering and classification, rule-based sorting, and unified formatting. This significantly improves data readability and usability, making it easier for administrators to quickly view, compare, and locate faults, while also meeting the standardized requirements for log recording and data reporting.

[0062] In another embodiment, a monitoring method based on the Redfish protocol further includes: Hardware data acquisition tasks are periodically executed during the monitoring runtime; After each collection cycle ends, release the completed Future objects and thread pool resources; After the monitoring runtime is reached, a Redfish logout request is sent to the BMC to destroy the session token and generate a hardware status anomaly record for the monitoring runtime.

[0063] In this embodiment, a pre-set monitoring runtime is obtained upon startup, which can support different time units such as seconds, minutes, and hours. Within the entire runtime, the system repeatedly executes the complete data collection process according to a fixed collection cycle (e.g., 10 seconds): establishing a session, locating the URI, parallel data collection, result acquisition, and data standardization processing. Each cycle is independent, and the data is continuously updated, thereby achieving continuous tracking and recording of the server hardware status. For example, if the monitoring duration is set to 2 hours and the collection interval is 10 seconds, the system will complete one round of hardware data collection every 10 seconds within 2 hours.

[0064] In this embodiment, after a single acquisition cycle is completed and the data has been successfully acquired and processed, the system proactively cleans up all Future objects created in the current cycle, releasing the memory space they occupy. Simultaneously, it reclaims completed task threads from the thread pool to an idle state, resets the thread execution context, and does not destroy the threads, allowing them to be reused in the next acquisition cycle. By releasing useless objects and reclaiming thread resources cycle by cycle, the system ensures stable memory usage and a controllable number of threads during long-term operation, preventing resource exhaustion due to continuous operation.

[0065] In this embodiment, once the system has run for the set monitoring duration, the periodic data collection task automatically stops. Subsequently, a standard Redfish logout request is sent to the session URI corresponding to the BMC. Upon receiving the request, the BMC immediately destroys the session token used for this monitoring, rendering it invalid and preventing further access to the BMC, thus ensuring session security. Simultaneously, the system iterates through and analyzes all hardware status data collected throughout the monitoring period, identifying abnormal data items such as excessive temperature, abnormal fan speed, voltage exceeding limits, and sensor loss. This data is then compiled into a hardware status anomaly record for subsequent problem localization and testing analysis.

[0066] In this embodiment, long-term stable monitoring is achieved through periodic data collection, long-term reliable system operation is ensured by releasing resources periodically, BMC access security is guaranteed by secure logout and token destruction, and hardware problem localization efficiency is improved by automatically generating anomaly records. This fully realizes standardized monitoring of the entire process from startup and continuous operation to secure termination.

[0067] To facilitate understanding of the monitoring method based on the Redfish protocol disclosed herein, a specific embodiment is provided below: (1) System architecture design The system adopts a layered and modular architecture, with each layer having independent functions that also work collaboratively, as detailed below: 1. Core Layer: Responsible for data acquisition and BMC communication, containing 2 core modules: The Redfish client module (redfish_client.py) enables full-process communication with the BMC, including session creation, login authentication (based on the Redfish protocol), data acquisition, and session cancellation. It also supports standardized acquisition of hardware resources such as Temperature, Power, and Fan. OS Extended Data Module (exec_linux.py): Uses tools such as smartctl to capture detailed data from storage devices (HDD, NVMe), network cards, and other components, supplementing the core layer's data collection scope.

[0068] 2. Concurrency Layer: Thread pool module (threadpools.py) improves real-time data collection performance. a) The default configuration has a maximum of 8 working threads, which can be dynamically adjusted via parameters; b) Split "sensor data acquisition" and "fan data acquisition" into independent tasks and execute them in parallel using pools.submit() to avoid single-threaded latency; c) Use a Future object to encapsulate the task result, and obtain the result through future.result() in a blocking manner to ensure data integrity; d) Protect shared resources with mutex locks to avoid concurrent access conflicts.

[0069] 3. Data Processing Layer: Responsible for data classification, sorting, and formatting. a) Smart Adaptation Module (load_first.py): Automatically detects URI paths and field positions for different BMC versions, eliminating the need for manual configuration and improving compatibility; b) Data processing module (data_handler.py): Category: Filter data by keywords (temperature contains "Temp" or "_T", power contains "Power", voltage starts with "P" and contains "Volts", fan contains "Fan"); Sorting: Temperature is sorted by "Air Inlet → CPU → Memory → Others", Power / Voltage is sorted by numerical sequence, and Fans are sorted by number → rotation direction → speed level; Formatting: Raw data is kept to two decimal places, and sensors with no data are marked as "None" to ensure output consistency.

[0070] 4. Configuration layer: Configuration modules (log_config.py, config.ini) support flexible configuration. a) Configuration file (config.ini): Stores server IP, username, password, etc. The INI format is easy to edit; b) Default configuration: Presets common BMC username and password combinations (such as admin / admin) to reduce configuration costs; c) Sensor parameters: Preset fields such as data name, data value, and fan parameters, supporting subsequent expansion of sensor types.

[0071] 5. Interaction Layer: Command line and deployment module, improving ease of use: a) Command line argument parsing (log_redfish.py): Supports parameters such as -h (BMC IP), -t (runtime), -u (username), -p (password), and -b (basic mode), and is compatible with both configuration files and command line methods; b) One-click installation script (install.sh): Automatically creates the installation directory / opt / log_redfish, configures the startup link, and supports starting directly via the log_redfish command; c) One-click uninstallation script (uninstall.sh): Automatically deletes the installation directory and startup links, leaving no residue.

[0072] (2) Implementation of key technologies 1. Redfish protocol communication: Connect to BMC via HTTPS, send a POST request to create a session and obtain an X-Auth-Token, and use the token to call the Redfish API to collect hardware data, supporting standardized adaptation to multiple brand servers; 2. Concurrent data acquisition: The thread pool processes sensor and fan data in parallel, reducing the acquisition interval to 1 second and capturing sudden changes in hardware status in real time; 3. Intelligent adaptation: Automatically detects URI paths and field positions for different BMC versions, eliminating the need for manual configuration modifications and adapting to multiple server models; 4. Flexible deployment: One-click installation / uninstallation, no complex dependency libraries required, and strong adaptability to cross-environment deployment; 5. Out-of-band and S5 status support: Based on the Redfish protocol and BMC out-of-band management capabilities, it does not rely on the server's main operating system and supports out-of-band data collection and S5 status fan curve monitoring in intranet environments.

[0073] (3) Work process 1. Initialization: Read configuration files or command-line parameters to obtain information such as BMC IP, username, password, and runtime; 2. Session Establishment: Establish an HTTPS connection with BMC through the Redfish client, complete Redfish login authentication, and obtain a session token; 3. Resource Location: Automatically loads the Redfish URI paths of hardware resources such as temperature and fans in the current BMC version to determine the data acquisition address; 4. Concurrent data acquisition: The thread pool submits sensor data acquisition and fan data acquisition tasks in parallel, and synchronously obtains hardware status data; 5. Data processing: Classify, sort, and format the collected data to generate standardized data lists; 6. Output Display: Real-time output of monitoring results, with support for log recording; 7. Termination Mechanism: When the runtime is reached or a termination signal is received, the Redfish session is logged out, resources are released, and the program is terminated.

[0074] (4) Usage process and solution 1. Installation: Copy the log_redfish.tar package to the server, extract it, and grant executable permissions to install.sh (chmod +xinstall.sh). Execute the script to complete the installation. 2. Configuration: Edit the / opt / log_redfish / config.ini file and fill in the BMC IP, username, password and other information (or overwrite via command line parameters); 3. Execution: Start data collection by executing the `log_redfish` command in any OS path. The following core usage scenarios are supported: a) Basic data collection: log_redfish|tee-a test data (data scraped from the current directory, supports csv and xlsx formats); b) Timed data collection: log_redfish-t2h|tee-a test data (captures 2 hours of data, supports s / m / h units); c) Out-of-band data collection: log_redfish-hbmcip-uuser-ppasswd|tee-a test data (specify BMC IP, username, and password for out-of-band data collection); d) Basic mode: log_redfish-bTrue|tee-a test data (only core sensor data is shown).

[0075] Figure 2 A schematic diagram of a monitoring system based on the Redfish protocol according to an embodiment of this disclosure is shown, as follows: Figure 2 As shown, a monitoring system based on the Redfish protocol includes: Module 10 is used to obtain the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server. Communication module 11 is used to establish a communication connection with BMC via HTTPS protocol based on BMC's IP address, and to complete Redfish login authentication with BMC and obtain session token based on authentication information; Module 12 is used to determine the Redfish URI path and field location corresponding to the hardware resources of the BMC; Concurrency module 13 is used to split the server's hardware data acquisition task into sensor data acquisition task and fan data acquisition task, and to execute the sensor data acquisition task and fan data acquisition task in parallel through a thread pool based on session token, Redfish URI path and field position. Acquisition module 14 synchronously acquires the acquisition results obtained from sensor data acquisition tasks and fan data acquisition tasks based on Future objects; Processing module 15 performs standardized processing on the collected results to obtain the server's hardware status information.

[0076] In another embodiment, the acquisition module 10 is further configured to: Obtain the BMC's IP address, username, and password based on configuration files or command-line arguments; The configuration file and command-line parameters contain the default account password for BMC and sensor field parameters; the sensor field parameters include the mapping relationship between the sensor type identifier and the corresponding Redfish standard field of the sensor.

[0077] In another embodiment, the communication module 11 is further configured to: Send a POST request carrying authentication information to the Redfish session service URI of BMC; the authentication information includes the BMC username and password; Receive the session token and session URI returned by the BMC; Establish and maintain an authentication session with the BMC based on the session token and session URI, and cache the session token during the validity period of the authentication session.

[0078] In another embodiment, the determining module 12 is further configured to: Obtain the Redfish root service documentation for BMC; Based on the resource links in the Redfish root service documentation, detect and match the hardware resource URI path corresponding to the current BMC firmware version; Parse the JSON Schema or sample response of the hardware resources to determine the location of the fields used to extract status data, and establish a dynamic mapping table between the field locations and the monitoring metric types.

[0079] In another embodiment, the concurrency module 13 is further configured to: Generate an independent sensor data acquisition task for each sensor resource to be monitored in the server; the sensor data acquisition task includes at least one of the following: temperature sensor acquisition subtask, voltage sensor acquisition subtask, and power sensor acquisition subtask. Generate an independent fan data acquisition task for each fan resource to be monitored in the server. The fan data acquisition task includes a fan speed acquisition subtask and a fan health status acquisition subtask. Add all data collection subtasks to the execution queue and assign a unique task identifier to each data collection task.

[0080] In another embodiment, the concurrency module 13 is further configured to: Retrieve collection subtasks from the queue to be executed, and bind the collection subtasks with the corresponding session tokens, Redfish URI paths and field positions to generate collection instructions; The acquisition command is submitted to the thread pool. The thread pool starts multiple execution threads simultaneously based on the core thread count and the maximum thread count, and each thread calls the acquisition command to send a data read request to the BMC.

[0081] In another embodiment, the acquisition module 14 is further configured to: The execution results of each collection subtask are encapsulated using Future objects; The result retrieval interface of the Future object is called in a blocking manner to wait for all collection subtasks to complete before retrieving the collection results in a unified manner. Mutex locks are used to protect thread-shared resources during parallel acquisition.

[0082] In another embodiment, the processing module 15 is further configured to: The collected results are filtered and categorized using keywords to obtain the classification results; the categories in the classification results include temperature, power, voltage, and fan. The data in the classification results are sorted according to preset rules; among them, temperature data are sorted in the order of air inlet, CPU, memory and other hardware, power data and voltage data are sorted in the order of coding, and fan data are sorted in the order of number, direction and speed level. The sorted data is formatted to obtain hardware status information.

[0083] In another embodiment, the concurrency module 13 is further configured to periodically execute hardware data acquisition tasks during the monitoring runtime; the acquisition module 14 is further configured to release completed Future objects and thread pool resources after each acquisition cycle ends; the communication module 11 is further configured to send a Redfish logout request to the BMC to destroy the session token after the monitoring runtime is reached; and the processing module 15 is further configured to generate hardware status anomaly records during the monitoring runtime.

[0084] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0085] Figure 3A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0086] like Figure 3 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0087] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0088] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as a Redfish protocol-based monitoring method. For example, in some embodiments, a Redfish protocol-based monitoring method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the Redfish protocol-based monitoring method described above can be performed. Alternatively, in other embodiments, the computing unit 801 may be configured, by any other suitable means (e.g., by means of firmware), to perform a monitoring method based on the Redfish protocol.

[0089] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0090] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0091] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0092] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0093] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0094] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0095] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0096] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0097] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A monitoring method based on the Redfish protocol, characterized in that, The method includes: Obtain the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server; Based on the IP address of the BMC, a communication connection is established with the BMC via the HTTPS protocol, and Redfish login authentication with the BMC is completed and a session token is obtained based on the authentication information; Determine the Redfish URI path and field location corresponding to the hardware resources of the BMC; The hardware data acquisition task of the server is split into sensor data acquisition task and fan data acquisition task, and the sensor data acquisition task and fan data acquisition task are executed in parallel through a thread pool based on the session token, Redfish URI path and field position. The acquisition results obtained from the sensor data acquisition task and the fan data acquisition task are obtained synchronously based on the Future object; The collected results are standardized to obtain the hardware status information of the server.

2. The method according to claim 1, characterized in that, The acquisition of the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server includes: Based on configuration files or command-line parameters, obtain the IP address, username, and password of the BMC; The configuration file and command-line parameters include the default account password for BMC and sensor field parameters; the sensor field parameters include the mapping relationship between the sensor type identifier and the corresponding Redfish standard field of the sensor.

3. The method according to claim 1, characterized in that, The process of completing Redfish login authentication with the BMC and obtaining a session token based on the authentication information includes: Send a POST request carrying the authentication information to the Redfish session service URI of the BMC; the authentication information includes the username and password of the BMC; Receive the session token and session URI returned by the BMC; An authentication session with the BMC is established and maintained based on the session token and session URI, and the session token is cached during the validity period of the authentication session.

4. The method according to claim 1, characterized in that, Determining the Redfish URI path and field location corresponding to the hardware resources of the BMC includes: Obtain the Redfish root service documentation for the BMC; Based on the resource links in the Redfish root service document, detect and match the hardware resource URI path corresponding to the current BMC firmware version; Parse the JSON Schema or sample response of the hardware resource to determine the location of the fields used to extract status data, and establish a dynamic mapping table between the field locations and the monitoring indicator types.

5. The method according to claim 1, characterized in that, The step of splitting the server's hardware data acquisition task into sensor data acquisition tasks and fan data acquisition tasks includes: An independent sensor data acquisition task is generated for each sensor resource to be monitored in the server; the sensor data acquisition task includes at least one of a temperature sensor acquisition subtask, a voltage sensor acquisition subtask, and a power sensor acquisition subtask. An independent fan data acquisition task is generated for each fan resource to be monitored in the server. The fan data acquisition task includes a fan speed acquisition subtask and a fan health status acquisition subtask. Add all collection subtasks to the execution queue and assign a unique task identifier to each collection task.

6. The method according to claim 5, characterized in that, The method of parallel execution of the sensor data acquisition task and the fan data acquisition task using a thread pool based on the session token, Redfish URI path, and field location includes: Obtain a collection subtask from the queue to be executed, and bind the collection subtask with the corresponding session token, Redfish URI path and field position to generate a collection instruction; The acquisition command is submitted to the thread pool, which simultaneously starts multiple execution threads based on the core thread count and the maximum thread count, and calls the acquisition command to send a data read request to the BMC.

7. The method according to claim 5, characterized in that, The method of synchronously acquiring the acquisition results obtained from the sensor data acquisition task and the fan data acquisition task based on the Future object includes: The execution results of each collection subtask are encapsulated using Future objects; The result retrieval interface of the Future object is called in a blocking manner to wait for all collection subtasks to complete before retrieving the collection results in a unified manner. Mutex locks are used to protect thread-shared resources during parallel acquisition.

8. The method according to claim 1, characterized in that, The standardization process of the collected results to obtain the hardware status information of the server includes: The collected results are filtered and categorized using keywords to obtain classification results; the types in the classification results include temperature, power, voltage, and fan. The data in the classification results are sorted according to preset rules; among them, temperature data are sorted in order of air inlet, CPU, memory and other hardware, power data and voltage data are sorted in the order of coding, and fan data are sorted in order of number, direction and speed level. The sorted data is formatted to obtain the hardware status information.

9. The method according to claim 1, characterized in that, The method further includes: The hardware data acquisition task is executed periodically during the monitoring runtime; After each collection cycle ends, release the completed Future objects and thread pool resources; After the monitoring runtime is reached, a Redfish logout request is sent to the BMC to destroy the session token and generate a hardware status anomaly record for the monitoring runtime.

10. A monitoring system based on the Redfish protocol, characterized in that, The system includes: The acquisition module is used to acquire the Internet Protocol IP address and authentication information of the Baseboard Management Controller (BMC) of the server; The communication module is used to establish a communication connection with the BMC via the HTTPS protocol based on the BMC's IP address, and to complete Redfish login authentication with the BMC and obtain a session token based on the authentication information. The determination module is used to determine the Redfish URI path and field location corresponding to the hardware resources of the BMC; The concurrency module is used to split the server's hardware data acquisition task into sensor data acquisition task and fan data acquisition task, and to execute the sensor data acquisition task and fan data acquisition task in parallel through a thread pool based on the session token, Redfish URI path and field position. The acquisition module synchronously acquires the acquisition results obtained from the sensor data acquisition task and the fan data acquisition task based on the Future object; The processing module performs standardized processing on the collected results to obtain the hardware status information of the server.

11. The system according to claim 10, characterized in that, The acquisition module is also used for: Based on configuration files or command-line parameters, obtain the IP address, username, and password of the BMC; The configuration file and command-line parameters include the default account password for BMC and sensor field parameters; the sensor field parameters include the mapping relationship between the sensor type identifier and the corresponding Redfish standard field of the sensor.

12. The system according to claim 10, characterized in that, The communication module is also used for: Send a POST request carrying the authentication information to the Redfish session service URI of the BMC; the authentication information includes the username and password of the BMC; Receive the session token and session URI returned by the BMC; An authentication session with the BMC is established and maintained based on the session token and session URI, and the session token is cached during the validity period of the authentication session.

13. The system according to claim 10, characterized in that, The determining module is also used for: Obtain the Redfish root service documentation for the BMC; Based on the resource links in the Redfish root service document, detect and match the hardware resource URI path corresponding to the current BMC firmware version; Parse the JSON Schema or sample response of the hardware resource to determine the location of the fields used to extract status data, and establish a dynamic mapping table between the field locations and the monitoring indicator types.

14. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

15. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

Images