Method for acquiring and dynamically displaying hardware configuration information based on graphical user interface

Abstract

The application relates to a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, which comprises the following steps: in response to a hardware information query request initiated by a user on a GUI interface, generating and scheduling a task queue, calling an MCS system interface by using a CLI command to acquire hardware configuration data, and generating a log event in an execution process; an event management module receives a hardware state change notification sent by the MCS system through Socket communication, generates an alarm event and adds the alarm event to an event queue when detecting an exception; a front-end module acquires event data through a polling interface, a GUI interface dynamically updates display content according to the event data, and the hardware running state and abnormal information are intuitively displayed by using color coding and a dynamic chart. The application can be applied to scenes such as servers and electronic devices, and can improve the real-time performance, visual degree and user interaction experience of hardware state monitoring.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer system management and graphical user interface, and particularly relates to a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface. BACKGROUND

[0002] As an important interactive means of computer system management, the graphical user interface (GUI) is widely used in the field of hardware state monitoring and system maintenance. With the exponential growth of computer hardware complexity, users' demand for the visualization, real-time and intelligent presentation of system configuration information is increasing. In related technologies, a basic hardware information acquisition and display system is constructed through the collaborative work of command line interface (CLI), remote procedure call (RPC) and multi-controller system (MCS). Specifically, this technology covers the whole process from hardware data acquisition, information processing to graphical feedback, including key links such as operating system level API call, cross-platform development framework, task scheduling mechanism and event listening system. Among them, the MCS system as the core platform of storage and control, undertakes important functions such as hardware state query, abnormality detection and data encapsulation, and provides a basic support for system maintenance and fault diagnosis.

[0003] However, in the existing hardware information acquisition and display method, the unified output or static display method is directly used, and the information is not processed in layers and dynamically fed back, which may cause problems such as information overload, interaction fragmentation and maintenance difficulty. Specifically, some tools do not display professional parameters in stages, which makes it difficult for ordinary users to quickly identify key information and requires secondary screening; hardware information is scattered in multiple subsystems, lacking a unified integration mechanism, affecting the intuitiveness and readability of information; at the same time, traditional methods rely on professional knowledge accumulation in hardware abnormality positioning, which is difficult to achieve rapid response and accurate judgment, thereby affecting system maintenance efficiency and operation and maintenance cost control. SUMMARY

[0004] The present application aims to at least solve one of the technical problems in the related art to some extent.

[0005] To this end, the first purpose of the present application is to propose a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, which aims to solve the problems of complex hardware information acquisition method, non-intuitive display and low maintenance efficiency in the prior art, and to realize efficient acquisition, dynamic update and visual feedback of hardware configuration information by constructing a collaborative mechanism of unified GUI interface and backend data processing module.

[0006] The second purpose of the present application is to propose a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface.

[0007] A third object of the present application is to provide an electronic device.

[0008] A fourth object of the present application is to provide a computer-readable storage medium.

[0009] A fifth object of the present application is to provide a computer program product.

[0010] To achieve the above objects, the first aspect of the present application provides a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, comprising:

[0011] In response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to a task queue of a task management module, and the task management module determines whether to sequentially execute the task in the queue according to a task dependency relationship;

[0012] When the task is in an execution state, hardware configuration data is acquired through a CLI command to call an MCS system interface, and a log event is generated during execution;

[0013] The log event is sent to an event management module, and the event management module establishes a connection with an MCS system server through Socket communication and receives a hardware state change notification sent by the MCS system;

[0014] If a hardware exception is detected, the event management module encapsulates exception information as an alarm event and adds the alarm event to an event queue, and a front-end module requests event data from the event management module through a polling interface at a preset time interval;

[0015] Based on the event data, a GUI interface module dynamically updates display content according to a hardware state and displays a hardware running state and exception information through color coding and a dynamic chart, wherein red represents component failure, black represents component absence, and yellow represents a warning state.

[0016] Optionally, the query task includes a query type task and a subscription type task, wherein:

[0017] The query type task is triggered by a user to acquire current hardware configuration information;

[0018] The subscription type task is triggered by a background timer to continuously acquire hardware state change information.

[0019] Optionally, the task management module divides tasks into queue execution tasks and non-queue execution tasks according to execution order of the tasks, wherein:

[0020] The queue execution task is used to execute CLI commands with a dependency relationship;

[0021] Non-queue execution tasks are used to execute CLI commands without dependencies and can be executed immediately.

[0022] Optionally, the event management module adopts a publish-subscribe mode to receive event notifications from the MCS system and generate corresponding alarm events according to the event type; the notification type sent by the MCS system to the event management module is one or more of Notification, Bellwether, Resy; Flush_ack, and the notification type sent by the event management module to the MCS system is one or more of Subscribe, Unsubscribe, and Flush.

[0023] Optionally, the GUI interface module adopts a layered information architecture, including a basic layer and an expert layer, wherein:

[0024] The base layer is used to display the core parameters of the hardware, including CPU, memory, and storage;

[0025] The expert layer displays advanced hardware status information through a folding menu, including hard disk SMART status, GPU temperature, and fan speed.

[0026] To achieve the above-mentioned purpose, the second embodiment of the present application proposes a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, comprising:

[0027] GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status;

[0028] A task management module, connected to the GUI interface module, is used to receive the query request and generate a query task, add the task to the task queue, and control the execution order of the tasks according to the task dependency relationship;

[0029] A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process;

[0030] An event management module, connected to the CLI execution module and the MCS system interface, is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to the event queue;

[0031] An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module;

[0032] The GUI interface module dynamically updates the display content based on the event data, and shows the hardware running state and abnormal information through color coding and dynamic charts, wherein red represents component failure, black represents component absence, and yellow represents a warning state.

[0033] Optionally, the GUI interface module supports visual display of dynamic charts and color coding, wherein:

[0034] The dynamic charts are used to show the usage rate of hardware resources.

[0035] The color coding is used to identify the hardware state, wherein red represents component failure, black represents component absence, and yellow represents a warning state.

[0036] To achieve the above purpose, a third aspect of the present application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication;

[0037] The memory stores computer execution instructions.

[0038] The processor executes the computer execution instructions stored in the memory to implement the method according to any one of the first aspect.

[0039] To achieve the above purpose, a fourth aspect of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method according to any one of the first aspect.

[0040] To achieve the above purpose, a fifth aspect of the present application provides a computer program product, wherein the computer program is executed by a processor to implement the method according to any one of the first aspect.

[0041] The technical scheme provided by the embodiments of the present application at least brings the following beneficial effects:

[0042] 1. Reduce the user threshold: replace the traditional command line tool (CLI) with a graphical user interface (GUI), so that non-professionals can also quickly master the system hardware state, and improve the ease of use of the system;

[0043] 2. Improve maintenance efficiency: through real-time monitoring of hardware parameter changes, combined with an event-driven mechanism, dynamic feedback of hardware state is realized, which helps operators to discover and handle exceptions in time;

[0044] 3. Enhance information integration capability: unify the hardware information of multiple platforms and third-party tools to avoid information fragmentation and improve information acquisition efficiency;

[0045] 4. Improve anomaly identification efficiency: By combining dynamic charts with color coding, users can identify hardware anomalies more than 40% faster and reduce the rate of false positives.

[0046] 5. Optimize the task execution process: through the task queue and execution monitoring mechanism, ensure the orderliness of task execution and the timeliness of exception handling, reduce task conflicts and improve system stability;

[0047] 6. Enhance system scalability and compatibility: Through decoupled design and provider configuration mechanism, it supports flexible expansion and adapts to different platforms and hardware environments;

[0048] 7. Improve product competitiveness: Graphical, real-time, and intelligent hardware monitoring systems can significantly improve product user experience and enhance market competitiveness.

[0049] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0051] Figure 1 A flowchart of a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface provided in an embodiment of the present application;

[0052] Figure 2 A schematic diagram of the backend data service provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0054] Figure 1 This is a flow chart of a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface provided in an embodiment of the present application. Figure 1 As shown, the method includes the following steps:

[0055] Step S1, in response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to the task queue of the task management module, and the task management module determines whether to execute the tasks sequentially in the queue according to the task dependency relationship.

[0056] In the embodiments of the present application, when a user initiates a hardware information query request in a graphical user interface (GUI), the system responds to the request and generates a corresponding query task. The query task is added to a task queue maintained by a task management module. The task management module dynamically determines whether to sequentially execute the tasks in the task queue according to the dependency relationship between the tasks.

[0057] Specifically, at system startup, a graphical user interface module is built by using a cross-platform development framework such as Electron or Qt. The interface adopts a layered architecture design, including a basic layer and an expert layer: the basic layer displays default core hardware parameters such as CPU model, memory capacity, storage device type, and the like; and the expert layer provides more detailed advanced hardware parameters such as hard disk SMART state, GPU temperature curve, and the like in the form of a folding menu. The graphical interface is designed with reference to the tree structure of the mcs "system report" to improve the information retrieval efficiency and interface consistency of the user and enhance the cross-platform adaptation capability of the system.

[0058] In terms of interaction between the front end and the back end, two types of communication are defined in the embodiments of the present application:

[0059] (1) RPC protocol-based request, used for regular polling, for example, the rpc.polling.poll request type is commonly used for event subscription or state update;

[0060] (2) Non-RPC protocol ordinary Servlet request, for example, the request used for the query operation of memory information will point to the Servlet interface such as MEMGridDataHandler, and the corresponding Java class in the back end is responsible for data processing.

[0061] In terms of task type, query tasks are divided into query type tasks and subscription type tasks. The query type task is triggered by the user to obtain the current hardware configuration information. The subscription type task is triggered periodically by the system background to monitor the dynamic changes of the hardware state, so that the system can respond to changes in time and provide updated information.

[0062] The task management module further divides the tasks into queue execution tasks and non-queue execution tasks according to the execution order requirements of the tasks:

[0063] The queue execution task is used for commands with dependency relationship, such as the "CPU information" command needs to be executed first, and then the "heat dissipation state" information can be obtained. Such tasks must be executed in sequence after the dependency conditions are met;

[0064] The non-queue execution task is suitable for independent CLI commands without dependency relationship, which can be executed instantly and concurrently to improve the overall execution efficiency.

[0065] like Figure 2 As shown, this application also sets up a unified task manager. The task manager's responsibility is to receive all task commands from the front end, including operations such as device creation, modification, and deletion, and convert these operations into CLI tasks. All tasks will be added to the task queue to be executed. The execution of tasks follows the queue rules: execute one by one from the head of the queue, only one task is taken at a time and marked as "executing", and the remaining tasks in the queue remain in the "pending" state. The system also updates the number of tasks waiting to be executed corresponding to each task to ensure the traceability of execution.

[0066] When a task is executed, the system generates event information and adds it to the event list. Furthermore, during CLI command execution, the system monitors command output and pushes any events generated during the process to the event list in real time. The frontend obtains real-time task execution feedback from the event list through regular RPC requests, enabling visual and responsive management of task execution.

[0067] After the task is completed, the system automatically takes the next task from the head of the queue and continues to execute it until all tasks are processed.

[0068] Step S2: When the task is in execution, the MCS system interface is called through the CLI command to obtain hardware configuration data, and log events are generated during the execution process.

[0069] In another embodiment of the present application, the above-mentioned task generation and scheduling process is continued. When the task is in the "executing" state, the system will automatically call the MCS system interface through the CLI (command line interface) command to obtain the required hardware configuration information, and generate log events in real time during the entire execution process for subsequent tracking and front-end interface display.

[0070] In the embodiments of this application, the command manager, as a key component, is primarily responsible for organizing, scheduling, and executing commands. The command manager not only initiates and issues commands but also implements a listener for the command execution process. This listener monitors the command execution status in real time, including key information such as whether the command is executed correctly and whether any exceptions are thrown. If an exception occurs during command execution, the listener will immediately record and report it, generating a corresponding error event to ensure the system has a good fault-tolerant mechanism.

[0071] In terms of the execution mechanism of commands, commands can be divided into two categories according to their dependencies:

[0072] (1) Commands that require queue execution: These commands have execution order dependencies. For example, some commands involving task configuration or hardware initialization require that a specific command be completed before the next command can be executed. In this case, the command manager places these commands in the task queue and executes them strictly in the queue order to avoid execution failures due to unsatisfied dependencies.

[0073] (2) Commands that do not require queue execution: These commands have no upstream or downstream dependencies and can be triggered immediately. For example, a single status read or log query command does not depend on other results and can be directly dispatched and executed by the system without waiting in a queue, thus improving system response efficiency.

[0074] In this embodiment, a key mechanism for ensuring system stability is also designed: the MCS memory anomaly file monitoring mechanism. The system continuously monitors a specific path in the MCS layer to see if a diagnostic file caused by memory anomalies is generated. If the file is detected, it can be preliminarily determined that the MCS has a potential memory anomaly issue.

[0075] Furthermore, the system dynamically monitors changes to the file's content: if the file continues to grow, the anomaly is still occurring. Once the file size stops changing within a certain period, indicating that the abnormal data has been written, the system immediately terminates the current application to prevent further damage or the spread of the anomaly. This mechanism ensures that the system can promptly stop losses and trigger fault recovery processes when memory anomalies occur, providing underlying security for stable system operation.

[0076] In summary, the embodiment of the present application constructs a hardware information query and processing system with real-time monitoring, sequence control and abnormal self-handling capabilities through the collaborative design of CLI command scheduling MCS interface, command monitoring mechanism, and abnormal file monitoring mechanism.

[0077] Step S3: Send the log event to the event management module. The event management module establishes a connection with the MCS system server through Socket communication and receives the hardware status change notification sent by the MCS system.

[0078] In the further steps of the embodiment of the present application, step S3 involves the design and implementation of an event processing mechanism. When a log event is generated during the execution of a CLI command, the system will send the log event to the event management module to implement the unified reception, processing and reporting functions of the event.

[0079] The event management module, one of the core components in this application's implementation, is responsible for maintaining a communication connection with the MCS system and for real-time sensing and processing of hardware status change events. The event management module primarily consists of two subcomponents: the event manager and the event list manager, which together form an efficient event distribution mechanism based on socket communication and a publish-subscribe model.

[0080] In terms of communication mechanism, the event manager establishes a persistent connection with the Socket server in the MCS system through the Socket client, and continuously listens for data change messages sent by the MCS system. The MCS system can send various types of notification information to the event management module, including but not limited to:

[0081] Notification: used to indicate regular state change events;

[0082] Bellwether: used to identify key events or indicator changes;

[0083] Resy: indicates the system response status at the resource level;

[0084] Flush_ack: used to confirm that the previous flush operation has been completed.

[0085] After receiving the above notification, the event manager will parse and classify the event according to the event type and generate the corresponding structured event object. At the same time, the event manager also has the ability to send control instructions and can actively send the following types of instructions to the MCS system to implement subscription control:

[0086] Subscribe: subscribe to a certain type of event;

[0087] Unsubscribe: cancel subscription;

[0088] Flush: flushes the event queue and requests the latest status.

[0089] During event reception and processing, the Event List Manager handles event caching and scheduling. This module integrates the PollingManager, which receives event information submitted by various business modules and stores it in a centralized queue structure. When the frontend requests events through RPC, the PollingManager filters and returns the corresponding event set based on the provider information in the request.

[0090] To further improve the flexibility and scalability of event processing, this application uses a decoupled publish-subscribe model to process events. This model supports the derivation and aggregation of original events. For example, when executing a "query memory" operation, the system automatically generates a corresponding "query memory" event and a "query information deletion" event to assist the front-end in updating page status or releasing resources.

[0091] Furthermore, to satisfy event subscription requests from the frontend through the rpc.polling.xxx interfaces, the system completes the registration and configuration of various providers during application initialization. Each provider defines the processing logic and subscription rules for specific event types, ensuring that the frontend can efficiently obtain relevant status updates.

[0092] To sum up, this application realizes an efficient event interaction and status notification system with the MCS system by setting up an event manager and an event list manager, and combining the Socket communication mechanism and the publish-subscribe model. While ensuring the system's asynchronous processing capabilities, it enhances the real-time and scalability of event response.

[0093] In step S4, if a hardware anomaly is detected, the event management module encapsulates the anomaly information as an alarm event and adds the alarm event to the event queue. The front-end module requests event data from the event management module at preset time intervals through the polling interface.

[0094] In an embodiment of the present application, further, in step S4, if the event management module detects that the event from the MCS system contains hardware abnormality information, the system will trigger an alarm mechanism and encapsulate and process the abnormal event.

[0095] Specifically, the event management module first parses and categorizes the received raw abnormal events to identify whether they represent abnormal conditions, such as device failure, overtemperature, voltage abnormality, or abnormal SMART status of a storage device. Once the event is confirmed to be a hardware abnormality, the event management module encapsulates it into a standard alarm format.

[0096] The alarm event not only retains the original abnormal information, but also adds fields such as the event occurrence time, associated hardware identification, alarm level (such as serious, warning, information) and predefined recommended processing actions, thereby enhancing the readability and operability of the event.

[0097] The event management module then adds the encapsulated alarm event to the event queue, which the front-end module can then retrieve and display. The event queue is centrally managed by the event list manager and features a first-in-first-out (FIFO) mechanism, ensuring that events are pushed in chronological order to avoid information delays or overwriting.

[0098] To ensure real-time front-end awareness of system anomalies, this embodiment of the present application utilizes a polling mechanism as a front-end / back-end communication method. The front-end module invokes a polling interface (e.g., rpc.polling.xxx) to periodically request the latest event data from the event management module at preset intervals (e.g., every 5 seconds or every 10 seconds). When a polling request reaches the event management module, the system filters the event queue for events not yet delivered to the front-end and returns them in order.

[0099] Through the above mechanism, the system can achieve timely reporting and front-end prompts of hardware anomalies without introducing a complex push architecture, thereby greatly improving the overall system's abnormal response capabilities and user visualization experience.

[0100] The alarm event mechanism, event queue cache and polling front-end pull method in the embodiments of this application jointly construct a low-coupling, highly controllable system exception handling path, which can flexibly adapt to the exception handling strategies of different business modules and provide basic support for subsequent alarm linkage, log auditing and system recovery.

[0101] In step S5, based on the event data, the GUI interface module dynamically updates the display content according to the hardware status, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

[0102] In step S5 of the present embodiment, the system dynamically displays and updates the hardware status in real time using the GUI module based on the event data provided by the event management module. This process not only enables the visualization of hardware information but also enhances the efficiency of identifying abnormal conditions and the user interaction experience through color coding and dynamic charts.

[0103] Specifically, upon receiving the latest event data from the event queue, the GUI module determines the status of the corresponding hardware component based on the event content and dynamically adjusts the displayed content within the interface. For hardware modules with changing status, such as the CPU, memory, disk, and GPU, the interface will refresh their status indicators in real time and trigger corresponding visual displays based on the current status.

[0104] In order to improve the efficiency of anomaly identification, the embodiment of the present application adopts a combination of a color coding mechanism and a dynamic chart component to achieve enhanced visualization of the status.

[0105] Color coding mechanism: Red indicates serious anomalies or component failures, such as CPU overheating, GPU failure, or storage device read failure; black indicates missing or unrecognizable hardware components, such as a motherboard without a certain device installed; yellow indicates an alarm state, such as a hard drive SMART parameter exceeding the warning threshold or abnormal power supply voltage fluctuations but not reaching the critical failure value;

[0106] At the same time, the temperature information is also dynamically judged using the temperature threshold. For example, when the temperature exceeds 80°C, it is marked as red.

[0107] The system introduces a circular progress bar chart component (similar to the disk utilization display in Windows Task Manager), replacing the traditional numeric percentage text display. This chart displays information such as hardware utilization and load level in a circular format, and uses color coding to more intuitively and quickly convey current status changes. User testing data shows that compared to traditional numeric percentage displays, the circular progress chart can improve anomaly identification speed by approximately 40%, especially when multiple indicators are displayed side by side.

[0108] In addition, the GUI interface module supports dynamic refresh and a hierarchical display mechanism. The basic layer displays core indicators, while the expert layer provides more granular status data analysis through graphical components (such as heat maps, curve graphs, and bar charts), facilitating fault diagnosis and performance evaluation by professionals.

[0109] Through the above mechanism, the embodiments of this application significantly enhance the system's ability to visualize hardware status, achieving full-link closed-loop control from data reception and status recognition to visual output. Users can directly grasp the system's operating status and potential fault points through a graphical interface without having to access the command line or backend, greatly enhancing the system's usability and fault response efficiency.

[0110] In summary, the present embodiment provides a unified task management mechanism applicable to both query and subscription tasks. By fine-tuning the execution paths, event generation, and front-end and back-end communication of these two types of tasks, the system can achieve both active query and passive monitoring of hardware status information.

[0111] Specifically: For query tasks, they are mainly used for hardware status query behaviors actively initiated in the user interface component. For example, when a user clicks a button on the front-end page to obtain the memory status, the system will trigger the following process: the page component executes the query action; the component sends a query URL request to the back-end, such as rpc.query.memory; the system generates the corresponding query task; the query task is added to the task queue in the task manager, waiting for execution; during the task execution process, the underlying MCS platform interface is called through the CLI command to obtain hardware information, and the system generates corresponding log information; the generated log information is encapsulated as a log event and added to the event list; the front-end module initiates a request to the event management module through the rpc.polling.poll interface at an interval of 1.5 seconds, pulls the latest log event from the event list, and realizes real-time visual feedback of the task execution process.

[0112] The execution path of subscription tasks is structurally similar to query tasks, but their triggering mechanism is different. These tasks are not directly triggered by user actions but are initiated periodically by the system backend. They are often used to continuously monitor hardware operating status. The specific process is as follows: the page component initiates a subscription topic; a query URL request (e.g., rpc.query.memory) is sent to the backend; the system generates the corresponding subscription task; the task is added to the task manager and awaits execution according to the scheduled order; during task execution, the system calls CLI commands to access the underlying data interface of the MCS platform to obtain key information such as memory frequency and in-place status; the log information generated during execution is encapsulated as log events and added to the event list; the frontend uses the polling mechanism rpc.polling.poll to request task-related event logs every 1.5 seconds; the backend encapsulates the hardware status data obtained by the CLI command and responds to the frontend request component through the corresponding Servlet service; the frontend component updates the page display based on the returned data. If an abnormal state is detected (such as memory not being in place), a color-coded alarm is automatically triggered, such as a red display to alert the user.

[0113] Through the above process, this application realizes the refined control of each key link in the task execution life cycle, including task generation, management, execution, log event generation and display. In particular, combined with a unified polling interface design and event list caching mechanism, the system has good responsiveness and visualization capabilities to hardware status changes. In addition, the underlying hardware data obtained through CLI commands is not only used for front-end display, but also used to trigger the corresponding visual alarm logic, forming an automatic closed-loop control of "data acquisition → anomaly identification → alarm presentation", which greatly improves the system's real-time perception and anomaly response capabilities.

[0114] To implement the above embodiment, the present application also proposes a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface. The device includes:

[0115] GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status;

[0116] A task management module, connected to the GUI interface module, is used to receive the query request and generate a query task, add the task to the task queue, and control the execution order of the tasks according to the task dependency relationship;

[0117] A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process;

[0118] An event management module, connected to the CLI execution module and the MCS system interface, is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to the event queue;

[0119] An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module;

[0120] The GUI interface module dynamically updates the display content based on the event data, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

[0121] Optionally, the GUI interface module supports dynamic charts and color-coded visual displays, wherein:

[0122] Dynamic charts are used to display the utilization of hardware resources;

[0123] Color coding is used to identify hardware status, with red indicating a component failure, black indicating a missing component, and yellow indicating a warning status.

[0124] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0125] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0126] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0127] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0128] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0129] It is important to note that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold beyond these legitimate uses. Furthermore, such collection / sharing should be conducted only after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes the relevant user information before using the feature. Furthermore, any necessary steps must be taken to safeguard and secure access to such personal information and ensure that others with access to personal information comply with its privacy policy and procedures.

[0130] This application contemplates providing implementations that allow users to selectively block the use or access of personal information data. Specifically, this disclosure contemplates providing hardware and / or software to prevent or block access to such personal information data. Risks can be minimized by limiting data collection and deleting data once it is no longer needed. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0131] In the descriptions of the foregoing embodiments, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are mutually inconsistent.

[0132] 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 the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of such features. Throughout the description of this application, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0133] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0134] The logic and / or steps represented in a flowchart or otherwise described herein, for example, can be considered a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" is any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0135] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having logic gate circuits for implementing logical functions on data signals, an application-specific integrated circuit having suitable combinational logic gate circuits, a programmable gate array (PGA), a field-programmable gate array (FPGA), etc.

[0136] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0137] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0138] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application. Persons skilled in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

[0139] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of this application can be achieved. This is not limited herein.

[0140] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, characterized in that: The following steps are involved: In response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to the task queue of the task management module, and the task management module determines whether to execute the tasks sequentially in the queue based on task dependencies, wherein the query tasks include query tasks triggered by the user and subscription tasks triggered by the background timer; When the task is in execution, the MCS system interface is called through CLI commands to obtain hardware configuration data, and log events are generated during the execution process; The log event is sent to the event management module, which includes an event manager and an event list manager. The event manager establishes a long connection with the Socket server in the MCS system through the Socket client and receives the hardware status change notification sent by the MCS system. The event management module adopts a publish-subscribe mode to receive event notifications from the MCS system and generates corresponding alarm events according to the event type. The type of notification information sent by the MCS system to the event management module is one or more of Notification, Bellwether, Resy, and Flush_ack. The Notification is used to indicate a regular status change event, and the Bellwether is used to identify a key event. The event manager receives notifications from the MCS system, parses and classifies them according to the event type, and generates corresponding structured event objects. The event manager sends control instructions to the MCS system to implement subscription control. The instruction type is one or more of Subscribe, Unsubscribe, and Flush. Subscribe means subscribing to a certain type of event, Unsubscribe means canceling the subscription, and Flush means refreshing the event queue and requesting the current latest status. The event list manager receives events submitted by each business module and retains them uniformly in a queue structure. If a hardware anomaly is detected, the event management module encapsulates the anomaly information as an alarm event and adds the alarm event to the event queue. The front-end module requests event data from the event management module at preset time intervals through a polling interface, wherein the event queue has a first-in-first-out mechanism; Based on the event data, the GUI interface module dynamically updates the display content according to the hardware status and displays the hardware operating status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status; The method further comprises: Establish an MCS memory exception file monitoring mechanism to continuously monitor whether a diagnostic file caused by memory exceptions is generated in a specific path in the MCS layer; If the diagnostic file is detected to exist, it is determined that the MCS has a memory anomaly problem; After determining that the MCS has a memory anomaly problem, the content changes of the diagnostic file are dynamically monitored. If the file continues to grow, it is determined that the abnormal state is still occurring. If the file size stops changing within a certain period, it is determined that the abnormal data writing has been completed, and the operation of the current application is terminated immediately.

2. The method according to claim 1, wherein The query task is used to obtain the current hardware configuration information; The subscription task is used to continuously obtain hardware status change information.

3. The method according to claim 1, wherein The task management module divides tasks into queue execution tasks and non-queue execution tasks according to the execution order of tasks, wherein: Queue execution tasks are used to execute CLI commands with dependencies; Non-queue execution tasks are used to execute CLI commands without dependencies and can be executed immediately.

4. The method according to claim 1, wherein The GUI interface module adopts a layered information architecture, including a basic layer and an expert layer, wherein: The base layer is used to display the core parameters of the hardware, including CPU, memory, and storage; The expert layer displays advanced hardware status information through a folding menu, including hard disk SMART status, GPU temperature, and fan speed.

5. A device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, characterized in that: The device implements the method according to claim 1, and the device includes: GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status; A task management module, connected to the GUI interface module, configured to receive the query request and generate a query task, add the task to a task queue, and control the execution order of the tasks based on task dependencies, wherein the query tasks include query tasks triggered by the user and subscription tasks triggered by the background timer; A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process; An event management module is connected to the CLI execution module and establishes a persistent connection with the Socket server in the MCS system through the Socket client. The module is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to an event queue. The event queue has a first-in-first-out mechanism. An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module; The GUI interface module dynamically updates the display content based on the event data and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status; Among them, the event management module adopts a publish-subscribe mode to receive event notifications from the MCS system and generate corresponding alarm events according to the event type; the notification type sent by the MCS system to the event management module is one or more of Notification, Bellwether, Resy, and Flush_ack, the Notification is used to indicate a regular status change event, the Bellwether is used to identify a key event or indicator change, the Resy indicates the system response status at the resource level, and the Flush_ack is used to confirm that the previous refresh operation has been completed. The notification type sent by the event management module to the MCS system is one or more of Subscribe, Unsubscribe, and Flush, the Subscribe indicates subscription to a certain type of event, the Unsubscribe indicates cancellation of subscription, and the Flush indicates refreshing the event queue and requesting the current latest status.

6. The device according to claim 5, characterized in that The GUI interface module supports dynamic charts and color-coded visual displays, where: Dynamic charts are used to display the utilization of hardware resources; Color coding is used to identify hardware status, with red indicating a component failure, black indicating a missing component, and yellow indicating a warning status.

7. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 4.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 4 when executed by a processor.

9. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 4 when executed by a processor.

Images