A device monitoring method, electronic device, storage medium and program product

Abstract

This invention discloses a device monitoring method, electronic device, storage medium, and program product, relating to the field of computer technology. By having a first operating system with a high response rate collect the status information of components in the device's management controller and store it in a first storage area, the real-time nature of the status information collection is ensured. A second operating system is responsible for anomaly monitoring. When an anomaly is detected in a component, it obtains the status information within a target time period from the first storage area to generate anomaly monitoring results. This target time period is the time period corresponding to the anomaly time point of the component and includes at least the time period before the anomaly time point. This ensures that the status information at the time of the anomaly and before is completely preserved and used for anomaly analysis. This solves the problem in related technologies where the lack of continuous recording of component status information leads to the inability to trace the component's status before the anomaly, resulting in difficulty in locating and reproducing transient performance failures of components.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a device monitoring method, electronic device, storage medium, and program product. Background Technology

[0002] With the continuous development of data centers and cloud computing, the requirements for the stability and reliability of servers and other equipment are constantly increasing. During actual operation, equipment often experiences intermittent and short-lived anomalies, such as increased memory access latency or momentary slowdowns in Peripheral Component Interconnect Express (PCIe) links. In related technologies, the equipment's management controller typically monitors the components through its operating system. However, this operating system has limited response times, making it difficult to collect component status information in a timely manner. Furthermore, logs are usually only recorded after an anomaly occurs, leaving component status information before the anomaly is missing, making accurate analysis of the cause of the anomaly impossible. Summary of the Invention

[0003] This invention provides a device monitoring method, electronic device, storage medium, and program product to at least solve the problem in related technologies where the lack of continuous recording of component status information leads to the inability to trace the component status before the anomaly occurs, resulting in difficulty in locating and reproducing transient performance failures of components.

[0004] This invention provides a device monitoring method applied to a device management controller, wherein the management controller includes a first operating system and a second operating system, the first operating system having a higher response rate than the second operating system; the device monitoring method includes: The first operating system collects the status information of the components in the device and stores the status information in the first storage area; The second operating system is used to monitor the components for anomalies. If an anomaly is detected in the component, the second operating system obtains the status information for the target time period stored in the first storage area, and generates an anomaly monitoring result based on the obtained status information. The target time period is the time period corresponding to the abnormal time point of the component, and the target time period includes at least the time period before the abnormal time point.

[0005] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the above-described device monitoring method.

[0006] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described device monitoring method.

[0007] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described device monitoring method.

[0008] This invention addresses the issue of real-time status information acquisition by setting up a first operating system and a second operating system with different response rates in the device's management controller. The first operating system, with its higher response rate, collects the status information of the device's components and stores it in a first storage area. The second operating system is responsible for anomaly monitoring. When an anomaly is detected in a component, it acquires the status information within a target time period from the first storage area to generate anomaly monitoring results. This target time period is the time period corresponding to the anomaly time point of the component, and it includes at least the time period before the anomaly time point. This ensures that the status information at the time of the anomaly and before it is completely preserved and used for anomaly analysis. Therefore, it solves the problem in related technologies where the lack of continuous recording of component status information leads to the inability to trace the component's status before the anomaly, resulting in difficulty in locating and reproducing transient performance faults. This invention achieves the effect of accurately tracing the root cause of the fault without reproducing the fault and improving the accuracy of device anomaly monitoring. Attached Figure Description

[0009] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 An architecture diagram of a device monitoring system provided in an embodiment of the present invention; Figure 2 A flowchart of the first device monitoring method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a ring buffer frame structure and partition layout provided in an embodiment of the present invention; Figure 4 A flowchart of a second device monitoring method provided in an embodiment of the present invention. Detailed Implementation

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

[0012] It should be noted that, in the description of this invention, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] Here, we will first explain some key terms used in the embodiments of the present invention.

[0014] Management Controller: In this embodiment of the invention, the management controller can refer to an out-of-band management controller board, which includes, in addition to the out-of-band monitoring master controller, various bus controllers, programmable logic units, memory, and other components. Alternatively, the management controller in this embodiment can refer to the out-of-band monitoring master controller on the baseboard management controller board, which can be a single-core or multi-core processor. In this embodiment, the out-of-band management controller or the out-of-band monitoring master controller on the out-of-band management controller board can employ an ARM processor, on which the operating system of the out-of-band management controller runs.

[0015] In devices such as servers, the Baseboard Management Controller (BMC) is the core control unit used to implement out-of-band monitoring and management of the hardware of such devices. It operates independently of the host-side business system of the device, and can still function normally even if the host-side operating system crashes. In this embodiment of the invention, the management controller can be a BMC.

[0016] A Real-Time Operating System (RTOS) possesses characteristics such as low scheduling jitter, high real-time response, and lightweight resource consumption, making it suitable for high-precision time-series data acquisition scenarios. In this embodiment of the invention, the first operating system can be an RTOS.

[0017] Linux system: An open-source, multi-tasking general-purpose operating system with a complete service ecosystem and complex business processing capabilities, but it suffers from scheduling jitter due to task scheduling and interrupt preemption. The second operating system in this embodiment of the invention can be a Linux system.

[0018] Inter-Integrated Circuit (I2C): A low-speed serial communication bus widely used on server motherboards for status data exchange of various onboard monitoring devices.

[0019] Platform Environment Control Interface (PECI): A bus interface used for monitoring server hardware temperature and status, capable of monitoring the temperature and status of the Central Processing Unit (CPU) and memory.

[0020] Serial Peripheral Interface (SPI): A high-speed, full-duplex synchronous serial communication bus commonly used for data exchange between controllers and peripherals.

[0021] Peripheral Component Interconnect Express (PCIe): As the core high-speed transmission bus of the server, it carries the data interaction services of various high-speed devices.

[0022] Dual In-line Memory Module (DIMM): The standard memory hardware carrier for servers.

[0023] Power Management Integrated Circuit (PMIC): The fifth-generation Double Data Rate 5 (DDR5) memory module has an onboard dedicated power supply monitoring chip for real-time monitoring of memory power supply voltage, current and transient electrical fluctuations.

[0024] Serial Presence Detect (SPD): The serial presence detection module integrated into the memory module is a passive response storage device that allows the BMC to read basic hardware information such as memory model, parameters, and temperature via I2C. It does not actively report data or collect load status statistics.

[0025] Link Training and Status State Machine (LTSSM): Responsible for PCIe link initialization, state negotiation, link training, and operational state switching. Its state can characterize the operation of the PCIe link.

[0026] Memory-Mapped Input / Output (MMIO): A method of accessing hardware registers through memory address mapping.

[0027] Static Random-Access Memory (SRAM): A low-latency, high-speed read / write memory device that can be integrated into the BMC system-on-chip, i.e., on-chip SRAM.

[0028] A circular buffer is a logically connected circular storage structure that, once full, can continuously overwrite the oldest written data from the beginning, thus retaining the latest data with a fixed storage overhead.

[0029] With the continuous iteration and upgrading of data centers, cloud computing, and high-performance computing services, the requirements for the stability and reliability of server and other equipment hardware are constantly increasing. During actual operation, occasional, transient performance fluctuations that cannot be reproduced in a laboratory often occur, manifesting as increased memory access latency, momentary PCIe link speed reduction, bus bandwidth fluctuations, and abrupt changes in service processing latency. These anomalies are short-lived (often lasting only tens of microseconds to milliseconds), randomly triggered, and without a fixed pattern, and they do not generate clear hardware error logs. Traditional monitoring methods struggle to capture effective anomaly data and accurately locate faults, making this a major challenge for current equipment maintenance and troubleshooting.

[0030] Currently, device hardware performance monitoring mainly relies on management controllers (such as BMCs). The mainstream industry solution is to monitor a single Linux system using a BMC, combined with hardware acquisition on the device host side. However, as a general-purpose multitasking operating system, Linux has problems such as task scheduling, interrupt preemption, and system jitter. The sampling period is usually only at the millisecond level and the period stability is poor. It cannot achieve stable microsecond-level continuous sampling and is difficult to capture instantaneous hardware performance anomalies with a duration of only microseconds or milliseconds.

[0031] In addition, traditional monitoring sampling has a coarse granularity and mainly relies on post-event log recording. That is, logs are only kept after a component generates a clear error, which cannot save the time-series data before the anomaly occurs. The fault tracing data is incomplete and cannot restore the evolution process of the component's state before the anomaly occurs.

[0032] Existing high-precision monitoring solutions in the industry require direct access to core hardware resources on the device host side, such as PCIe configuration space, memory controller registers, performance monitoring unit (PMU), high-speed bus, and MMIO mapping space. This type of data acquisition operation consumes host bus resources, competes for hardware read / write locks, and consumes host CPU computing power. It also creates resource contention conflicts with device operations, easily leading to latency jitter, operational stuttering, and impacting overall system stability. Furthermore, it incurs significant acquisition overhead and carries high hardware access risks.

[0033] To address the problem in related technologies where the lack of continuous recording of component status information makes it impossible to trace the component's state before an anomaly occurs, thus hindering the localization and reproduction of transient performance faults, this invention provides a device monitoring method, electronic device, storage medium, and program product. By setting up a first operating system and a second operating system with different response rates in the device's management controller, the first operating system, with its higher response rate, collects the status information of components in the device and stores it in a first storage area, ensuring the real-time nature of the status information collection. The second operating system is responsible for anomaly monitoring. When an anomaly is detected in a component, it retrieves the status information within a target time period from the first storage area to generate anomaly monitoring results. This target time period corresponds to the time period before the anomaly, and includes at least the time period preceding the anomaly time. This ensures that both the status information at the time of the anomaly and the information prior to it are completely preserved and used for anomaly analysis. Therefore, this invention solves the problem in related technologies where the lack of continuous recording of component status information makes it impossible to trace the component's state before an anomaly occurs, thus hindering the localization and reproduction of transient performance faults. It achieves the effect of accurately tracing the root cause of a fault without needing to reproduce the fault, improving the accuracy of device anomaly monitoring.

[0034] The specific application environment architecture or specific hardware architecture on which the execution of the device monitoring method depends is described here.

[0035] Figure 1 This is an architecture diagram of a device monitoring system provided in an embodiment of the present invention.

[0036] like Figure 1 As shown, the device monitoring system provided in this embodiment of the invention may include: a device management controller, a target bus, and components in the device; wherein, the management controller includes a first operating system, a second operating system, a first storage area, and a second storage area.

[0037] The device can be an electronic device such as a server, storage device, or network device that requires monitoring of its hardware operating status. This embodiment of the invention uses a server as an example. The management controller is an out-of-band management unit within the device that operates independently of the host-side business system; for example, it can be a BMC (Browser Management Center). The management controller internally runs both a first operating system and a second operating system, forming a heterogeneous dual-system architecture, with the first operating system having a higher response rate than the second operating system.

[0038] In this embodiment of the invention, the response rate is used to characterize the response latency to a task (such as power-on initialization or interruption). The higher the response rate, the lower the response latency.

[0039] The first operating system can be a program with real-time capabilities, including a real-time operating system (RTOS) and bare-metal program code capable of implementing real-time functions. The type of real-time operating system can include, but is not limited to, FreeRTOS, RTLinux, or other real-time operating systems in embedded systems.

[0040] The second operating system can be a non-real-time operating system, specifically including but not limited to Contiki, HeliOS, and Linux.

[0041] In some optional embodiments of the present invention, the first operating system and the second operating system may both run on the core processor of the baseboard management controller and communicate with each other through inter-core communication. In other optional embodiments of the present invention, the first operating system and the second operating system may also have one running on the core processor of the baseboard management controller and the other running on the coprocessor of the baseboard management controller; for example, the first operating system runs on the coprocessor and the second operating system runs on the core processor.

[0042] In this heterogeneous dual-system architecture, the two systems achieve functional decomposition and collaborative division of labor: the second operating system (e.g., Linux) is responsible for complex management tasks such as system-wide anomaly detection, inter-core instruction issuance, log maintenance, human-computer interaction, and platform management; the first operating system (e.g., RTOS), after resource trimming and elimination of redundant services and drivers, retains only core functions such as bus communication (e.g., I2C communication), memory management, and inter-core interaction, and is specifically responsible for real-time tasks such as high-frequency hardware acquisition, buffer data maintenance, and abnormal data freezing. Through this functionally decoupled division of labor architecture, the comprehensive platform management capabilities of the second operating system are preserved, while the low scheduling jitter of the first operating system ensures high real-time performance of the acquisition, solving the problems of large scheduling jitter and insufficient sampling accuracy in traditional single-Linux monitoring solutions.

[0043] The components in the device are the hardware to be monitored. These components may include at least one of the following: memory modules (e.g., DDR5 memory modules, which have onboard PMIC and SPD; the PMIC can monitor memory power supply voltage, current, and transient electrical fluctuations, while the SPD can read basic hardware information such as memory model, parameters, and temperature); PCIe devices (whose link status can be represented by the LTSSM status); power supply modules (e.g., motherboard power supply modules); and temperature sensors (e.g., ambient temperature sensors at server air inlets and outlets). All of these components can be standard hardware native to the device, eliminating the need for additional dedicated data acquisition hardware. They offer strong versatility and compatibility, adapting to various device platforms and reducing adaptation and deployment costs.

[0044] Each component establishes interconnection and communication with the management controller via a target bus. The target bus can include at least one of the following: integrated circuit bus (i.e., I2C bus), platform environment control interface bus (i.e., PECI bus), serial peripheral interface bus (i.e., SPI bus), and high-speed serial expansion bus (i.e., PCIe bus). The first operating system directly reads the corresponding status registers inside each component by issuing standard bus access instructions (e.g., standard I2C access instructions), thereby obtaining the component's status information. Status information can include at least one of the following: transient voltage, transient current, power supply fluctuations, temperature (e.g., memory module temperature, inlet / outlet ambient temperature), link status, power consumption (e.g., overall system power consumption), bus load, and error count. The entire acquisition process is completed independently out-of-band by the management controller, without the involvement of the host CPU. It does not access the host core registers or service bus, abandoning the high-overhead acquisition methods of traditional direct reading of host registers, high-speed bus parsing, and MMIO space access. From an architectural perspective, it completely avoids resource contention and interference with host services, resulting in low operating overhead.

[0045] The first storage area is used to store the status information collected by the first operating system. Optionally, the first storage area is a circular buffer, which is deployed in the local memory of the management controller. It can be deployed on the management controller's on-chip SRAM or on external memory chips, thus being compatible with both storage media and supporting dynamic capacity adaptive adjustment. It balances low-latency read / write, low resource overhead, and cache capacity adaptability, and can adapt to management controller hardware platforms of different specifications and configurations. The second storage area can be an independent shared memory region partitioned from the management controller's local memory. This shared memory region is shared and accessed by both the first and second operating systems, serving as a dedicated carrier for cross-core data interaction between the two systems.

[0046] Based on the above architecture, the overall workflow of the equipment monitoring system can include: The first operating system runs independently on the out-of-band architecture of the management controller, without occupying any host service resources; each monitored component in the device updates its internal register status in real time; the first operating system polls the register data through the target bus at a fixed microsecond interval, encapsulates the collected data into a standard frame format, and writes it into a circular buffer for cyclic storage. During operation, the second operating system continuously monitors the overall operating condition of the equipment. Upon identifying transient anomalies such as performance jitter, sudden increases in latency, link anomalies, and electrical parameter jumps, it sends a freeze command to the first operating system via inter-core communication; upon receiving the command, the first operating system immediately locks the buffer state, stops data cyclic overwriting, and solidifies the complete time-series data before and after the anomaly; after data solidification, the first operating system moves the frozen data to shared memory and wakes up the second operating system via an inter-core interrupt, allowing the second operating system to read the data and perform fault tracing analysis; after analysis, the second operating system issues a recovery command, the first operating system unlocks the buffer, and re-enters normal data acquisition mode, forming a complete monitoring operation loop.

[0047] The hardware architecture provided by this invention allows for high-frequency acquisition of hardware status and pre-storage of time-series data, leveraging the differentiated division of labor among the heterogeneous dual systems within the management controller and utilizing the high real-time performance, low latency, and lightweight operation advantages of the first operating system. When the second operating system detects an anomaly in a device component, it retrieves complete, high-precision time-series data before and after the anomaly from the first operating system, constructing a hardware performance black box. This enables precise location of the root cause of the fault without the need for fault reproduction.

[0048] The embodiments of the present invention provide a device monitoring method. The method is described in detail below in conjunction with the execution flow of the device monitoring method.

[0049] Figure 2 A flowchart of a device monitoring method provided in an embodiment of the present invention.

[0050] The device monitoring method provided in this embodiment of the invention is applied to the device management controller. The management controller includes a first operating system and a second operating system, wherein the response rate of the first operating system is higher than that of the second operating system. The specific forms of the management controller, the first operating system, and the second operating system can be referred to the description of the above-described device monitoring system embodiment.

[0051] like Figure 2 As shown, the device monitoring method provided in this embodiment of the invention may include: S201: collecting status information of components in the device through a first operating system and storing the status information in a first storage area.

[0052] S202: Monitor component anomalies through a second operating system.

[0053] S203: When an anomaly is detected in a component, the system obtains the status information for the target time period stored in the first storage area through the second operating system, and generates an anomaly monitoring result based on the obtained status information.

[0054] The target time period is the time period corresponding to the abnormal time point of the component, and the target time period includes at least the time period before the abnormal time point.

[0055] In this embodiment of the invention, the response rate is used to characterize the response latency to a task (such as power-on initialization or interruption). The higher the response rate, the lower the response latency.

[0056] The first operating system can be a program with real-time capabilities, including a real-time operating system (RTOS) and bare-metal program code capable of implementing real-time functions. The type of real-time operating system can include, but is not limited to, FreeRTOS, RTLinux, or other real-time operating systems in embedded systems.

[0057] The second operating system can be a non-real-time operating system, specifically including but not limited to Contiki, HeliOS, and Linux.

[0058] Further details about the first and second operating systems can be found in the description of the above-described device monitoring system embodiments.

[0059] Optionally, before collecting the status information of components in the device through the first operating system, that is, before executing S201, the device monitoring method provided in this embodiment of the invention may further include: performing initialization on the first operating system, wherein the first operating system after initialization is loaded with a bus controller driver and an inter-core communication driver, and no drivers and services unrelated to the collection of status information are loaded; performing initialization on the second operating system, wherein the second operating system after initialization is deployed with a management service, an anomaly monitoring service and an inter-core communication service.

[0060] Specifically, after the device powers on, the first and second operating systems within the management controller complete their initialization. The first operating system performs a streamlined, lightweight initialization process, loading only the bus controller driver and inter-core communication driver, while disabling all hardware drivers and services unrelated to the acquired status information. In other words, the first operating system undergoes resource trimming, retaining only core functions such as bus communication, memory management, and inter-core interaction. The second operating system completes the initialization and deployment of routine management services, anomaly monitoring services, and inter-core communication services, enabling coordinated control and operation of the two systems. By trimming and lightweighting the first operating system, system resource overhead can be effectively reduced, further minimizing scheduling jitter and ensuring the timing stability of microsecond-level high-frequency data acquisition.

[0061] The following provides a detailed explanation of each step from S201 to S203.

[0062] For S201, the status information of the components in the device is collected through the first operating system and stored in the first storage area.

[0063] Among them, the component is the hardware to be monitored in the device, and the status information is the information that characterizes the operating status of the component.

[0064] In this embodiment of the invention, the components may include at least one of the following: a memory module, a PCIe device, a power supply module, and a temperature sensor. Status information may include at least one of the following: transient voltage, transient current, power supply fluctuation, temperature, link status, power consumption, bus load, and error count.

[0065] For example, components may include DDR5 memory modules, PCIe high-speed devices, motherboard power supply modules, and device inlet and outlet temperature sensors. Accordingly, status information may include transient voltage, transient current, power supply fluctuations, and memory module temperature (e.g., read from the PMIC and SPD onboard to the DDR5 memory module), PCIe device link status (e.g., the status of the LTSSM), overall power consumption and bus load of the motherboard power supply module, ambient temperature of the device inlet and outlet, and component error counts and other operating parameters.

[0066] It should be noted that error counting, also known as hardware implicit minor error counting, is used to record the implicit cumulative anomalies of components. Some components have self-testing mechanisms, and the results are usually stored in the component's registers, in various forms: typically, a numerical value characterizing the potential error situation, such as a counter from 0 to 100, where the component may be about to malfunction when the count reaches 80; or it could be the number of times a state parameter exceeds a threshold. Unlike relatively objective core state parameters such as transient voltage and temperature, error counting is the component's own judgment, that is, the situation the component perceives as potentially indicating an anomaly. In this embodiment of the invention, by collecting error counting, it is possible to predict that a component may malfunction in the near future, providing a basis for early warning and root cause analysis of faults.

[0067] In this embodiment of the invention, the collection of status information of components in the device through the first operating system can be achieved by periodic polling. Therefore, S201, collecting the status information of components in the device through the first operating system, may include: using the first operating system to poll and read data recorded in the registers of the components via a target bus according to a target period to obtain the status information.

[0068] Specifically, the first operating system establishes a high-precision sampling cycle. Following a preset target period, it sequentially traverses the internal registers of each component (e.g., sequentially traversing the DDR5 memory module, PCIe high-speed device, motherboard power supply module, and device inlet / outlet temperature sensors) via the target bus, batch-reading the raw parameters of each component's real-time operation to achieve high-frequency acquisition of component status across all dimensions. The target period can be in the microsecond range, such as 10 microseconds, 50 microseconds, or 100 microseconds. The target period can be determined based on the rate of change of component status information; for example, transient voltage and transient current change rapidly, a shorter target period (e.g., 50 microseconds) can be configured, while parameters that change slowly, such as temperature, can be configured with a longer target period (e.g., 10 milliseconds). Alternatively, it can be determined by comprehensively considering the transmission bandwidth of the target bus, the number of components polled in a single round, the capacity of the first storage area, and the desired backtracking time, ensuring that a single round of polling can be completed within one target period. Leveraging the low scheduling jitter of the first operating system, the acquisition accuracy can be improved from milliseconds to microseconds in traditional single-Linux solutions, thereby capturing short-term, hidden transient hardware anomalies that traditional solutions cannot identify.

[0069] In this embodiment of the invention, the target bus may include at least one of an integrated circuit bus, a platform environment control interface bus, a serial peripheral interface bus, and a high-speed serial expansion bus.

[0070] Specifically, the first operating system can collect component status information solely through the I2C bus, thus eliminating the high overhead of traditional direct reading of host registers and high-speed bus parsing. This results in low operating overhead and completely avoids resource contention and interference with host services from an architectural perspective. Alternatively, the first operating system can also collect component status information through the I2C bus and other buses provided by the management controller, such as the PECI bus, SPI bus, and PCIe bus. For example, the temperature and status of the CPU and memory can be monitored through the PECI bus.

[0071] After acquiring the status information, the first operating system stores the status information in the first storage area. The first storage area can be a circular buffer or other types of storage area. The first operating system encapsulates the acquired data into standard data frames and writes them sequentially into the circular buffer for cyclic storage, achieving uninterrupted pre-storage with extremely low memory overhead, and continuously reserving time-series data for transient fault tracing.

[0072] For S202, the second operating system is used to monitor the components for anomalies.

[0073] In S202, anomaly monitoring of components via a second operating system may include: acquiring anomaly monitoring data through the second operating system. This anomaly monitoring data may include at least one of the following: operational information reported by the device's host side, operational logs of the management controller, and hardware alarm data of the component. Based on this anomaly monitoring data, the second operating system monitors whether the component exhibits any anomalies, where anomalies may include at least one of the following: performance degradation, sudden increase in latency, link anomaly, electrical parameter fluctuations, and temperature anomalies.

[0074] Specifically, during operation, the second operating system integrates the operating information reported by the device host, the local operating logs of the management controller, and the hardware alarm data of the components to monitor the overall operating status of the device in real time and identify occasional performance failures such as overall performance degradation, sudden increase in service latency, transient abnormalities in PCIe links, memory access jitter, abnormal fluctuations in electrical parameters, and abnormal overall temperature.

[0075] For example, the second operating system can monitor whether a component is abnormal by comparing abnormal monitoring data with preset abnormal judgment conditions: for performance degradation, an abnormality can be judged when the service throughput is lower than a preset percentage (e.g., 80%) of the baseline average; for sudden increases in latency, an abnormality can be judged when the service processing latency or memory access latency exceeds a preset multiple (e.g., 1.5 times) of the average within the sliding statistical window, or exceeds a preset latency threshold (e.g., 10 milliseconds); for link abnormalities, an abnormality can be judged when the PCIe link experiences a momentary speed reduction or abnormal link state switching; for electrical parameter fluctuations, an abnormality can be judged when the fluctuation range of the power supply voltage exceeds a preset range of the rated voltage (e.g., ±5%); for temperature abnormalities, an abnormality can be judged when the temperature exceeds a preset temperature threshold (e.g., 85°C). The preset thresholds mentioned above can be determined according to the component manufacturer's instructions or based on historical operating data statistics of the equipment.

[0076] Since anomaly monitoring requires analyzing information from multiple sources and performing relatively complex judgments, it places high demands on the management capabilities of the operating system, while having relatively low requirements for real-time performance. Therefore, in this embodiment of the invention, the anomaly monitoring task is performed by a second operating system.

[0077] For S203, when an anomaly is detected in a component, the second operating system obtains the status information for the target time period stored in the first storage area, and generates an anomaly monitoring result based on the obtained status information.

[0078] The target time period is the time period corresponding to the abnormal time point of the component, and the target time period includes at least the time period before the abnormal time point. The abnormal time point is the time point at which the second operating system detects an abnormality in the component. For example, the target time period can be the time period from 5 seconds before the abnormal time point to 0.5 seconds after the abnormal time point. Since there is a certain processing delay from the occurrence of the abnormality to the second operating system completing the abnormality judgment and triggering data acquisition, the first storage area will actually retain the status information collected for a short period of time after the abnormal time point. Therefore, the target time period can also be the time period corresponding to all the status information retained when the first storage area is frozen, that is, covering the period before the abnormality is triggered, the instant of the abnormality, and the period of abnormality. The duration before the abnormal time point in the target time period can be determined according to the capacity of the first storage area, the frame length of the data frame, and the target period.

[0079] After acquiring the status information within the target time period, the second operating system generates anomaly monitoring results based on this information. For example, the second operating system can integrate and analyze the changing patterns of memory status, PCIe link status, bus load, electrical parameters, and temperature parameters within the target time period, compare the differences in component status before and after the anomaly, locate the root cause of occasional performance fluctuations in the device, and output the root cause location results, key timing data before and after the anomaly, etc., as anomaly monitoring results for maintenance personnel to view or for use by upper-level maintenance systems.

[0080] The device monitoring method provided in this invention sets up a first operating system and a second operating system with different response rates in the device's management controller. The first operating system, with a higher response rate, collects the status information of the components in the device and stores it in a first storage area, ensuring the real-time nature of the status information collection. The second operating system is responsible for anomaly monitoring. When an anomaly is detected in a component, it obtains the status information within a target time period from the first storage area to generate anomaly monitoring results. The target time period is the time period corresponding to the time point of the anomaly of the component, and the target time period includes at least the time period before the time point of the anomaly. This ensures that the status information at the time of the anomaly and before is completely preserved and used for anomaly analysis. Therefore, it can solve the problem in related technologies where the lack of continuous recording of component status information leads to the inability to trace the component status before the anomaly occurs, resulting in difficulty in locating and reproducing transient performance failures of components. This achieves the effect of accurately tracing the root cause of the fault without reproducing the fault and improving the accuracy of device anomaly monitoring.

[0081] Based on the above embodiments, the present invention further describes the storage mechanism of the first storage area.

[0082] In this embodiment of the invention, the first storage area can be a circular buffer. Storing state information into the first storage area in S201 can include: sequentially writing state information into the circular buffer through a first operating system, and, when the circular buffer is full, cyclically overwriting the state information with the earliest storage time in the circular buffer.

[0083] Specifically, in routine monitoring scenarios, the first operating system writes the collected status information into a circular buffer in the local memory of the management controller. When the circular buffer is full, an automatic iteration mechanism is used to overwrite expired data, i.e., the oldest stored status information is overwritten in the circular buffer, while the latest time-series dataset is retained. As described in the above embodiment of the device monitoring system, the circular buffer can be deployed on the on-chip SRAM of the management controller or external memory chips, and supports dynamic capacity adaptive adjustment. Through the circular overwrite mechanism of the circular buffer, the latest operating status data of the device hardware can always be maintained, realizing uninterrupted pre-storage of hardware time-series data around the clock, continuously retaining the latest operating data of the device, and adapting to the capture scenarios of transient sudden anomalies.

[0084] Furthermore, the circular buffer can be configured with write pointers and read pointers. Writing state information sequentially into the circular buffer via the first operating system can include: driving the write pointer to increment cyclically via the first operating system, writing the state information to the storage location indicated by the write pointer; wherein, during the writing of state information, the read pointer is in an disabled, locked state.

[0085] Specifically, the circular buffer is configured with an independent dual-pointer architecture (read and write pointers) and a read-write mutual exclusion protection mechanism, employing a differentiated operating logic of "write pointers autonomously incrementing in a circular manner, and read pointers being passively triggered on demand." The write pointer is entirely controlled by the first operating system, responsible for routine data overwrite writing; the read pointer is in a locked, disabled state by default, never exposed for external reading, and only used for internal data transfer within the first operating system. During routine data acquisition, the first operating system only drives the write pointer to continuously increment in a unidirectional circular manner, constantly writing newly acquired status information to the storage location indicated by the write pointer, while automatically overwriting the oldest expired time-series data; during this process, the read pointer remains in a locked, disabled state and does not participate in read or write operations. Through this dual-pointer separation design, the routine write process does not require any read-side synchronization or scheduling operations, maintaining high-frequency acquisition with extremely low memory overhead and scheduling loss. Simultaneously, it completely isolates three types of operations—routine data writing, abnormal data freezing, and cross-core data transfer—from a mechanism perspective, avoiding read-write conflicts and data corruption in high-frequency acquisition scenarios.

[0086] If an anomaly is detected, the circular buffer can be frozen. That is, the device monitoring method provided in this embodiment of the invention may further include: when an anomaly is detected in a component, sending a freeze command to the first operating system via the second operating system; and the first operating system responding to the freeze command by locking the current position of the write pointer and stopping the writing of status information to the circular buffer.

[0087] Specifically, after the second operating system determines that a component is abnormal, it sends a freeze command to the first operating system through the inter-core communication channel of the management controller. Upon receiving the freeze command, the first operating system immediately locks the current position of the write pointer (which is in an enabled state under normal circumstances, so no secondary locking is required), stops the offset of the write pointer, and stops subsequent data writing and loop overwriting operations. This accurately freezes the complete and continuous time-series data before the abnormality is triggered, at the moment of the abnormality, and during the duration of the abnormality. Because the first operating system has a high response rate and the freeze operation is an instantaneous pointer locking operation, it can solidify the abnormal data in a very short time after the abnormality occurs, preventing critical transient fault data from being lost due to subsequent writes and overwriting.

[0088] After the anomaly analysis is completed, normal data collection in the circular buffer is restored. That is, after generating the anomaly monitoring result based on the acquired status information in S203, the device monitoring method provided in this embodiment of the invention may further include: sending a recovery command to the first operating system through the second operating system; and, in response to the recovery command, the first operating system releases the lock on the write pointer to continue collecting the status information of the component through the first operating system and storing the status information in the first storage area.

[0089] Specifically, after the second operating system completes the fault data analysis (i.e., generates the anomaly monitoring results), it sends a data acquisition recovery command to the first operating system. In response to the recovery command, the first operating system releases the lock on the write pointer, clears the freeze flag, and restarts the high-frequency acquisition and cyclic storage process. This means it continues executing the steps of acquiring the status information of the components through the first operating system and storing that information in the first storage area, thus bringing the system back to normal acquisition mode. This freeze, analysis, and recovery process ensures that monitoring capabilities are restored immediately after a single anomaly is handled, preventing interruption of subsequent 24 / 7 monitoring due to a single anomaly analysis.

[0090] Furthermore, considering that if data acquisition completely stops during the period when the write pointer is frozen (i.e., the time between the issuance of the freeze command and the issuance of the restore command), the status information of the component during this period will be lost. Therefore, the circular buffer can include a main buffer and a temporary buffer, with the write pointer corresponding to the main buffer. The device monitoring method provided in this embodiment of the invention may further include: during the period when the write pointer is locked, writing the acquired component status information into the temporary buffer through a first operating system; after unlocking the write pointer, synchronizing the status information stored in the temporary buffer to the main buffer according to the acquisition time order through the first operating system, and clearing the temporary buffer.

[0091] Specifically, the main buffer is the buffer mentioned above that performs normalized circular storage, and the frozen write pointer is the write pointer corresponding to the main buffer. During the period when the write pointer is locked, the first operating system does not stop the acquisition operation, but writes the status information of the components acquired during this period into a temporary buffer; after unlocking the write pointer, the first operating system synchronizes the status information stored in the temporary buffer to the main buffer in the order of acquisition time, clears the temporary buffer, and then resumes normalized circular writing to the main buffer.

[0092] In some alternative embodiments of the present invention, a dual-buffer mechanism can also be adopted, that is, two equal circular buffers are configured, and when the write pointer of one buffer is frozen, the writing is switched to the other buffer to continue. By using a main buffer combined with a temporary buffer (or a dual buffer) design, the acquisition is not interrupted when the write pointer is frozen, ensuring the continuity of the time series data throughout the process, avoiding the omission of important component status information during anomaly analysis, and further improving the integrity of the black box data.

[0093] Based on the above embodiments, this embodiment of the invention further describes the steps of the second operating system to obtain the state information of the target time period in the first storage area.

[0094] In this embodiment of the invention, obtaining the state information within the target time period stored in the first storage area through the second operating system in S203 may include: activating the read pointer through the first operating system to read the state information within the target time period from the circular buffer, writing the read state information into the second storage area, and resetting the read pointer and restoring it to the disabled locked state after the writing is completed; sending an inter-core interrupt to the second operating system through the first operating system; and reading the state information within the target time period from the second storage area in response to the inter-core interrupt through the second operating system.

[0095] Specifically, after the abnormal data is solidified (i.e., the write pointer is locked), the first operating system internally activates the read pointer, starting from the locked starting position, to read the time-series data within the solidified target time period frame by frame from the circular buffer, and batch-transfers the read state information to the second storage area. After the transfer (writing) is completed, the first operating system resets the read pointer and relocks it to an disabled locked state so that the read pointer does not participate in read / write operations when the circular buffer resumes normal writing. Subsequently, the first operating system wakes up the second operating system through an inter-core interrupt; the second operating system responds to the inter-core interrupt, actively reads all state information within the target time period from the second storage area, and then executes the abnormal analysis steps described in the above embodiment.

[0096] Therefore, the second operating system only reads backup data from the second storage area for fault analysis, without directly accessing the first storage area. The read pointer is only used for internal data transfer within the first operating system and is not exposed to the outside. As a result, the three types of operations—normal data writing (write pointer driven), abnormal data freezing (write pointer locking), and cross-core data transfer (read pointer internal activation)—are completely isolated in terms of timing and access subject. This accurately distinguishes the working timing of normal writing, internal data transfer, and upper-layer data analysis, completely avoiding interference from upper-layer business to the acquisition cache, as well as data corruption, read-write conflicts, and critical data loss in high-frequency acquisition scenarios. This comprehensively ensures the integrity, continuity, and reliability of the black box time-series data.

[0097] In this embodiment of the invention, the second storage area can be a shared memory area partitioned in the local memory of the management controller, and the shared memory area is shared and accessed by the first operating system and the second operating system.

[0098] Specifically, an independent shared memory region is allocated in the local memory of the management controller as a dedicated carrier for cross-core data interaction between the first and second operating systems. This shared memory region is shared and accessed by both the first and second operating systems and is adaptable to management controller hardware platforms with different configurations. This embodiment of the invention utilizes a low-latency, interconnected transmission mechanism combining shared memory and inter-core interrupts. By allocating an independent shared memory region in the local memory of the management controller and coordinating with inter-core interrupts, efficient and reliable data interaction between the two systems is achieved. This forms a workflow of anomaly detection and judgment by the second operating system—issuing a freeze command, freezing data in the first operating system to shared memory, inter-core interrupt notification, and reading and analysis by the second operating system. This enables low-latency cross-core transmission of frozen time-series data, ensuring complete synchronization of fault data and providing stable data support for accurate tracing of occasional, unreproducible performance failures in servers.

[0099] Based on the above embodiments, the present invention further describes the storage format of state information in the first storage area.

[0100] In this embodiment of the invention, storing the status information in the first storage area in S201 may include: encapsulating the status information obtained in a single round of collection into a data frame through a first operating system, and storing the data frame in the first storage area; wherein, the fields of the data frame include the status parameters of the component, and also include at least one of the following: frame header identifier, timestamp, device type identifier, component error count, and frame check field.

[0101] Specifically, the first operating system can poll the registers of each component to collect the status information of each component, and perform normalization and unified encapsulation on the collected status information to generate standardized timing data frames with uniform structure, time alignment, and verifiable error correction. In order to ensure that the timing data is normalized and aligned and can be directly parsed, the first storage area (e.g., a circular buffer) can adopt a fixed frame length and structured storage design, dividing the overall cache space equally into multiple independent data frames, with each frame corresponding to one polling collection result.

[0102] Figure 3 This is a schematic diagram of a ring buffer frame structure and partition layout provided in an embodiment of the present invention.

[0103] like Figure 3 As shown, a single frame of data can consistently contain six core fields: First, a frame header identifier, used to identify the starting position of the frame data, for example, a fixed identifier code can be used; second, a timestamp, such as a high-precision microsecond-level timestamp, used to mark the acquisition time and achieve time-series alignment of multi-dimensional component parameters; third, a device type identifier, used to distinguish monitoring objects such as DDR5 memory, PCIe devices, power supply modules, and temperature sensors, for example, a pre-agreed type code can be used; fourth, component status parameters, i.e., core status parameters, including key data such as memory transient voltage, transient current, power supply fluctuations, memory module temperature, PCIe link status, overall power consumption, bus load, and device inlet / outlet ambient temperature; fifth, a component error count (i.e., hardware implicit minor error count), used to record implicit cumulative anomalies of components, the meaning of which can be referred to the explanation in Example 2; and sixth, a frame check field, for example, a Cyclic Redundancy Check (CRC) code can be used to ensure the integrity of single-frame data storage and transmission and avoid data distortion caused by high-frequency read and write operations. By encapsulating data frames in a standardized manner, the problems of chaotic timing, inconsistent formats, and easy distortion of high-frequency acquired data are solved, ensuring the integrity and standardization of subsequent data storage, freezing, and parsing.

[0104] In some optional embodiments of the present invention, when the device includes multiple components, the status information of the multiple components obtained in a single round of data acquisition can be encapsulated into the same data frame. That is, when the device includes multiple components, encapsulating the status information obtained in a single round of data acquisition into a data frame by the first operating system and storing the data frame in the first storage area may include: encapsulating the status information of each of the multiple components obtained by polling multiple components in a single round of data acquisition into the same data frame by the first operating system; wherein the status parameters of the components included in the fields of the data frame are the status parameters of the multiple components respectively.

[0105] In other words, the first operating system polls multiple components sequentially according to the target cycle during a single data acquisition round, and encapsulates the status information of each component obtained from the single polling round into the same data frame. At this time, the status parameter field of the data frame includes the status parameters of each component, and the device type identifier can be used to identify the component type to which each status parameter belongs. By encapsulating all component information from a single data acquisition round into the same data frame, and aligning the status information of each component at the same time according to the timestamp, the second operating system can easily compare the status of multiple components at the same time during fault analysis, realizing multi-dimensional parameter correlation analysis.

[0106] In some optional embodiments of the present invention, considering that different types of components have different rates of state change, different acquisition cycles can be configured for different types of components, and the state information can be stored in partitions. The first storage area can then include multiple partitions, with at least two different types of components corresponding to different acquisition cycles. Encapsulating the state information obtained from a single round of acquisition into data frames through the first operating system and storing the data frames in the first storage area can include: encapsulating the state information of components with the same acquisition cycle into the same data frame through the first operating system, and storing the data frames corresponding to different acquisition cycles into different partitions within the multiple partitions.

[0107] In other words, the first storage area can be divided into multiple partitions, and different types of components can correspond to different acquisition cycles (acquisition frequencies). For example, electrical parameters such as transient voltage and transient current change rapidly, so DDR5 memory modules and power supply modules can be configured with shorter acquisition cycles; the link status of PCIe devices can be configured with medium acquisition cycles; and temperature changes slowly, so temperature sensors can be configured with longer acquisition cycles. The first operating system encapsulates the status information of components with the same acquisition cycle into the same data frame (i.e., component status information with the same acquisition cycle is placed in one frame), and stores the data frames corresponding to different acquisition cycles into different partitions within the multiple partitions. By dividing the data into frames according to the acquisition cycle and storing them in partitions, the acquisition frequency can be matched according to the actual rate of change of the status of various components, avoiding oversampling of slowly changing parameters and reducing bus load and storage overhead.

[0108] Furthermore, the multiple partitions may include an analysis partition; the device monitoring method provided in this embodiment of the invention may further include: the device monitoring method further includes: performing a preset analysis on the collected status information through a first operating system to obtain analysis results, and storing the analysis results in the analysis partition; when an anomaly is detected in a component, obtaining the analysis results stored in the analysis partition through a second operating system. The anomaly monitoring results are also generated based on the analysis results.

[0109] In practical applications, real-time operating systems such as RTOS possess certain data processing capabilities, although their functionality is more streamlined compared to Linux systems. Therefore, in addition to data acquisition, the first operating system can also perform preset analyses on the acquired state information. Preset analyses can be simple processing, such as threshold judgment (e.g., determining whether transient voltage exceeds ±5% of the rated voltage, whether temperature exceeds 85℃, etc., and recording the events and number of exceedances), statistical analysis (e.g., calculating the mean, peak value, and fluctuation amplitude of state parameters over a certain period of time), and storing the analysis results in the analysis partition.

[0110] When an anomaly is detected in a component, the second operating system can read all component status information as needed, or it can read only the analysis results stored in the analysis partition. The anomaly monitoring results can also be generated based on these analysis results.

[0111] The first operating system performs lightweight preset analysis and stores it in an independent partition. The second operating system can flexibly choose to read the full data or statistical analysis data according to the analysis needs, thereby improving the efficiency of anomaly analysis.

[0112] Figure 4 A flowchart of a second device monitoring method provided in an embodiment of the present invention.

[0113] Based on the above embodiments, combined with Figure 4 An optional overall workflow of the device monitoring method provided in the embodiments of the present invention will be described. For example... Figure 4 As shown, the embodiment of the present invention adopts a dual-system linkage mechanism of normalized real-time pre-collection of data in the first operating system and event-driven freezing in the second operating system. The complete operation link is divided into six stages: system initialization, normalized pre-collection, anomaly detection, data freezing, source analysis, and data recovery, so as to realize the full-process traceable closed-loop monitoring of transient fault data of equipment.

[0114] Phase ①, System power-on initialization phase: After the device is powered on and started, the first operating system and the second operating system inside the management controller complete the initialization and startup, as detailed in the above embodiment.

[0115] Phase ②, Normalized Pre-collection and Storage Phase: After the dual system initialization is completed, the whole machine enters the all-weather monitoring state. The first operating system is responsible for the low-level high-frequency data collection and cache update, that is, executing S201 to continuously reserve time-series baseline data for the fault tracing of the whole machine.

[0116] Phase ③, Real-time Anomaly Monitoring Phase: The second operating system integrates multi-source anomaly monitoring data, such as the operating information reported by the host side of the device, the operating log of the management controller, and the hardware alarm data of the components, to monitor the overall operating status of the device in real time, i.e., execute S202.

[0117] Phase 4, Anomaly Triggering and Data Freezing Phase: After the second operating system determines that the device has a performance anomaly, it sends a data freezing command to the first operating system through the inter-core communication channel of the management controller. The first operating system locks the state of the first storage area, stops data writing and cyclic overwriting, and completely preserves all high-precision time-series data before the anomaly occurs, at the moment of the anomaly, and during the anomaly's duration, to avoid the overwriting and loss of critical fault data. For details, please refer to the description in the above embodiments.

[0118] Phase 5, Data Interaction and Fault Root Cause Tracing Phase: The first operating system writes the complete timing freeze data to the second storage area (e.g., a shared memory area) and notifies the second operating system through an inter-core interrupt. The second operating system reads the data and performs fault root cause tracing analysis, i.e., executes S203. For details, please refer to the description in the above embodiment.

[0119] Phase 6, System Recovery to Normal Acquisition Phase: After the fault data analysis is completed, the second operating system sends a recovery command to the first operating system. The first operating system unlocks the first storage area, clears the freeze marker, restarts the high-frequency acquisition and cyclic storage process, and returns to Phase 2. For details, please refer to the description in the above embodiment.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. In addition, those skilled in the art can make appropriate adjustments and replacements to the dual-system division mode of the management controller, the status information acquisition strategy (e.g., the type of target bus, the value of the target period), the parameters of the first storage area (storage area type, capacity, frame length, partitioning method), the triggering logic of abnormal freezing, and the fault tracing process without departing from the core architecture and technical principles of this invention. All equivalent modifications and adaptations are within the protection scope of this invention.

[0121] Embodiments of the present invention also provide a device monitoring apparatus applied to a device management controller. The management controller includes a first operating system and a second operating system, wherein the response rate of the first operating system is higher than that of the second operating system. The device monitoring apparatus may include: a data acquisition unit, used to acquire status information of components in the device through the first operating system and store the status information in a first storage area; a monitoring unit, used to perform anomaly monitoring on the components through the second operating system; and an analysis unit, used to, when an anomaly is detected in the components, obtain status information within a target time period stored in the first storage area through the second operating system and generate an anomaly monitoring result based on the obtained status information; wherein the target time period is the time period corresponding to the anomaly time point of the components, and the target time period includes at least the time period before the anomaly time point.

[0122] In this embodiment of the invention, the first storage area can be a circular buffer; the acquisition unit stores the status information in the first storage area, which may include: writing the status information sequentially into the circular buffer through the first operating system, and when the circular buffer is full, cyclically overwriting the status information with the earliest storage time in the circular buffer.

[0123] In this embodiment of the invention, the circular buffer can be configured with a write pointer and a read pointer; the acquisition unit writes the status information sequentially into the circular buffer through the first operating system, which may include: driving the write pointer to increment cyclically through the first operating system to write the status information into the storage location indicated by the write pointer; wherein, during the process of writing the status information, the read pointer is in an disabled locked state.

[0124] In this embodiment of the invention, the analysis unit can also be used to send a freeze command to the first operating system through the second operating system when the monitoring unit detects an abnormality in the component; and the first operating system responds to the freeze command by locking the current position of the write pointer and stopping the writing of status information to the circular buffer.

[0125] In this embodiment of the invention, the analysis unit obtains the state information within the target time period stored in the first storage area through the second operating system, which may include: activating the read pointer through the first operating system to read the state information within the target time period from the circular buffer, writing the read state information into the second storage area, and resetting the read pointer and restoring it to the disabled locked state after the writing is completed; sending an inter-core interrupt to the second operating system through the first operating system; and reading the state information within the target time period from the second storage area in response to the inter-core interrupt through the second operating system.

[0126] In this embodiment of the invention, the second storage area can be a shared memory area partitioned in the local memory of the management controller, and the shared memory area is shared and accessed by the first operating system and the second operating system.

[0127] In this embodiment of the invention, the analysis unit can also be used to send a recovery command to the first operating system through the second operating system after generating an anomaly monitoring result based on the acquired status information; and the first operating system responds to the recovery command by releasing the lock on the write pointer so that the acquisition unit can continue to acquire the status information of the component through the first operating system and store the status information in the first storage area.

[0128] In this embodiment of the invention, the circular buffer may include a main buffer and a temporary buffer, and the write pointer is the write pointer corresponding to the main buffer; the acquisition unit may also be used to write the acquired component status information into the temporary buffer through the first operating system while the write pointer is in a locked state; after the write pointer is unlocked, the first operating system synchronizes the status information stored in the temporary buffer to the main buffer in the order of acquisition time, and clears the temporary buffer.

[0129] In this embodiment of the invention, the acquisition unit acquires the status information of components in the device through a first operating system, which may include: reading the data recorded in the registers of the components by polling via a target bus according to a target cycle through the first operating system to obtain the status information.

[0130] In this embodiment of the invention, the acquisition unit stores the status information in the first storage area, which may include: encapsulating the status information obtained in a single round of acquisition into a data frame through a first operating system, and storing the data frame in the first storage area; wherein, the fields of the data frame include the status parameters of the component, and also include at least one of the following: frame header identifier, timestamp, device type identifier, component error count, and frame check field.

[0131] In this embodiment of the invention, the first storage area may include multiple partitions, and at least two different types of components correspond to different acquisition cycles; the acquisition unit encapsulates the status information obtained from a single round of acquisition into a data frame through the first operating system and stores the data frame in the first storage area, which may include: encapsulating the status information of components with the same acquisition cycle into the same data frame through the first operating system, and storing the data frames corresponding to different acquisition cycles into different partitions of the multiple partitions respectively.

[0132] In this embodiment of the invention, multiple partitions may include analysis partitions; the analysis unit may also be used to perform preset analysis on the collected status information through a first operating system, obtain analysis results, and store the analysis results in the analysis partition; when an anomaly is detected in a component, the analysis results stored in the analysis partition are obtained through a second operating system; wherein, the anomaly monitoring results are also generated based on the analysis results.

[0133] In this embodiment of the invention, the device may include multiple components; the acquisition unit encapsulates the status information obtained from a single round of acquisition into a data frame through a first operating system and stores the data frame in a first storage area, which may include: encapsulating the status information of multiple components obtained from polling multiple components in a single round of acquisition into the same data frame through the first operating system; wherein, the status parameters of the components included in the fields of the data frame are the status parameters of multiple components respectively.

[0134] In this embodiment of the invention, the monitoring unit performs anomaly monitoring on the component through a second operating system, which may include: acquiring anomaly monitoring data through the second operating system; wherein, the anomaly monitoring data includes at least one of the following: operating information reported by the host side of the device, operating log of the management controller, and hardware alarm data of the component; and monitoring whether the component has anomalies based on the anomaly monitoring data through the second operating system, wherein the anomalies include at least one of the following: performance degradation, sudden increase in latency, link anomaly, electrical parameter jump, and temperature anomaly.

[0135] The device monitoring apparatus provided in this embodiment of the invention may further include: an initialization unit, used to initialize the first operating system before collecting the status information of the components in the device through the first operating system, wherein the first operating system after initialization is loaded with a bus controller driver and an inter-core communication driver, and no drivers and services unrelated to the collection of status information are loaded; and to initialize the second operating system, wherein the second operating system after initialization is deployed with management services, anomaly monitoring services and inter-core communication services.

[0136] For a description of the features in the embodiment corresponding to the equipment monitoring device, please refer to the relevant description in the embodiment corresponding to the equipment monitoring method, which will not be repeated here.

[0137] Embodiments of the present invention also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described device monitoring method embodiments.

[0138] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above-described device monitoring method embodiments when running.

[0139] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0140] Embodiments of the present invention also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described device monitoring method embodiments.

[0141] Embodiments of the present invention also provide another computer program product, including a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described device monitoring method embodiments.

[0142] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0143] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0144] The foregoing has provided a detailed description of the device monitoring method, electronic device, storage medium, and program product provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A method for monitoring equipment, characterized in that, A management controller applied to a device, the management controller including a first operating system and a second operating system, wherein the response rate of the first operating system is higher than that of the second operating system; The device monitoring method includes: The first operating system collects the status information of the components in the device and stores the status information in the first storage area; The second operating system is used to monitor the components for anomalies. If an anomaly is detected in the component, the second operating system obtains the status information within the target time period stored in the first storage area, and generates an anomaly monitoring result based on the obtained status information. The target time period is the time period corresponding to the abnormal time point of the component, and the target time period includes at least the time period before the abnormal time point.

2. The equipment monitoring method according to claim 1, characterized in that, The first storage area is a circular buffer; Storing the status information into the first storage area includes: The first operating system sequentially writes the state information into the circular buffer, and when the circular buffer is full, it cyclically overwrites the state information stored in the circular buffer that has the earliest storage time.

3. The equipment monitoring method according to claim 2, characterized in that, The circular buffer is configured with write pointers and read pointers; The first operating system sequentially writes the status information into the circular buffer, including: The first operating system drives the write pointer to increment cyclically, and writes the status information to the storage location indicated by the write pointer; During the process of writing the status information, the read pointer is in an disabled locked state.

4. The equipment monitoring method according to claim 3, characterized in that, Also includes: If an abnormality is detected in the component, a freeze command is sent from the second operating system to the first operating system. In response to the freeze command, the first operating system locks the current position of the write pointer and stops writing the status information to the circular buffer.

5. The equipment monitoring method according to claim 4, characterized in that, Obtaining the state information within the target time period stored in the first storage area through the second operating system includes: The first operating system activates the read pointer to read the state information within the target time period from the circular buffer, writes the read state information into the second storage area, and resets the read pointer to the disabled locked state after the writing is completed. Send an inter-core interrupt to the second operating system through the first operating system; The second operating system responds to the inter-core interrupt and reads the status information within the target time period from the second storage area.

6. The equipment monitoring method according to claim 5, characterized in that, The second storage area is a shared memory region partitioned from the local memory of the management controller, and the shared memory region is shared and accessed by the first operating system and the second operating system.

7. The equipment monitoring method according to claim 4, characterized in that, After generating the anomaly monitoring result based on the acquired status information, the process also includes: Send a recovery command to the first operating system through the second operating system; In response to the recovery command, the first operating system unlocks the write pointer to continue collecting the status information of the component through the first operating system and stores the status information in the first storage area.

8. The equipment monitoring method according to claim 4, characterized in that, The circular buffer includes a main buffer and a temporary buffer, and the write pointer is the write pointer corresponding to the main buffer; The device monitoring method also includes: During the period when the write pointer is in a locked state, the collected status information of the component is written to the temporary buffer through the first operating system; After unlocking the write pointer, the first operating system synchronizes the status information stored in the temporary buffer to the main buffer according to the acquisition time sequence, and then clears the temporary buffer.

9. The equipment monitoring method according to claim 1, characterized in that, The status information of the components in the device is collected through the first operating system, including: The first operating system reads the data recorded in the registers of the component through the target bus according to the target cycle to obtain the status information.

10. The equipment monitoring method according to claim 9, characterized in that, The target bus includes at least one of the following: integrated circuit bus, platform environment control interface bus, serial peripheral interface bus, and high-speed serial expansion bus.

11. The equipment monitoring method according to claim 1, characterized in that, Storing the status information into the first storage area includes: The first operating system encapsulates the status information obtained from a single round of data collection into a data frame and stores the data frame in the first storage area. The data frame includes the status parameters of the component, and also includes at least one of the following: frame header identifier, timestamp, device type identifier, error count of the component, and frame check field.

12. The equipment monitoring method according to claim 11, characterized in that, The first storage area includes multiple partitions, and at least two different types of the components correspond to different acquisition cycles; The first operating system encapsulates the state information obtained from a single round of data collection into a data frame and stores the data frame in the first storage area, including: The first operating system encapsulates the status information of the components with the same acquisition cycle into the same data frame, and stores the data frames corresponding to different acquisition cycles into different partitions of the multiple partitions.

13. The equipment monitoring method according to claim 12, characterized in that, The multiple partitions include an analysis partition; The device monitoring method also includes: The first operating system performs a preset analysis on the collected status information to obtain analysis results, and stores the analysis results in the analysis partition; If an anomaly is detected in the component, the analysis results stored in the analysis partition are obtained through the second operating system; The anomaly monitoring results are also generated based on the analysis results.

14. The equipment monitoring method according to claim 11, characterized in that, The device includes multiple of the aforementioned components; The first operating system encapsulates the state information obtained from a single round of data collection into a data frame and stores the data frame in the first storage area, including: The first operating system encapsulates the state information of each of the multiple components obtained from polling multiple components in a single round of data acquisition into the same data frame; The data frame includes state parameters for the components, which are the individual state parameters of each component.

15. The equipment monitoring method according to claim 1, characterized in that, Anomaly monitoring of the component is performed through the second operating system, including: Obtain anomaly monitoring data through the second operating system; The abnormal monitoring data includes at least one of the following: the operating information reported by the host side of the device, the operating log of the management controller, and the hardware alarm data of the component; The second operating system monitors whether the component has any abnormalities based on the abnormality monitoring data. The abnormalities include at least one of the following: performance degradation, sudden increase in latency, link abnormality, electrical parameter jump, and temperature abnormality.

16. The equipment monitoring method according to claim 1, characterized in that, Before collecting the status information of the components in the device through the first operating system, the device monitoring method further includes: The first operating system is initialized. The initialized first operating system is loaded with bus controller driver and inter-core communication driver, but no drivers and services unrelated to the collection of the status information are loaded. The second operating system is initialized, and management services, anomaly monitoring services, and inter-core communication services are deployed in the initialized second operating system.

17. The equipment monitoring method according to any one of claims 1 to 16, characterized in that, The component includes at least one of the following: a memory module, a PCIe device, a power supply module, and a temperature sensor; The status information includes at least one of the following: transient voltage, transient current, power supply fluctuation, temperature, link status, power consumption, bus load, and error count.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the device monitoring method as described in any one of claims 1 to 17.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the device monitoring method as described in any one of claims 1 to 17.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the device monitoring method as described in any one of claims 1 to 17.

Images