A server hardware device monitoring system and a server system

Abstract

The present application discloses a server hardware device monitoring system and a server system, including: a foreground prompt device cluster, a message broker service cluster, and a background monitoring service cluster. The message broker service cluster includes multiple containers, and each container includes a publisher queue and a subscriber queue. The message broker service cluster is configured to: obtain messages sent by the foreground prompt device cluster or the background monitoring service cluster through the publisher queue; determine subscribers who subscribe to the messages in the subscriber queue; and send the messages to the target management program in the background monitoring cluster corresponding to each subscriber or the foreground prompt module in the foreground prompt device cluster. The present application can decouple the front and back-end clusters, improving data processing efficiency and transmission performance.

Description

Technical Field

[0001] This application relates to the field of servers, and particularly to a server hardware device monitoring system and a server system. Background Art

[0002] With the development of IT industries such as 5G communication and artificial intelligence, more and more terminal hardware devices have been upgraded to intelligent hardware devices by adding computing, storage, and network units, such as intelligent business card holders and server computing power acceleration cards. Due to possible software and hardware design bugs and operation times limitations in the devices themselves, and possible system anomalies caused by user misoperations, complex monitoring software is required to continuously monitor the running status of the server system.

[0003] Currently, the common practice is to customize a set of monitoring software for a certain hardware device. The monitoring software is divided into two parts: a foreground display module and a background monitoring module. The front-end and back-end software modules are mutually dependent. When the foreground display module sends a monitoring instruction to the background monitoring module or the background monitoring module transmits device abnormal status information to the foreground display module, the data recipient must be clearly specified. Due to the high coupling degree between the front-end and back-end software modules, any change on either side of the front-end and back-end software modules must be modified simultaneously in the software module of the opposite side. In addition, due to the synchronous transmission method between the front-end and back-end software modules, when a device node (such as a device running the background software) in the monitoring system is processing an instruction or transmitting data, the processors and data transmission channels of other device nodes are in an idle waiting state, resulting in low data processing and transmission performance.

[0004] Therefore, how to provide a solution to the above technical problems is an issue that those skilled in the art need to solve currently. Summary of the Invention

[0005] The purpose of this application is to provide a server hardware device monitoring system and a server system, which can decouple the front-end and back-end clusters and improve data processing efficiency and transmission performance.

[0006] To solve the above technical problems, this application provides a server hardware device monitoring system, including: a foreground prompt device cluster, a message broker service cluster, and a background monitoring service cluster. The message broker service cluster includes multiple containers, and each container includes a publisher queue and a subscriber queue, where:

[0007] The message broker service cluster is used to obtain messages sent by the foreground prompt device cluster or the background monitoring service cluster through the publisher queue, determine subscribers who subscribe to the messages in the subscriber queue, and send the messages to the target management program in the background monitoring cluster or the foreground prompt module in the foreground prompt device cluster corresponding to each subscriber.

[0008] Optionally, each of the containers corresponds to a message type.

[0009] Optionally, the multiple containers include a command request container, a command response container, and a status reporting container.

[0010] Optionally, the background monitoring service cluster further includes:

[0011] A polling instruction processing module, configured to poll a hardware device register after receiving a polling instruction to obtain device status information, and copy the device status information to the status polling module;

[0012] The status polling module is configured to, when detecting abnormal status information in the device status information, send the abnormal status information to the publisher queue of the status reporting container.

[0013] Optionally, the background monitoring service cluster further includes:

[0014] A hardware interrupt processing module, configured to obtain abnormal status information when receiving an interrupt instruction, and report the abnormal status information to an event processing module;

[0015] The event processing module is configured to send the abnormal status information to the publisher queue of the status reporting container.

[0016] Optionally, each of the containers further includes a recorder queue, and the message broker service cluster further includes:

[0017] A queue management process, configured to store the message data stream information of each container into the recorder queue of the container.

[0018] Optionally, the server hardware device monitoring system further includes a database;

[0019] The queue management process is further configured to store the message data stream information in each recorder queue into the database according to a preset storage rule.

[0020] Optionally, storing the message data stream information in each recorder queue into the database according to the preset storage rule:

[0021] When the message data stream information is written into the recorder queue, store the message data stream information into the database.

[0022] To solve the above technical problems, the present application further provides a server system, including the server hardware device monitoring system described in any one of the above.

[0023] The present application provides a server hardware device monitoring system, which decouples the front-end and back-end clusters through a message broker service cluster. When the front-end and back-end clusters transmit data, they do not need to specify the peer software network descriptor. Under the management of the message broker service cluster, they are invisible to each other and only responsible for sending messages to the message broker service cluster and receiving messages from the message broker service cluster. Whether the front-end software or the back-end software is modified, the peer does not need to be modified. Since the message broker service cluster uses an asynchronous transmission mechanism to receive and forward messages from the front-end and back-end clusters, the front-end and back-end clusters can immediately exit after sending the messages and then execute other services without blocking and waiting for the message transmission to complete. This asynchronous data transmission method enables high data processing and transmission performance for the front-end and back-end software. The present application also provides a server system, which has the same beneficial effects as the above-mentioned server hardware device monitoring system. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] To more clearly illustrate the embodiments of the present application, the accompanying drawings required for use in the embodiments will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can be obtained based on these drawings.

[0025] Figure 1 The structural schematic diagram of a server hardware device monitoring system provided by the present application;

[0026] Figure 2 The schematic diagram of a queue definition and interaction process provided by the present application;

[0027] Figure 3 The schematic diagram of the principle of a publish-subscribe mode provided by the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] The core of the present application is to provide a server hardware device monitoring system and a server system, which can decouple the front-end and back-end clusters and improve the data processing efficiency and transmission performance.

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0030] Please refer to Figure 1 , Figure 1Schematic diagram of the structure of a server hardware device monitoring system provided by this application. The server hardware device monitoring system includes: a foreground prompt device cluster 1, a message broker service cluster 2, and a background monitoring service cluster 3. The message broker service cluster 2 includes multiple containers, and each container includes a publisher queue and a subscriber queue, where:

[0031] The message broker service cluster 2 is used to obtain messages sent by the foreground prompt device cluster 1 or the background monitoring service cluster 3 through the publisher queue, determine the subscribers who subscribe to the messages in the subscriber queue, and send the messages to the target management program 31 in the background monitoring cluster corresponding to each subscriber or the foreground prompt module in the foreground prompt device cluster 1.

[0032] Specifically, the server hardware device monitoring system provided in this embodiment includes a foreground prompt device cluster 1, a message broker service cluster 2, and a background monitoring service cluster 3. The foreground prompt device cluster 1 includes a command request sending module 11, a prompt command response module 12, a prompt device status module 13, and a prompt message recording module 14. The above-mentioned prompt command response module 12, prompt device status module 13, and prompt message recording module 14 are all foreground prompt modules in this embodiment.

[0033] Specifically, the message broker service cluster 2 includes multiple pre-created containers, and each container corresponds to a message type. Correspondingly, the multiple created containers include, but are not limited to, a command request container 21, a command response container 22, and a status reporting container 23.

[0034] Specifically, the background monitoring service cluster 3 includes a user space and a memory space. The user space includes a management program 31, and there is a corresponding relationship between the management program 31 and the subscribers. The background monitoring service cluster 3 may include multiple management programs 31. Each management program 31 includes a command receiving module 311, a command response module 312, a status polling module 313, and an event processing module 314. The kernel space includes a virtual file system 32 and a character device driver 33. The character device driver 33 includes a command processing module 331, a polling instruction processing 332, and a hardware interrupt processing module 333. The background monitoring service cluster 3 is connected to the server hardware device, writes configuration information to the execution configuration module in the server hardware device, polls the status control register in the server hardware device, and is also used to receive interrupt instructions sent by the interrupt control module. Among them, a character device refers to a device that can only read one byte of memory data in the order of the data stream at a time and cannot randomly read the data in the device memory. Common character devices include keyboards, mice, GPIO, shell consoles, etc. The virtual file system 32 is a general file system interface abstracted by the operating system kernel for all types of file systems. File system manufacturers only need to implement the underlying file system interface to facilitate users to write application programs in a portable manner.

[0035] Specifically, each container includes a publisher queue and a subscriber queue, and all queues are stored in the container in the form of key (message type) - value (queue set) pairs. It can be understood that a queue is a first - in - first - out data storage structure. The data that enters the queue first will be taken out first, and it is mostly used in the producer - consumer scenario. The producer continuously pushes data, and the consumer continuously extracts data in the push order. A key - value pair is a data storage structure based on a hash table, similar to a dictionary. Each data has a unique key - value, and the location of the data in memory can be quickly queried through the key - value. The queue definition and interaction process refer to Figure 2 As shown, each publisher queue and subscriber queue is a set of network descriptors, representing one or more network connections. One end of the network connection is the queue management process 24 on the message proxy service cluster 2 as the network transmission server - side, and the other end is the software module on the front - end and back - end monitoring devices as the network transmission client - side. The message proxy service cluster 2 receives messages from all network entities represented by the publisher queue in a polling manner. When any message is received, it will traverse the subscriber queue, and thus forward the message to all network entities represented by the subscriber queue.

[0036] Refer to Figure 3 As shown, Figure 3 This is a schematic diagram of the principle of a publish - subscribe mode provided by this application. The front - end prompt module and the back - end monitoring module can both act as publishers. Similarly, the front - end prompt module and the back - end monitoring module can also both act as subscribers. Specifically, when the front - end prompt module acts as a publisher, the back - end monitoring module can be regarded as a subscriber; when the back - end monitoring module acts as a publisher, the front - end prompt module can be regarded as a subscriber. Specifically, the message sent by the publisher will be correspondingly sent to the queue corresponding to the message type in the message proxy module, and the message will be forwarded to all subscribers who have subscribed to the message of this type. For example, when the front - end prompt module needs to modify the device parameters, it sends a command request message as a publisher. This command request message is forwarded by the message proxy module to the back - end monitoring module that has subscribed to this message. The back - end monitoring module modifies the device configuration and sends the configuration result (i.e., the response message) and the device status information that needs to be actively reported as a publisher through the message proxy module to the front - end prompt module that has subscribed to the response message and the status report information.

[0037] It can be understood that the polling instruction processing 332 in the background monitoring service cluster 3 is used to poll the hardware device register after receiving a polling instruction to obtain device status information and copy the device status information to the status polling module 313; the status polling module 313 in the background monitoring service cluster 3 is used to send the abnormal status information to the publisher queue of the status reporting container 23 when detecting abnormal status information in the device status information. The hardware interrupt processing module 333 in the background monitoring service cluster 3 is used to obtain abnormal status information when receiving an interrupt instruction and report the abnormal status information to the event processing module 314; the event processing module 314 in the background monitoring service cluster 3 is used to send the abnormal status information to the publisher queue of the status reporting container 23.

[0038] The following refers to Figure 1 and will elaborate on the server hardware device monitoring system provided in this embodiment in detail:

[0039] When a user needs to modify the hardware device parameters, the sending command request module 11 in the foreground prompt device cluster 1 sends a message to the publisher queue in the command request container 21 in the message broker service cluster 2. The message content includes device configuration information. The message broker service cluster 2 forwards the command request message to the corresponding management program 31 in the background monitoring service cluster 3 that subscribes to the message of this command request message type. The background monitoring service cluster 3 receives the command request message including device configuration information through the command receiving module 311 in the management program 31 in the user space, and then forwards the command request message to the kernel character device driver 33 interface through the file operation interface provided by the kernel virtual file system 32. The kernel character device driver 33 interface calls the command processing module 331 to write the device configuration information into the hardware device register, and then returns a command sending completion message to the command response module 312 in the user space. The command response module 312 sends the command sending completion message to the command response container 22 of the message broker service cluster 2. The message broker service cluster 2 forwards the command completion message to the foreground prompt device that subscribes to the message of this command response message type, and the foreground prompt device prompts the command completion message to the user interface.

[0040] Specifically, during operation, the hardware device exposes its device status information to the kernel character device driver 33 in the form of a status control register. The status polling module 313 in the user space of the background monitoring service cluster 3 continuously sends polling instructions to the kernel character device driver 33 through the file operation interface of the kernel virtual file system 32 to invoke the kernel space polling instruction processing 332. The polling instruction processing 332 obtains the device status information by reading and writing the hardware device status register and copies it into the buffer of the status polling module 313 in the user space. When the status polling module 313 in the user space of the background monitoring service cluster 3 detects an abnormal device status, it sends the abnormal status information to the publisher queue of the status reporting container 23 of the message broker service cluster 2. The message broker service cluster 2 forwards the abnormal status message to the foreground prompt device that subscribes to the message of this message type of status reporting, and then the foreground prompt device prompts the abnormal status information to the user interface. Of course, the background monitoring service cluster 3 can also configure the hardware interrupt mechanism to enable the hardware device to actively notify the character device driver 33 to take away the abnormal status information of the device.

[0041] It can be seen that in this embodiment, the coupling between the front-end and back-end clusters is removed through the message broker service cluster. When the front-end and back-end clusters transmit data, they do not need to specify the peer software network descriptor. Under the management of the message broker service cluster, they are invisible to each other. Each only needs to be responsible for sending messages to the message broker service cluster and then receiving messages from the message broker service cluster. Whether the front-end software or the back-end software is modified, the peer does not need to be modified. Since the message broker service cluster uses an asynchronous transmission mechanism to receive and forward messages from the front-end and back-end clusters, the front-end and back-end clusters can immediately exit after sending the messages and then execute other services, without blocking and waiting for the message transmission to complete. This asynchronous data transmission method enables the data processing and transmission performance of the front-end and back-end software to be relatively high.

[0042] Based on the above embodiment:

[0043] As an optional embodiment, each container further includes a recorder queue, and the message broker service cluster 2 further includes:

[0044] A queue management process 24, configured to store the message data stream information of each container into the recorder queue of the container.

[0045] As an optional embodiment, the server hardware device monitoring system further includes a database;

[0046] The queue management process 24 is further configured to store the message data stream information in each recorder queue into the database according to a preset storage rule.

[0047] As an optional embodiment, storing the message data stream information in each recorder queue into the database according to a preset storage rule:

[0048] When message data stream information is written into the recorder queue, the message data stream information is stored in the database.

[0049] Specifically, the message broker service cluster 2 further includes a queue management process 24. The queue management process 24 continuously monitors the published and subscribed messages, stores the message data stream information in the message record queue, and then persists the message record queue into the database. There are various storage rules for storing the data in the message record queue into the database. It can adopt the method of storing immediately upon entry, or the method of storing after filling up. This embodiment does not make specific limitations in this regard. Among them, data persistence is a data storage model that can convert in-memory object data into metadata in non-volatile media, or vice versa, convert metadata in non-volatile media into in-memory object data. When a user needs to obtain message records, the persisted message record queue is read from the database of the message broker service cluster 2, and then the message data stream information is read one by one from the message record queue.

[0050] In summary, by adopting the solution of this application, the coupling between the front-end and back-end software of the monitoring system is removed. When the front-end and back-end software transfer data, they do not need to specify the peer software network descriptor. Under the management of the message broker service cluster 2, they are invisible to each other. Each is only responsible for sending messages to the publisher queue and receiving messages from the subscriber queue. No matter which party's software is modified, the peer software does not need to be modified. This solution also has strong software customization. When modifying the monitoring data type, it only needs to cancel the subscription from the front-end software or cancel the publication of a certain message from the back-end software. When modifying the data transmission method, it only needs to modify the message broker service cluster 2. The data transmission method is invisible to the front-end and back-end software. In addition, multiple publishers and subscribers can be flexibly configured and deployed on different computing platforms. Since the message broker service cluster 2 uses an asynchronous transmission mechanism to receive and forward messages from the front-end and back-end software, the front-end and back-end software can immediately exit after sending the messages and then execute other services, without blocking and waiting for the message transmission to complete. This asynchronous data transmission method enables the data processing and transmission performance of the front-end and back-end software to be relatively high. In addition, the existence of the message record queue also facilitates users to trace message records in the later stage. Users do not need to check the device running status in real time. They only need to, when an anomaly is found, according to the anomaly message ID, persist the message record queue from the database of the message broker service cluster 2, and further extract and analyze the detailed device anomaly status log information from the message record queue.

[0051] On the other hand, this application also provides a server system, including the server hardware device monitoring system as described in any one of the above.

[0052] For the introduction of a server system provided by this application, please refer to the above embodiments, and this application will not elaborate here.

[0053] A server system provided by this application has the same beneficial effects as the above-mentioned server hardware device monitoring system.

[0054] It should also be noted that in this specification, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0055] The above description of the disclosed embodiments enables those skilled in the art to implement or use this application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application will not be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A server hardware device monitoring system, characterized in that, Including: A front - end prompt device cluster, a message broker service cluster, and a back - end monitoring service cluster. The message broker service cluster includes multiple containers, and each container includes a publisher queue and a subscriber queue, where: The message broker service cluster is used to obtain messages sent by the front - end prompt device cluster or the back - end monitoring service cluster through the publisher queue, determine subscribers who subscribe to the messages in the subscriber queue, and send the messages to the target management program in the back - end monitoring cluster corresponding to each subscriber or the front - end prompt module in the front - end prompt device cluster; The back - end monitoring cluster includes a user space and a memory space. The user space includes a management program, and there is a corresponding relationship between the management program and the subscriber. The back - end monitoring service cluster includes multiple management programs, and each management program includes a command receiving module, a command response module, a status polling module, and an event processing module. The kernel space includes a virtual file system and a character device driver. The character device driver includes a command processing module, a polling instruction processing module, and a hardware interrupt processing module. The back - end monitoring service cluster is connected to the server hardware device, used to write configuration information to the execution configuration module in the server hardware device, used to poll the status control register in the server hardware device, and also used to receive interrupt instructions sent by the interrupt control module; where a character device refers to a device that can only read one - byte memory data in the order of the data stream and cannot randomly read the data in the device memory; The message broker service cluster uses an asynchronous transmission mechanism to receive and forward messages from the front - end and back - end software. After the front - end and back - end software send the messages, they can immediately exit and then execute other services.

2. The server hardware device monitoring system according to claim 1, wherein Each of the containers corresponds to a message type.

3. The server hardware device monitoring system according to claim 2, characterized in that, The multiple containers include a command request container, a command response container, and a status reporting container.

4. The server hardware device monitoring system according to claim 3, wherein The polling instruction processing module is used to poll the hardware device register after receiving a polling instruction to obtain device status information and copy the device status information to the status polling module; The status polling module is used to send the abnormal status information to the publisher queue of the status reporting container when it detects abnormal status information in the device status information.

5. The server hardware device monitoring system according to claim 3, wherein The back - end monitoring service cluster further includes: The hardware interrupt processing module is used to obtain abnormal status information when it gets an interrupt instruction and report the abnormal status information to the event processing module; The event processing module is used to send the abnormal status information to the publisher queue of the status reporting container.

6. The server hardware device monitoring system according to claim 1, characterized in that, Each of the containers further includes a recorder queue, and the message broker service cluster further includes: A queue management process for storing the message data stream information of each container into the recorder queue of the container.

7. The server hardware device monitoring system according to claim 6, characterized in that, This server hardware device monitoring system further includes a database; The queue management process is further used to store the message data stream information in each recorder queue into the database according to a preset storage rule.

8. The server hardware device monitoring system according to claim 7, wherein, Storing the message data stream information in each recorder queue into the database according to a preset storage rule: When the message data stream information is written into the recorder queue, the message data stream information is stored in the database.

9. A server system, characterized in that, Including the server hardware device monitoring system according to any one of claims 1-8.

Images