Process monitoring method, system and equipment of baseboard management controller and medium

Abstract

The invention discloses a process monitoring method, system and device for a baseboard management controller and a medium, and relates to the technical field of server management, and the method comprises the steps: continuously collecting CPU occupation information of a target process from an information collection file through a kernel interface based on a preset sampling time interval, and calculating the CPU utilization rate of the target process, and calculating a target parameter based on the CPU utilization rate in the preset sliding time window, analyzing the target parameter and the CPU utilization rate based on a preset threshold value, and determining the CPU state of the target process. According to the method, the CPU usage rate of each process can be continuously calculated by periodically sampling the CPU occupation information and the system CPU time of the target process, the CPU usage condition of the target process is analyzed based on the sliding time window, sampling and analysis can be automatically carried out, whether abnormity exists or not is monitored in real time, and the monitoring efficiency of the target process is improved.

Description

Technical Field

[0001] This application relates to the technical field of server management, and in particular, to a method, system, device, and medium for monitoring the processes of a baseboard management controller. Background Art

[0002] A baseboard management controller (BMC) is an embedded controller in a server system that implements functions such as power control, sensor monitoring, remote management, and fault recovery. With the increasing complexity of server functions, more and more services are running in the baseboard management controller. The services in the baseboard management controller run in the form of processes on the embedded system of the baseboard management controller, which will occupy a certain amount of CPU (Central Processing Unit) resources. There are multiple daemon processes running concurrently in the baseboard management controller. The prior art relies on manually parsing relevant files to view resources, which requires manual operation and has a relatively coarse query granularity, resulting in a low overall monitoring efficiency of the processes. Summary of the Invention

[0003] This application provides a method, system, device, and medium for monitoring the processes of a baseboard management controller to at least solve the problem of low efficiency in monitoring the processes in the baseboard management controller in the related art.

[0004] This application provides a method for monitoring the processes of a baseboard management controller, the method comprising: Continuously collecting the CPU occupancy information and system CPU time of a target process from an information collection file through a kernel interface based on a preset sampling time interval, and calculating the CPU usage rate of the target process based on the CPU occupancy information at adjacent sampling times, the CPU usage rate corresponding to each sampling time one by one; Writing the CPU usage rates corresponding to multiple sampling times into a preset sliding time window, and calculating a target parameter based on the CPU usage rates within the preset sliding time window, the target parameter being used to characterize the CPU usage situation corresponding to a target time period; Analyzing the target parameter and the CPU usage rate based on a preset threshold to determine the CPU status of the target process, the CPU status including an abnormal status.

[0005] This application also provides a system for monitoring the processes of a baseboard management controller, the system comprising: A sampling module, which continuously collects the CPU occupancy information and system CPU time of a target process from a kernel interface based on a preset sampling time interval, and calculates the CPU usage rate of the target process based on the CPU occupancy information and system CPU time at adjacent sampling times, the CPU usage rate corresponding to each sampling time one by one; A first analysis module, configured to write the CPU utilization rates corresponding to multiple sampling moments into a preset sliding time window, and calculate a target parameter based on the CPU utilization rates within the preset sliding time window, where the target parameter is used to characterize the CPU usage condition corresponding to a target time period; A second analysis module, configured to analyze the target parameter and the CPU utilization rate based on a preset threshold to determine the CPU status of the target process, where the CPU status includes an abnormal status. This application also provides a computer device, including: a memory, configured to store a computer program; a processor, configured to implement the steps of any one of the above-mentioned process monitoring methods of the baseboard management controller when executing the computer program.

[0006] This application also provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of any one of the above-mentioned process monitoring methods of the baseboard management controller are implemented.

[0007] The process monitoring method of the baseboard management controller provided by the embodiment of the present invention includes continuously collecting the CPU occupancy information of a target process from an information collection file through a kernel interface based on a preset sampling time interval, calculating the CPU utilization rate of the target process based on the CPU occupancy information of adjacent sampling moments, and then writing the CPU utilization rates corresponding to multiple sampling moments into a preset sliding time window, and calculating a target parameter based on the CPU utilization rates within the preset sliding time window, where the target parameter is used to characterize the CPU usage condition corresponding to a target time period; analyzing the target parameter and the CPU utilization rate based on a preset threshold to determine the CPU status of the target process, where the CPU status includes an abnormal status. This method samples the CPU occupancy information of the target process and the system CPU time periodically, so as to continuously calculate the CPU utilization rate of each process, and analyze the CPU usage condition of the target process based on the sliding time window, without manual intervention, can automatically perform sampling and analysis, and can monitor in real time whether there is an abnormality, improving the monitoring efficiency of the target process of the baseboard management controller. Description of the Drawings

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

[0009] Figure 1 It is a flowchart of a process monitoring method of a baseboard management controller provided by an embodiment of the present application; Figure 2Flowchart of another method for monitoring processes of a baseboard management controller provided by an embodiment of this application; Figure 3 Flowchart of yet another method for monitoring processes of a baseboard management controller provided by an embodiment of this application; Figure 4 Schematic diagram of a system for monitoring processes of a baseboard management controller provided by an embodiment of this application; Figure 5 Schematic diagram of a computer device provided by an embodiment of this application. Detailed implementation manners

[0010] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.

[0011] It should be noted that in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0012] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be made in conjunction with the accompanying drawings and specific implementation manners.

[0013] A baseboard management controller is a dedicated microcontroller embedded in key hardware devices such as servers, running independently of the main processor, and providing out-of-band management capabilities. The core functions of the BMC include real-time monitoring of the status of hardware sensors, remote control of the server power supply, management of firmware updates, and support for remote access and fault diagnosis through standard protocols. Even when the host operating system crashes or becomes unresponsive, the BMC can continue to work, and it is the infrastructure for ensuring the stable operation of the server and realizing efficient remote operation and maintenance.

[0014] The baseboard management controller runs multiple daemon processes on an embedded Linux system. These processes jointly support its core management functions, including processing remote commands, a sensor daemon (collecting hardware data such as temperature, voltage, and fan speed in real time), a logging system (recording events), a policy engine (executing automated operations), and a web service (providing a management interface), etc. These processes run concurrently in the resource-constrained BMC environment, continuously consuming CPU and memory resources. However, current BMC systems generally lack a fine-grained process-level resource monitoring mechanism, making it difficult to detect and diagnose process anomalies in real time (such as full CPU occupancy, memory leaks, or infinite loops). Once a critical service process gets out of control, it may directly lead to the risk of the entire machine management function failing.

[0015] Embodiments of this application provide a process monitoring method for a baseboard management controller. The method will be described in detail in combination with the execution flow of the process monitoring method for the baseboard management controller.

[0016] According to an embodiment of the present invention, there is provided an embodiment of a process monitoring method for a baseboard management controller. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0017] In this embodiment, a process monitoring method for a baseboard management controller is provided. Figure 1 It is a flowchart of the process monitoring method for the baseboard management controller according to an embodiment of the present invention, as Figure 1 shown. The process includes the following steps: Step S101, continuously collect the CPU occupancy information and system CPU time of the target process from the information collection file through the kernel interface based on a preset sampling time interval, and calculate the CPU usage rate of the target process based on the CPU occupancy information and system CPU time at adjacent sampling moments.

[0018] Among them, the CPU usage rate corresponds one-to-one with the sampling moment. The CPU occupancy information includes user-mode CPU time, kernel-mode CPU time, and system CPU time. The kernel interface is a specific system interface of the Linux system. The information collection file is a virtual file in the Linux system. The information collection file belongs to the virtual file system, and its content is dynamically generated by the kernel and is used to provide detailed information about a specific process. This virtual file system does not store actual disk files but provides an interface to access kernel and process information. The kernel interface includes a process-level status interface and a system-level statistics interface. By accessing the corresponding information collection file through different kernel interfaces, the CPU occupancy information of the target process and the system CPU time can be obtained.

[0019] In some alternative embodiments, the kernel interfaces include / proc / [pid] / stat and / proc / stat, both of which belong to the proc file system. The information collection file is a virtual file system rather than a real disk file, and it is a dynamic mapping of kernel data structures and statistical information. Among them, / proc / [pid] / stat is a process-level status interface, where [pid] is the identifier of the target process. The stat file consists of multiple fields separated by spaces, and these fields can provide CPU occupancy information of the process, including user-mode CPU time, kernel-mode CPU time, memory occupancy, information processing, etc. The CPU occupancy information of the target process can be extracted through the / proc / [pid] / stat interface. / proc / stat is a system-level statistical interface used to provide cumulative time statistics of the CPU and various task activities since the system was started, including providing CPU time statistics, such as system CPU time, system startup time, total number of process creations, etc. The system CPU time can be extracted through the / proc / stat interface.

[0020] The entry point of the entire process monitoring process when the system starts can be triggered by the initialization script of the baseboard management controller or an external management controller. The external management controller can be a superior management module of the server BMC. After the monitoring process starts, the monitoring parameters can be initialized, including setting the sampling period, dynamic threshold, sliding time window, process monitoring, etc.

[0021] Among them, the dynamic threshold is used to determine whether there is an abnormality, and the sampling period is a preset sampling time interval. In some alternative embodiments, the preset sampling time interval is 5 seconds, that is, the target process is sampled every 5 seconds to obtain the CPU occupancy information of the target process and the system CPU time.

[0022] The target process represents the process to be monitored. After initializing the monitoring parameters, based on the preset sampling time interval, the CPU occupancy information of the target process and the system CPU time are regularly extracted through the kernel interface. The CPU occupancy information includes the user-mode CPU time and kernel-mode CPU time of the target process (both in units of jiffies), and the CPU usage rate of the target process at the sampling moment is further calculated according to the collected CPU occupancy information and system CPU time. Specifically, the CPU usage rate can be calculated through the difference in CPU occupancy information at two adjacent sampling moments.

[0023] CPU utilization rate is a key metric for measuring the proportion of CPU resources occupied by a system or process, usually expressed as a percentage, reflecting the proportion of time the CPU spends processing tasks within a specific time period (e.g., 50% means the CPU is busy executing tasks half of the time and idle the other half). Its calculation is based on the time allocation of the CPU in the user state (executing application code), kernel state (processing system calls), and idle state (when there are no tasks). High utilization rates (such as continuously approaching 100%) may indicate high system load or process resource competition, while low utilization rates may mean that CPU resources are not fully utilized.

[0024] Step S102: Write the CPU utilization rates corresponding to multiple sampling moments into a preset sliding time window, and calculate the target parameter based on the CPU utilization rates within the preset sliding time window.

[0025] Among them, the target parameter is used to characterize the CPU usage situation corresponding to the target time period. The target quantity is a value set during the parameter initialization stage. The CPU occupancy information of the target process is collected regularly based on the preset sampling time interval, and the CPU occupancy information of the target quantity is collected. That is to say, the number of CPU occupancy information collected within the target time period is the target quantity, and the target time period is a fixed value determined based on the target quantity and the preset sampling time interval.

[0026] Calculate the target parameter within the target time period based on the CPU utilization rates corresponding to multiple sampling moments. The target parameter can be set according to the actual situation and is used to characterize the CPU usage situation, which may include the average value of the CPU utilization rate within the target time period, the maximum value of the CPU utilization rate within the target time period, etc.

[0027] The preset sliding time window is a time interval with a fixed length that slides forward with a fixed step size. It can be implemented through a queue data structure. The length of this queue is fixed and follows the first-in-first-out principle. In this embodiment, the target time period is the preset sliding time window, and the target quantity is determined by setting the size of the sliding time window. That is, set to retain 10 sampling points within the sliding time window. Correspondingly, the target quantity is 10.

[0028] Set up a circular buffer. The circular buffer is an array of a fixed size and can be used to circularly store raw data of a fixed capacity. In this embodiment, the raw data sampled is the CPU utilization rate collected at different sampling times. The circular buffer is used as the underlying physical storage of the preset sliding time window. First, an array of a fixed size can be allocated, and the collected CPU utilization rate is stored in the circular buffer. According to the size of the preset sliding time window (for example, 10 sampling points), traverse the circular buffer to extract the CPU utilization rates at the most recent 10 sampling times from the circular buffer and write them into the preset sliding time window. After the timer triggers the sampling at each sampling time and calculates the CPU utilization rate, the CPU utilization rate at the new sampling time is stored in the circular buffer, and then the circular buffer is read through incremental update, so as to write the CPU utilization rate at the latest time into the preset sliding time window and replace the oldest element in the preset sliding time window with the CPU utilization rate at the latest sampling time. Calculate the target parameter according to the CPU utilization rate within the preset sliding time window.

[0029] In this step, through the preset sliding time window, the CPU utilization rates corresponding to the target number of sampling times can be aggregated and calculated, so as to filter out instantaneous fluctuations (such as CPU burst peaks), provide a more accurate basis for subsequent abnormal state judgment, and avoid triggering false alarms. Using the circular buffer to pre-store the CPU utilization rate and then extracting data from the circular buffer and writing it into the preset time window, this operation can keep the memory occupancy constant. When updating the CPU utilization rate at the latest sampling time, obtain the CPU utilization rate at the latest sampling time from the circular buffer through incremental update, without full traversal, improve the efficiency of data collection, and occupy less memory.

[0030] Step S103, analyze the target parameter and the CPU utilization rate based on a preset threshold to determine the CPU state of the target process.

[0031] Among them, the CPU state includes an abnormal state. The preset threshold is a standard value preset for judging whether the CPU usage is normal. The preset threshold can be configured according to actual requirements, system performance requirements, and the characteristics of the target process, including the threshold corresponding to the target parameter and the threshold corresponding to the CPU utilization rate. The preset threshold can include an upper limit threshold and a lower limit threshold, or it can be a single value. Compare the target parameter with the preset threshold. As an example, if the target parameter (such as the average value) exceeds the preset upper limit threshold, it may indicate that the target process consumes too much CPU resources during the target time period. If the target parameter is lower than the preset lower limit threshold, it may indicate that the CPU resources are not fully utilized.

[0032] In addition to analyzing the target parameter, the CPU utilization rate can also be analyzed, and the CPU utilization rate is compared with the corresponding preset threshold to judge whether the CPU usage of the target process is normal at this moment.

[0033] Based on multiple preset thresholds, multiple conditions for determining the CPU status are set. The target parameter is comprehensively judged to see if it meets the corresponding judgment conditions. When multiple conditions are met, the CPU status can be determined as an abnormal status.

[0034] The process monitoring method of the baseboard management controller provided by the embodiment of the present invention includes continuously collecting the CPU occupancy information of the target process from the information collection file through the kernel interface based on a preset sampling time interval, calculating the CPU usage rate of the target process based on the CPU occupancy information at adjacent sampling moments, then writing the CPU usage rates corresponding to multiple sampling moments into a preset sliding time window, and calculating a target parameter based on the CPU usage rate within the preset sliding time window. The target parameter is used to characterize the CPU usage situation corresponding to the target time period; analyzing the target parameter and the CPU usage rate based on preset thresholds to determine the CPU status of the target process. The CPU status includes an abnormal status. This method samples the CPU occupancy information of the target process and the system CPU time periodically, so as to continuously calculate the CPU usage rate of each process, analyze the CPU usage situation of the target process based on the sliding time window, without manual intervention, can automatically perform sampling and analysis, and can monitor in real time whether there is an abnormality, improving the monitoring efficiency of the target process of the baseboard management controller.

[0035] In this embodiment, a process monitoring method of a baseboard management controller is provided, and the method includes the following steps: Step S201, continuously collect the CPU occupancy information of the target process and the system CPU time from the kernel interface based on a preset sampling time interval, and calculate the CPU usage rate of the target process based on the CPU occupancy information and the system CPU time at adjacent sampling moments.

[0036] Specifically, the CPU occupancy information includes the user-mode CPU time and the kernel-mode CPU time. Step S201 includes: Step S2011, determine the user-mode CPU time increment based on the difference between the first user-mode CPU time at the first moment and the second user-mode CPU time at the second moment.

[0037] The first moment and the second moment are two consecutive sampling moments, and the second moment is after the first moment. Read the first user-mode CPU time of the target process through the kernel interface at the first moment, and read the second user-mode CPU time of the target process from the first file at the second moment, calculate the difference between the two to obtain the user-mode CPU time increment. The user-mode CPU time increment represents the change in the CPU time consumed by the target process in the user mode between two samplings.

[0038] Step S2012: Determine the kernel-mode CPU time increment based on the difference between the first kernel-mode CPU time at the first moment and the second kernel-mode CPU time at the second moment.

[0039] Read the first kernel-mode CPU time of the target process through the kernel interface at the first moment, read the second kernel-mode CPU time of the target process from the first file at the second moment, calculate the difference between the two to obtain the kernel-mode CPU time increment. The kernel-mode CPU time increment represents the change in the CPU time consumed by the target process in the kernel mode between two samplings.

[0040] Step S2013: Determine the system CPU time increment based on the difference between the first system CPU time at the first moment and the second system CPU time at the second moment.

[0041] Read the first system CPU time of the target process through the kernel interface at the first moment, read the second system CPU time of the target process through the kernel interface at the second moment, calculate the difference between the two, and calculate the ratio of the difference to the first moment and the second moment to obtain the system CPU time increment. The system CPU time increment represents the total amount of CPU time actually consumed by the target process in the kernel mode within the time interval between two samplings.

[0042] As an example, let the first system CPU time be total_time1, the second system CPU time be total_time2, the first moment be t1, the second moment be t2, and the system CPU time increment = (total_time2 - total_time1) / (t2 - t1).

[0043] Step S2014: Calculate the sum of the user-mode CPU time increment and the kernel-mode CPU time increment to obtain the total CPU time increment.

[0044] The total CPU time increment represents the total CPU time (including user mode and kernel mode) consumed by the target process between two samplings.

[0045] Obtain the total CPU time increment by calculating the sum of the user-mode CPU time increment and the kernel-mode CPU time increment between the first moment and the second moment.

[0046] As an example, let the first moment be t1, the second moment be t2, the first user-mode CPU time be utime1, the second user-mode CPU time be utime2, the first kernel-mode CPU time be stime1, and the second kernel-mode CPU time be stime2. The user-mode CPU time increment = utime2 - utime1, and the kernel-mode CPU time increment = stime2 - stime1.

[0047] Total CPU time increment = (utime2 - utime1 + stime2 - stime1) / (t2 - t1).

[0048] Step S2015: Calculate the CPU usage rate based on the total CPU time increment and the system CPU time increment.

[0049] Calculate the ratio of the total CPU time increment to the system CPU time increment to obtain the CPU usage rate of the target process.

[0050] As an example, CPU usage rate = (total CPU time increment / system CPU time increment) × 100%.

[0051] Among them, the units of user-mode CPU time, kernel-mode CPU time, and system CPU time are jiffies, and jiffies can be converted to seconds according to requirements when calculating the CPU usage rate.

[0052] Read the user-mode CPU time, kernel-mode CPU time, and system CPU time through the kernel interface by sampling, calculate the CPU usage rate of the target process by combining the differences between two samplings, achieve precise monitoring, control the monitoring cost, and facilitate integration for trend analysis, which is applicable to anomaly detection and system performance management in resource-constrained environments.

[0053] As an example, CPU occupancy information can be read based on cat / proc / [pid] / stat#, and the system CPU time can be read based on / proc / stat.

[0054] Step S202: Calculate the target parameter based on the CPU usage rates of the target quantity.

[0055] Specifically, step S202 includes: Step S2021: Obtain the CPU usage rate at each sampling moment within the first target time period based on the preset sliding time window.

[0056] Among them, the number of CPU usage rates within the first target time period is the target quantity. The sliding time window is a data structure used to maintain a window of a fixed size, and the data within the window is dynamically updated as new data is added. The size of the preset sliding time window is determined by the target quantity, that is, the number of CPU usage rate data points retained within the window is fixed. After each sampling, the new CPU usage rate data is added to the sliding time window, and the oldest data point in the window is removed.

[0057] The first target time period refers to the time range covered by the current sliding time window, and the number of CPU usage data points within this time period is equal to the target number. For example, if the target number is 10, the sliding time window will always retain the CPU usage at the most recent 10 sampling moments.

[0058] Step S2022: Calculate the first target parameter corresponding to the first target time period based on the CPU usage at each sampling moment within the first target time period.

[0059] Among them, the first target parameter is used to characterize the CPU usage situation corresponding to the first target time period. The first target parameter is calculated based on the CPU usage data within the first target time period and is used to characterize the CPU usage situation within this time period. The target parameter may include the average value, maximum value, standard deviation, minimum value, etc. of the CPU usage within the target time period.

[0060] In some optional embodiments, step S202 further includes: Step S2023: Obtain the CPU usage at the next sampling moment after the last sampling moment within the first target time period.

[0061] The first target time period consists of a series of consecutive sampling moments, and the CPU usage data at the sampling moments is used to calculate the first target parameter. After the last sampling moment within the first target time period, the system will perform the next sampling to obtain new CPU usage data, that is, the CPU usage at the next sampling moment.

[0062] Step S2024: Replace the CPU usage at the first sampling moment within the first target time period with the CPU usage at the next sampling moment to obtain the CPU usage at each sampling moment within the second target time period, and the number of CPU usage data within the second target time period is the target number.

[0063] Update the CPU usage data based on the sliding time window. The size of the sliding time window (i.e., the target number) is fixed, indicating that at any moment, the window retains the CPU usage data at a certain number of the most recent sampling moments. Remove the CPU usage data at the first sampling moment within the first target time period, and add the CPU usage data at the next sampling moment to the sliding time window to become the new last data point within the window. The data in the sliding time window is updated to the CPU usage data within the second target time period, and the number of data points is still equal to the target number.

[0064] Step S2025: Calculate a second target parameter corresponding to the second target time period based on the CPU usage rate at each sampling moment within the second target time period. The second target parameter is used to characterize the CPU usage condition corresponding to the second target time period.

[0065] The second target parameter is calculated based on the CPU usage rate data within the second target time period, used to characterize the CPU usage condition during this time period. Calculate the second target parameter according to the CPU usage rate data within the second target time period, including the maximum value, minimum value, average value, etc.

[0066] By continuously updating the sliding time window and calculating new target parameters, the CPU usage condition of the target process at different time periods can be dynamically reflected.

[0067] As an example, as Figure 2 shown, introduce the sliding time window mechanism for smoothing processing and anomaly judgment to improve stability and reduce false alarms. The parameters involved are as follows:

[0068] First, initialize the window structure and set N to determine the size of the preset sliding time window. Then clear the window content, that is, delete all the data saved in the window structure U[i]. For example, if the window size is 10, set the data from U[0] to U[9] to 0. Trigger data collection every T seconds based on the timer to obtain the CPU usage rate. After obtaining a new sampling value, add the new value to the window U[i] to replace the oldest element. Finally, calculate the average value Avg, maximum value Max, standard deviation StdDev, and the deviation Delta between the current value and the mean within the window.

[0069] This method uses a sliding window to collect the CPU occupancy information and system CPU time of the same process at different time points. Based on the total system time as a benchmark, it can eliminate the sampling time drift error, facilitate more accurate analysis of the CPU state, and improve the process monitoring efficiency.

[0070] Step S203: Analyze the target parameter and CPU usage rate based on a preset threshold to determine the CPU state of the target process.

[0071] The preset threshold includes a first usage rate threshold, a second usage rate threshold, and a proportion threshold. The target parameter includes the average CPU usage rate. Specifically, Step S203 includes: If there is any CPU usage rate greater than the first usage rate threshold and the duration of the CPU usage rate being greater than the first usage rate threshold exceeds the first preset duration, the average CPU usage rate of the target process in the target time period is greater than the second usage rate threshold, the proportion of idle processes is less than the proportion threshold and the duration exceeds the second preset duration, then it is determined that the CPU status of the target process is an abnormal status.

[0072] The preset thresholds include the first usage rate threshold, the first preset duration, the second usage rate threshold, the proportion threshold, and the second preset duration. Among them, the first usage rate threshold is used to represent the upper limit of the CPU usage rate. The second preset duration is a time threshold used to determine whether the high-load state lasts long enough to avoid misjudging as abnormal due to instantaneous high load. The second usage rate threshold is used to represent the upper limit of the average CPU usage rate of the target process within a period of time. The proportion threshold is used to represent the lower limit of the proportion of idle processes. A value lower than this may indicate a relatively high overall CPU load of the system. The second preset duration is used to determine whether the low-idle state lasts long enough to avoid misjudging as abnormal due to instantaneous low idle.

[0073] It is set that when the following conditions are met, the CPU status of the target process is an abnormal status, including: (1) Any CPU usage rate is greater than the first usage rate threshold and the duration exceeds the first preset duration; (2) The average CPU usage rate of the target process in the target time period is greater than the second usage rate threshold; (3) The proportion of system idle processes is less than the proportion threshold and the duration exceeds the second preset duration.

[0074] In this embodiment, when the above conditions are met, the target process is determined as an abnormal process and the CPU status of the target process is an abnormal status.

[0075] As a specific implementation, the first usage rate threshold is 80%, the first preset duration is 5 seconds, the second usage rate threshold is twice the average value of the process group, and the proportion threshold is 10%.

[0076] Furthermore, the method further includes: if it is determined that the CPU status of the target process is an abnormal status, then generate an abnormal event and store it in the abnormal event queue; consume events from the abnormal event queue and execute preset operations. Among them, the preset operations include one or more of log recording, remote event reporting, automatically restarting the target process, and restricting the CPU usage rate of the target process.

[0077] When it is determined that the CPU state of the target process is an abnormal state, a corresponding abnormal event is generated and written into the abnormal event queue. Specifically, a message queue can be used to store the abnormal events, and the data structure of the abnormal event is defined, including the time when the abnormality occurs, the identifier of the target process, the type of the abnormality, and possible reasons for the abnormality or relevant context information. By writing the abnormal events into the abnormal event queue, data loss can be guaranteed, and the abnormal events can be processed preferentially according to their priorities. Historical data support can be provided for subsequent troubleshooting, performance optimization, and system maintenance.

[0078] Start one or more independent threads or processes to process the abnormal events in the event queue. Specifically, the response policy can be defined through a configuration file or a database. Specifically, preset operations can be executed according to the type of the abnormal event. By consuming the abnormal events from the queue through independent threads or processes, blocking the main program can be avoided.

[0079] Furthermore, the system will control the target process to execute corresponding operations to handle different abnormal events according to preset rules or policies, including one or more of logging, remote event reporting, automatically restarting the target process, and restricting the CPU usage of the target process.

[0080] When the target process is abnormal due to high CPU usage or other reasons, the system can automatically trigger the restart operation of the process. The restart operation will terminate the currently running target process instance and start a new process instance to continue executing the task. For example, when a service process or a background task process has an abnormality, it can quickly resume the service through restarting, reducing the impact on users.

[0081] In addition, the CPU usage can also be restricted by adjusting the priority of the target process, setting the CPU affinity, or using resource limiting tools. Restricting the CPU usage is applicable to processes that have low requirements for real-time performance but need to run for a long time. For example, when the CPU usage of a data analysis task or a batch job is too high, its CPU usage can be restricted to avoid affecting the overall performance of the system.

[0082] The technical solution provided in this embodiment uses a message queue to store abnormal events and defines a detailed data structure that includes the time of abnormal occurrence, the target process identifier, the type of abnormality, and relevant context information. This not only ensures the integrity and persistence of abnormal event data, avoiding data loss, but also provides rich historical data support for subsequent troubleshooting, performance optimization, and system maintenance. At the same time, by starting an independent thread or process to handle abnormal events in the event queue, it effectively avoids blocking the main program and ensures the stable operation of the main program. In terms of the response strategy, it can be flexibly defined through a configuration file or a database, and can automatically execute preset operations such as logging, remote event reporting, automatically restarting the target process, and restricting the CPU usage of the target process according to the type of abnormal event. This decouples the abnormal trigger mechanism and the response strategy. This decoupling design enables the system to flexibly adjust the response strategy according to different business requirements and scenarios, improving the adaptability and scalability of the system. Especially when the target process is abnormal due to high CPU usage or other reasons, the system can automatically trigger the process restart operation to quickly restore the service and reduce the impact on users. For processes that have low requirements for real-time performance but need to run for a long time, the system can limit their CPU usage by adjusting the process priority or using resource limit tools, avoiding excessive impact on the overall system performance.

[0083] Therefore, in this embodiment, by independently configuring the abnormal trigger module and the response strategy, the decoupling of policy definition and execution is achieved, improving the flexibility, scalability, and stability of the system, and providing a strong guarantee for the long-term operation and maintenance of the system.

[0084] Furthermore, the method further includes: if it is determined that the CPU status of the target process is an abnormal status, performing an alarm process based on a preset method.

[0085] After the system determines that the CPU status of the target process is an abnormal status, in addition to recording the abnormal event and controlling the target process to execute preset operations, it is also necessary to perform an alarm process through a preset method. The main purpose of the alarm process is to quickly notify relevant personnel when the CPU status of the target process is abnormal, so that they can timely understand the situation and take corresponding handling measures. By giving an alarm in a timely manner, the impact of the abnormal status on system performance, user experience, or business continuity can be reduced, and the problem can be prevented from deteriorating further. The preset alarm methods include email alarm, SMS alarm, etc. Specifically, the SEL (System Event Log) in the intelligent platform management interface can be used to record abnormal events and perform alarm processing.

[0086] In some alternative embodiments, the method further includes: obtaining status data corresponding to the CPU status of the target process and alarm events based on a preset interface layer; encapsulating the status data in a preset format, and displaying the CPU status and corresponding alarm events on a preset page.

[0087] The preset interface layer is a standardized output layer, which is used to provide a unified and standardized data access interface, so that external systems (such as Web interfaces) can easily obtain relevant information such as status data corresponding to the CPU status of the target process and alarm events. Optionally, the preset interface layer can adopt the RESTful Redfish API (an open standard interface designed based on the RESTful architecture style) as a means of data query. The preset interface layer establishes a connection with the target process through a specific communication protocol (such as system calls, inter-process communication, etc.), and collects key information such as status data corresponding to the CPU status and alarm events in real time or at regular intervals.

[0088] The obtained status data and alarm events need to be encapsulated and formatted for subsequent transmission and display. In this embodiment, a JSON format is used to encapsulate the multi-level data structure. The JSON format has the advantages of strong readability, good scalability, and easy parsing. During the encapsulation process, the CPU status data and alarm events are respectively organized into different data structures, and a clear multi-level data structure is constructed through the nesting of JSON objects and attribute settings. For example, for the CPU status data, it can be encapsulated as a JSON object containing attributes such as process name, current CPU occupancy rate, and the timestamp of the last CPU occupancy time; for the alarm events, it can be encapsulated as a JSON object containing attributes such as event type, event time, and event description.

[0089] To meet the data requirements in different scenarios, this embodiment supports the independent channel return of periodic sampling data and alarm events. Periodic sampling data refers to the CPU status data of the target process collected at a certain time interval (such as every minute, every hour), which is mainly used to analyze the historical trend of CPU load. Alarm events are generated in real time when abnormal situations occur in the target process and need to be notified to relevant personnel for processing in a timely manner. Returning these two types of data through independent channels can avoid data confusion and improve the efficiency and accuracy of data processing. For example, the periodic sampling data can be returned through a dedicated API interface, while the alarm events can be pushed through another independent interface or message queue.

[0090] The preset page is the BMC Web interface, which is the main window for users to interact with the system. In order to graphically display data trends and anomaly alarm histories in the BMC Web interface, the standardized output layer needs to transfer the encapsulated JSON data to the BMC Web interface. In the BMC Web interface, by using a chart library and a front-end framework, the JSON data is parsed and rendered into intuitive charts and lists, such as a line chart showing the historical trend of CPU load and a table showing the detailed information of alarm events. At the same time, the BMC Web interface can also provide interactive functions. For example, users can view detailed information by clicking on data points in the chart and set alarm thresholds.

[0091] The technical solution provided in this embodiment realizes the standardized output and efficient display of the CPU status information of the target process by designing a standardized output layer, encapsulating data in JSON format, supporting the independent channel return of periodic sampling data and alarm events, and displaying the CPU status and corresponding alarm events on the preset interface, providing support for the management and monitoring of the system, and can be used in scenarios of large-scale remote cluster management.

[0092] In some alternative embodiments, a recovery function for abnormal processes can be configured to start the recovery function when the target process is detected to be in an abnormal state.

[0093] In some alternative embodiments, the monitoring system of this method adopts an independent four-layer architecture of "monitoring - analysis - triggering - response". Each layer has independent functions, and some modules can be selectively enabled according to the actual situation of the platform. This structure has good platform compatibility and scalability. By constructing a four-stage asynchronous model of "detection - judgment - triggering - response", it allows the decoupling of policy definition and execution. Among them, the anomaly triggering module and the response policy are independently configured and do not depend on a unified service process, supporting the configuration of actions such as "logging, Redfish event (a mechanism defined in the Redfish standard for notifying management clients when specific situations occur in server hardware or management software), service restart".

[0094] In this embodiment, a method for monitoring the processes of a baseboard management controller is provided. As Figure 3 shown, first, start the entry point of the monitoring system, which can be specifically triggered by system initialization or an external controller. Initialize the monitoring parameters, including setting the sampling frequency, the threshold for judging abnormal states, etc. By reading / proc / <pid>The / stat file (the first file) obtains the CPU occupancy information of a specific process, including user-mode time and kernel-mode time, and calculates the CPU usage rate. The CPU usage rate is written into a preset circular buffer for storing a certain amount of historical data. The sliding average algorithm is used to smooth out fluctuations. For example, the average value of the last 5 samples is calculated to avoid false alarms triggered by short-term spikes. By comparing the current sliding average value with the historical trend, analyze whether there are situations such as continuous increase, sudden increase, abnormal fluctuations, etc. Algorithms such as simple linear regression can be combined to assist in judging the trend. Determine whether the current or trend average value exceeds the set threshold. If not, it means that no anomaly is detected, and the next round of monitoring process can continue, and sampling can continue; if so, write to the system log, trigger the alarm mechanism, and perform process control operations. Among them, writing to the system log includes recording the anomaly time, occupancy rate, process name, etc. Triggering the alarm mechanism includes log reporting, email notification, etc. Performing process control operations includes automatically restarting the process, restricting its CPU occupancy, etc. If the process is bound to a specific hardware interface, update its status cache to maintain the consistency of subsequent data, such as for display, reporting, or decision-making. Finally, wait for the next sampling period, which can be triggered by a timer.

[0095] This method realizes automatic data collection without manual intervention by periodically sampling the / proc / [pid] / stat and / proc / stat interfaces, and performs data aggregation and trend judgment based on the sliding time window mechanism. It supports second-level sampling and sliding time window aggregation, realizes real-time analysis of the CPU usage rate of each process in the BMC system, and can configure monitoring strategies to meet the resource management requirements of different platforms. By setting thresholds and analyzing the change trend of the CPU usage rate, abnormal behaviors such as high occupancy and infinite loop can be actively identified. Once the preset conditions are triggered, logs will be recorded, abnormal events will be reported, and restart operations will be executed, effectively preventing the entire BMC system from responding sluggishly or even getting out of control due to the anomaly of a single process. Without introducing additional hardware, the complete function can be achieved only by using the interfaces provided by the BMC Linux operating system itself, avoiding the use of heavy monitoring frameworks or relying on external system services, greatly reducing the resource load, and conforming to the lightweight design principle of embedded systems. The monitoring system of the present invention encapsulates the sampling, analysis, triggering, and response modules into task units that can be independently registered, and defines module registration interfaces. All underlying sampling operations are based on the standard Linux / proc file system without relying on the private framework of BMC manufacturers. Compared with the existing manual collection method, the present invention is more automated, has higher accuracy, lower overhead, and increases the recovery ability of the baseboard management controller.

[0096] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.

[0097] An embodiment of the present application further provides a process monitoring system for a baseboard management controller, as Figure 4 shown, including: A sampling module that continuously collects the CPU occupancy information and system CPU time of a target process from an information collection file through a kernel interface based on a preset sampling time interval, and calculates the CPU usage rate of the target process based on the CPU occupancy information and system CPU time at adjacent sampling moments. The CPU usage rate corresponds one-to-one with the sampling moment, and the CPU occupancy information includes user-mode CPU time and kernel-mode CPU time; A first analysis module for writing the CPU usage rates corresponding to multiple sampling moments into a preset sliding time window, and calculating a target parameter based on the CPU usage rates within the preset sliding time window. The target parameter is used to characterize the CPU usage situation corresponding to a target time period; A second analysis module for analyzing the target parameter and the CPU usage rate based on a preset threshold to determine the CPU status of the target process. The CPU status includes an abnormal status.

[0098] In some optional embodiments, the sampling module includes: A first increment determination unit for determining a user-mode CPU time increment based on the difference between the first user-mode CPU time at a first moment and the second user-mode CPU time at a second moment; A second increment determination unit for determining a kernel-mode CPU time increment based on the difference between the first kernel-mode CPU time at a first moment and the second kernel-mode CPU time at a second moment; A third increment determination unit for determining a system CPU time increment based on the difference between the first system CPU time at a first moment and the second system CPU time at a second moment; A total increment determination unit for obtaining a total CPU time increment based on the difference between the first moment and the second moment, the user-mode CPU time increment, and the kernel-mode CPU time increment; A usage rate determination unit for calculating the CPU usage rate based on the total CPU time increment and the system CPU time increment.

[0099] In some optional embodiments, the first analysis module includes: A first CPU usage rate calculation unit, configured to obtain the CPU usage rate at each sampling moment within a first target time period based on a preset sliding time window, where the number of CPU usage rates within the first target time period is a target number; A first parameter calculation unit, configured to calculate a first target parameter corresponding to the first target time period based on the CPU usage rate at each sampling moment within the first target time period, where the first target parameter is used to characterize the CPU usage condition corresponding to the first target time period.

[0100] In some alternative embodiments, the first analysis module further includes: A second CPU usage rate calculation unit, configured to obtain the CPU usage rate at the next sampling moment after the last sampling moment within the first target time period; A usage rate replacement unit, configured to replace the CPU usage rate at the first sampling moment within the first target time period with the CPU usage rate at the next sampling moment, to obtain the CPU usage rate at each sampling moment within a second target time period, where the number of CPU usage rates within the second target time period is a target number; A second parameter calculation unit, configured to calculate a second target parameter corresponding to the second target time period based on the CPU usage rate at each sampling moment within the second target time period, where the second target parameter is used to characterize the CPU usage condition corresponding to the second target time period.

[0101] In some alternative embodiments, the preset threshold includes at least a first usage rate threshold, a second usage rate threshold, and a proportion threshold, and the target parameter includes at least an average CPU usage rate. The status determination module includes: An abnormality determination unit, configured to determine that the CPU status of the target process is an abnormal status if there is any CPU usage rate greater than the first usage rate threshold and the duration for which the CPU usage rate is greater than the first usage rate threshold exceeds a first preset duration, the average CPU usage rate of the target process within the target time period is greater than the second usage rate threshold, the proportion of idle processes is less than the proportion threshold and the duration exceeds a second preset duration.

[0102] In some alternative embodiments, the system further includes: A trigger module, configured to generate an abnormal event and store it in an abnormal event queue if it is determined that the CPU status of the target process is an abnormal status; A response module, configured to consume events from the abnormal event queue and perform a preset operation, where the preset operation includes one or more of log recording, remote event reporting, automatically restarting the target process, and restricting the CPU usage rate of the target process.

[0103] In some alternative embodiments, the system further includes: A data acquisition unit, configured to obtain status data corresponding to the CPU status of the target process and alarm events based on a preset interface layer.

[0104] A data encapsulation unit, configured to obtain status data corresponding to the CPU status of the target process and alarm events based on a preset interface layer.

[0105] For the description of the features in the corresponding embodiments of the process monitoring system of the baseboard management controller, reference can be made to the relevant description in the corresponding embodiments of the process monitoring method of the baseboard management controller, which will not be elaborated here one by one.

[0106] An embodiment of the present application further provides a computer device, as Figure 5 shown, including a memory 10 and a processor 20. A computer program is stored in the memory 10, and the processor 20 is configured to run the computer program to execute the steps in any of the above embodiments of the process monitoring method of the baseboard management controller.

[0107] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above embodiments of the process monitoring method of the baseboard management controller when running.

[0108] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical disks and other media that can store computer programs.

[0109] An embodiment of the present application further provides a computer program product. The above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the process monitoring method of the baseboard management controller.

[0110] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above embodiments of the process monitoring method of the baseboard management controller.

[0111] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner 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 implementation should not be considered to exceed the scope of this application.

[0112] The above has introduced in detail a process monitoring method, system, device, and medium of a substrate management controller provided by this application. Specific examples are used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.< / pid>

Claims

1. A process monitoring method for a baseboard management controller, characterized in that, The method includes: Continuously collecting the CPU occupancy information and system CPU time of the target process from the information collection file through a kernel interface based on a preset sampling time interval, and calculating the CPU usage rate of the target process based on the CPU occupancy information and system CPU time at adjacent sampling moments. The CPU usage rate corresponds one-to-one with the sampling moments. The CPU occupancy information includes user-mode CPU time and kernel-mode CPU time; Writing the CPU usage rates corresponding to multiple sampling moments into a preset sliding time window, and calculating a target parameter based on the CPU usage rates within the preset sliding time window. The target parameter is used to characterize the CPU usage situation corresponding to a target time period; Analyzing the target parameter and the CPU usage rate based on a preset threshold to determine the CPU status of the target process. The CPU status includes an abnormal status.

2. The method according to claim 1, characterized in that, The calculating the CPU usage rate of the target process based on the CPU occupancy information and system CPU time at adjacent sampling moments includes: Determining the user-mode CPU time increment based on the difference between the first user-mode CPU time at the first moment and the second user-mode CPU time at the second moment; Determining the kernel-mode CPU time increment based on the difference between the first kernel-mode CPU time at the first moment and the second kernel-mode CPU time at the second moment; Determining the system CPU time increment based on the difference between the first system CPU time at the first moment and the second system CPU time at the second moment; Obtaining the total CPU time increment based on the difference between the first moment and the second moment, the user-mode CPU time increment, and the kernel-mode CPU time increment; Calculating the CPU usage rate based on the total CPU time increment and the system CPU time increment.

3. The method according to claim 1, wherein The calculating the target parameter based on the CPU usage rates within the preset sliding time window includes: Obtaining the CPU usage rate at each sampling moment within a first target time period based on the preset sliding time window. The number of CPU usage rates within the first target time period is the target number; Calculating a first target parameter corresponding to the first target time period based on the CPU usage rates at each sampling moment within the first target time period. The first target parameter is used to characterize the CPU usage situation corresponding to the first target time period.

4. The method according to claim 3, wherein The calculating the target parameter based on the CPU usage rates within the preset sliding time window, the method further includes: Obtaining the CPU usage rate at the next sampling moment after the last sampling moment within the first target time period; Replacing the CPU usage rate at the first sampling moment within the first target time period with the CPU usage rate at the next sampling moment to obtain the CPU usage rates at each sampling moment within a second target time period. The number of CPU usage rates within the second target time period is the target number; Calculating a second target parameter corresponding to the second target time period based on the CPU usage rates at each sampling moment within the second target time period. The second target parameter is used to characterize the CPU usage situation corresponding to the second target time period.

5. The method according to claim 1, wherein The preset thresholds at least include a first usage rate threshold, a second usage rate threshold, and a proportion threshold, and the target parameter at least includes an average CPU usage rate. Analyzing the target parameter and the CPU usage rate based on the preset thresholds includes: If there is any CPU usage rate greater than the first usage rate threshold and the duration for which the CPU usage rate is greater than the first usage rate threshold exceeds a first preset duration, the average CPU usage rate of the target process in the target time period is greater than the second usage rate threshold, the proportion of idle processes is less than the proportion threshold and the duration exceeds a second preset duration, then it is determined that the CPU status of the target process is an abnormal status.

6. The method according to claim 5, wherein The method further includes: If it is determined that the CPU status of the target process is an abnormal status, an abnormal event is generated and stored in an abnormal event queue; Consume events from the abnormal event queue and perform preset operations, where the preset operations include one or more of logging, remote event reporting, automatically restarting the target process, and restricting the CPU usage rate of the target process.

7. The method according to claim 1, characterized in that, The method further includes: Obtain status data corresponding to the CPU status of the target process and alarm events based on a preset interface layer; Encapsulate the status data in a preset format and display the CPU status and the corresponding alarm events on a preset page.

8. A process monitoring system for a baseboard management controller, characterized in that, The system includes: A sampling module that continuously collects the CPU occupancy information of the target process and the system CPU time from an information collection file through a kernel interface based on a preset sampling time interval, and calculates the CPU usage rate of the target process based on the CPU occupancy information and the system CPU time at adjacent sampling moments. The CPU usage rate corresponds one-to-one with the sampling moment, and the CPU occupancy information includes user-mode CPU time and kernel-mode CPU time; A first analysis module for writing the CPU usage rates corresponding to multiple sampling moments into a preset sliding time window and calculating a target parameter based on the CPU usage rates within the preset sliding time window. The target parameter is used to characterize the CPU usage situation corresponding to the target time period; A second analysis module for analyzing the target parameter and the CPU usage rate based on preset thresholds to determine the CPU status of the target process, where the CPU status includes an abnormal status.

9. The system according to claim 8, characterized in that, The system further includes: A trigger module for generating an abnormal event and storing it in an abnormal event queue if it is determined that the CPU status of the target process is an abnormal status; A response module for consuming events from the abnormal event queue and performing preset operations, where the preset operations include one or more of logging, remote event reporting, automatically restarting the target process, and restricting the CPU usage rate of the target process.

10. A computer device, characterized in that, It includes: A memory for storing a computer program; A processor for implementing the steps of the process monitoring method of the baseboard management controller according to any one of claims 1 to 7 when executing the computer program.

11. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, where the computer program implements the steps of the process monitoring method of the baseboard management controller according to any one of claims 1 to 7 when executed by a processor.

Images