Interface card monitoring method, device, equipment and medium

Abstract

The present invention discloses an interface card monitoring method, device, equipment, and medium, and relates to the field of server technology. This solution obtains a pre-configured dynamic library of each interface card, which contains monitoring item acquisition functions corresponding to multiple monitoring items. This allows the system to add, delete, and modify corresponding monitoring items according to the configuration during runtime, avoiding the need for recompilation and deployment, simplifying the system's configuration and management processes, supporting hot plugging and dynamic expansion of devices, and improving flexibility and maintainability. At the same time, the system collects monitoring results of the monitoring items corresponding to each interface card according to a preset period. When a user's access command is received, the system determines the corresponding target monitoring item according to the access command and returns the corresponding target monitoring result. This ensures that the system does not block upper-layer user responses when collecting monitoring results, thereby improving the real-time and stability of interface card monitoring.

Description

Technical Field

[0001] The present invention relates to the technical field of servers, and in particular to an interface card monitoring method, device, equipment and medium. Background Art

[0002] The Baseboard Management Controller (BMC) serves as the core for monitoring and managing the health of Host Bus Adapter (HBA) cards. It uses a combination of software and hardware to collect HBA card information, report status, and generate fault alarms, ensuring the stability and reliability of server storage pathways.

[0003] However, traditional BMC HBA monitoring solutions have limitations when dealing with a wide variety of HBAs. Monitoring mechanisms are typically pre-compiled into firmware, requiring recompilation and re-deployment of monitoring items. This not only increases maintenance complexity but also reduces system flexibility. Furthermore, due to a lack of cross-vendor interface consistency, HBAs from different vendors may require different monitoring solutions, further complicating management.

[0004] In view of the above, how to solve the poor flexibility and insufficient cross-vendor compatibility of traditional HBA card monitoring solutions is an urgent problem to be solved by technical personnel in this field. Summary of the Invention

[0005] The present invention provides an interface card monitoring method, apparatus, device and medium, which at least solve the problems of poor flexibility and insufficient cross-vendor compatibility in traditional HBA card monitoring solutions.

[0006] The present invention provides an interface card monitoring method, which is applied to an open management controller; the method comprises:

[0007] Obtain the pre-configured dynamic libraries corresponding to each interface card, and register the corresponding interface card based on the initialization function of each dynamic library; wherein the dynamic library contains the initialization function and multiple monitoring item acquisition functions;

[0008] Establish a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function;

[0009] Each monitoring item acquisition function is executed according to a preset period to obtain the monitoring results of the monitoring items corresponding to each interface card, so that when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item.

[0010] The present invention also provides an interface card monitoring device, which is applied to an open management controller; the device comprises:

[0011] The registration module is used to obtain the pre-configured dynamic libraries corresponding to each interface card and register the corresponding interface card based on the initialization function of each dynamic library; wherein the dynamic library contains the initialization function and multiple monitoring item acquisition functions;

[0012] Mapping module, used to establish a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function;

[0013] The acquisition module is used to execute each monitoring item acquisition function according to a preset period to obtain the monitoring results of the monitoring items corresponding to each interface card, so that when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item.

[0014] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any one of the above interface card monitoring methods when executing the computer program.

[0015] The present invention also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned interface card monitoring methods are implemented.

[0016] The beneficial effect of the present invention is that, by obtaining a pre-configured dynamic library of each interface card, the dynamic library contains monitoring item acquisition functions corresponding to multiple monitoring items, so that the system can add, delete, and modify corresponding monitoring items according to the configuration during operation, avoiding the need for recompilation and deployment, simplifying the system configuration and management process, supporting hot plugging and dynamic expansion of equipment, and improving flexibility and maintainability; at the same time, the monitoring results of the monitoring items corresponding to each interface card are collected according to a preset period, and when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is returned, which can ensure that the system will not block the upper-level user response when collecting the monitoring results, thereby improving the real-time and stability of the interface card monitoring.

[0017] In addition, the present invention also provides an interface card monitoring device, equipment and medium, which have the same effects as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A flowchart of an interface card monitoring method provided by an embodiment of the present invention;

[0020] Figure 2 A schematic diagram of an interface card monitoring device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0021] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0022] It should be noted that, in the description of the present invention, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. The terms "first," "second," etc., in the present invention are used to distinguish similar objects, and are not used to describe a particular order or precedence.

[0023] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0024] Currently, traditional BMC monitoring solutions for HBA cards, when used with diverse HBAs, typically implement their monitoring mechanisms through pre-compiled firmware. This requires recompilation and re-deployment of monitoring items to change, increasing maintenance complexity and reducing system flexibility. Furthermore, due to a lack of cross-vendor interface consistency, HBAs from different manufacturers may require different monitoring solutions, further increasing management complexity. In light of the foregoing, the present invention provides an interface card monitoring method.

[0025] It's important to note that the interface card monitoring method provided by this invention is applied to the OpenBaseboard Management Controller (OpenBMC). OpenBMC is an open-source, programmable, and scalable BMC operating system platform suitable for enterprises requiring highly customized and automated management. OpenBMC provides a more open development interface, a Desktop Bus (D-Bus) architecture, and flexible Redfish / IPMI support, facilitating cross-vendor adaptation and dynamic management.

[0026] Figure 1 The flowchart of an interface card monitoring method provided by an embodiment of the present invention. Figure 1 As shown, the method includes:

[0027] S10: Obtain the pre-configured dynamic libraries corresponding to the respective interface cards, and register the corresponding interface cards based on the initialization functions of the dynamic libraries, wherein the dynamic libraries contain the initialization functions and multiple monitoring item acquisition functions.

[0028] Specifically, first, the pre-configured dynamic libraries and header files for the standard interfaces corresponding to each interface card are obtained. It should be noted that an interface card is a hardware component used to expand computer functionality or connect to external devices, and includes, but is not limited to, HBA cards, graphics cards, sound cards, and network interface cards. This embodiment does not limit the specific type of interface card. The header file is used to indicate information about each function / class in the compiler, and the dynamic library provides runtime monitoring functions.

[0029] It should be noted that the dynamic library can be provided by the interface card manufacturer or can be self-written and encapsulated, which is not a limitation in this embodiment. At the same time, the corresponding interface card is registered based on the initialization function of each dynamic library so that OpenBMC can recognize the interface card and perform the necessary initialization on the interface card to prepare for subsequent acquisition of interface card data.

[0030] S11: Establish a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function.

[0031] Furthermore, a monitoring item acquisition function refers to a function specifically implemented in a dynamic library. For example, if the monitoring item is HBA card temperature, a corresponding function for obtaining the HBA card temperature must be found in the dynamic library. However, if there is no corresponding mapping relationship, the corresponding function cannot be found to obtain the HBA card temperature. Therefore, a mapping relationship is established between the monitoring items of each interface card and the corresponding monitoring item acquisition function.

[0032] S12: Execute each monitoring item acquisition function according to a preset period to obtain the monitoring results of the monitoring items corresponding to each interface card, so that when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item.

[0033] After each monitoring item is mapped to a specific function in the dynamic library through configuration, a unified scheduling timer system is added, such as libevent or system timer. The scheduler calls each function regularly according to the preset period and uses the monitoring results of each monitoring item of the interface card obtained by the function.

[0034] It should be noted that, in this embodiment, there is no restriction on the size of the preset period, and there is no restriction on the specific process of obtaining the monitoring results, which depends on the specific implementation situation.

[0035] Finally, when the user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is directly obtained from the collected monitoring results according to the target monitoring item, which improves the real-time performance and stability of the system.

[0036] In this embodiment, by obtaining a pre-configured dynamic library of each interface card, the dynamic library contains monitoring item acquisition functions corresponding to multiple monitoring items, so that the system can add, delete, and modify corresponding monitoring items according to the configuration during operation, avoiding the need for recompilation and deployment, simplifying the system configuration and management process, supporting hot plugging and dynamic expansion of equipment, and improving flexibility and maintainability; at the same time, the monitoring results of the monitoring items corresponding to each interface card are collected according to the preset period. When the user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is returned, which can ensure that the system will not block the upper-level user response when collecting the monitoring results, thereby improving the real-time and stability of the interface card monitoring.

[0037] In order to adjust the configuration of interface card monitoring items, based on the above embodiment, in some embodiments, before obtaining the pre-configured dynamic library corresponding to each interface card, the following is further included:

[0038] S14: When a new configuration file uploaded by the user is received through the configuration interface, the local configuration file is updated according to the new configuration file;

[0039] S15: Determine the monitoring items to be modified based on the new configuration file;

[0040] S16: Establish a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function.

[0041] It should be noted that the purpose of adjusting the configuration of monitoring items is: in the data center, the interface card types, sensor types, and supported monitoring items provided by different suppliers are not consistent. For example, some cards have "temperature" and "voltage" sensors, while other cards may also have "current" or "link status". Through dynamic configuration adjustment, selective monitoring can be carried out according to specific equipment to avoid invalid or erroneous monitoring operations.

[0042] Therefore, in this embodiment, a D-Bus interface of the interface card monitoring module of OpenBMC is used as a configuration interface to receive configuration files uploaded by users. It should be noted that in the BMC system, a configuration file refers to some static or dynamic information read by the system or service during startup or operation, and is used to control behaviors such as hardware monitoring, sensor management, device topology, network settings, function switches, etc., and is usually in the form of JSON, YAML, INI, conf, environment variables, etc. In this embodiment, there is no restriction on the specific format of the configuration file. For example, a json configuration file can be used, which supports dynamic settings through the D-Bus interface, including adding, modifying, and deleting monitoring item configurations.

[0043] In a specific implementation, when a new configuration file uploaded by a user is received through the configuration interface, the local configuration file is updated based on the new configuration file. Simultaneously, the monitoring items to be modified are determined based on the new configuration file. It is understood that the monitoring items to be modified can be monitoring items to be added, deleted, or modified. Preferably, a mapping relationship is established between the monitoring items to be modified and the corresponding monitoring item acquisition functions.

[0044] In this embodiment, the configuration file is dynamically modified using the configuration interface to implement the addition, deletion and modification of monitoring items, avoiding the need for recompilation and deployment, and simplifying the system configuration and management process.

[0045] Based on the above embodiment, in some embodiments, the process of generating a new configuration file includes:

[0046] S141: Determine the configuration bus name, configuration object path, and configuration interface name.

[0047] S142: Determine the configuration method information and attribute definition of the monitoring item to be modified; wherein the configuration method information includes at least configuration update, configuration view and configuration reset; and the attribute definition includes at least read-only information and read-write information.

[0048] S143: Generate a new configuration file according to the configuration bus name, configuration object path, configuration interface name, configuration method information and attribute definition.

[0049] Specifically, the bus name, object path, and interface name are the three core pieces of information that make up a D-Bus interface call. Together, they identify the specific functionality of the service being accessed. For example, the bus name xyz.openbmc_project.HBAMonitor indicates that this service is responsible for monitoring all HBAs; the object path / xyz / openbmc_project / HBAMonitor / hba0 indicates a monitoring object for HBA0; the interface name xyz.openbmc_project.Sensor.Value indicates that this object implements the sensor value interface; and the Get method is the actual function being called, such as obtaining a temperature value.

[0050] Furthermore, the configuration method information and attribute definition of the monitoring item to be modified are determined. It should be noted that the configuration method information includes at least configuration update, configuration view and configuration reset. For example, SetConfig(config:dict<string,variant> )→void represents receiving a dictionary containing monitoring item configurations and updating the system configuration. Example input: {"Temperature":true,"Voltage":false}; GetConfig()→dict<string,variant> This function returns the current monitoring item configuration. You can view the current HBA card monitoring item configuration. For example, in the above example, "Temperature" is true, which means that the HBA card temperature is included in the monitoring, and "Voltage" is false, which means that the HBA card voltage is not included in the monitoring. ResetConfig()→void represents resetting the configuration to the default state.

[0051] Secondly, in D-Bus, attributes are members exposed in the interface, defining the state or configuration parameters of an object. The attribute definition here is used as an interface to view the monitoring items of the BMC for the HBA card and the monitoring items currently configured. The attribute definition includes at least read-only information and read-write information, specifically: AvailableItems (read-only), type array <string>, represents a list of all monitoring items supported by the BMC for the system HBA card; CurrentConfig (read and write), type is dict<string,variant> , which indicates the current BMC monitoring item configuration for the HBA card.

[0052] In this way, the complete generation of the configuration file is achieved, so that the monitoring items can be accurately modified according to the configuration file in the future.

[0053] In order to ensure the security of the monitoring item configuration, based on the above embodiment, before establishing the mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function, and after determining the monitoring item to be modified according to the new configuration file, the following is further included:

[0054] S17: Determine whether the monitoring item to be modified is in the pre-built legal item whitelist; wherein the legal item whitelist contains information of multiple monitoring items that are allowed to be called; if not, proceed to step S18; if so, proceed to step S19.

[0055] S18: Output a prompt message indicating that the monitoring item configuration is illegal and stop the current configuration process;

[0056] S19: Determine whether the monitored item to be modified is correctly bound to a valid function pointer in the dynamic library. If not, proceed to step S20; if so, proceed to step S21.

[0057] S20: Output a prompt message indicating that binding of a legal function pointer fails, and stop the current configuration process;

[0058] S21: Determine that the monitoring item to be modified is legal, and enter the step of establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function.

[0059] Specifically, after determining the monitoring item to be modified according to the new configuration file, it is determined whether the monitoring item to be modified is in a pre-built legal item whitelist, wherein the legal item whitelist contains information of multiple monitoring items that are allowed to be called.

[0060] If it is confirmed that the monitoring item to be modified is not in the pre-built legal item whitelist, the current configuration item to be modified is considered to have failed the validity check, a prompt message indicating that the monitoring item configuration is illegal is output, and the current configuration process is stopped. If it is confirmed that the monitoring item to be modified is in the pre-built legal item whitelist, the system determines whether the monitoring item to be modified is correctly bound to a legal function pointer in the dynamic library (such as get_temperature) to prevent null pointers or forged function names.

[0061] If it is confirmed that the monitoring item to be modified is not correctly bound to a legal function pointer in the dynamic library, the current configuration item to be modified is considered to have failed the validity check, a prompt message indicating that the binding of the legal function pointer failed is output, and the current configuration process is stopped. If it is confirmed that the monitoring item to be modified is correctly bound to a legal function pointer in the dynamic library, the monitoring item to be modified is determined to be legal, and the step of establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function is entered.

[0062] In this embodiment, the legitimacy of all monitoring item names passed in through the configuration interface is checked, and only the verified monitoring items are scheduled for execution; calling undefined, uninitialized or tampered function addresses is prevented, and pointer hijacking or dynamic injection attacks are defended from the root.

[0063] In addition, to further ensure the configuration and legality of monitored items, regular expression validation can be combined with data type and range validation in specific implementations. Specifically, regular expression validation uses predefined regular expressions to verify whether the format or value of a configuration item conforms to specific rules. First, you need to define regular expressions. Create a corresponding regular expression for each configuration item to match legal values ​​or formats. When a configuration modification request is received, these regular expressions are used to match the configuration item. If a match is successful, the modification is allowed; otherwise, the modification is rejected and an error message is returned. Data type and range validation ensures that the value of the configuration item conforms to the predefined data type and value range. First, you need to define the data type and range: clarify the legal data type (such as integer, string, Boolean value, etc.) and value range of each configuration item. In the configuration modification request, check whether the configuration item conforms to the predefined data type and ensure that its value is within the legal range. If it meets the requirements, the modification is allowed; otherwise, the modification is rejected.

[0064] In this way, by combining regular expression validation with data type and range validation, complex matching rules can be defined that are applicable to configuration items of various formats. At the same time, by clearly defining data types and ranges, the legitimacy of configuration items can be intuitively verified.

[0065] Based on the above embodiment, in some embodiments, registering the corresponding interface card based on the initialization function of each dynamic library includes:

[0066] S101: Load the dynamic library corresponding to the interface card through the dynamic library opening function.

[0067] S102: Calling the initialization function in the dynamic library to register the interface card.

[0068] To implement interface card registration, in this embodiment, the dynamic library corresponding to the interface card is loaded through the dynamic library opening function dlopen(), and the initialization function init_monitor() in the dynamic library is called to register the interface card, completing the initialization of the interface card by OpenBMC. OpenBMC recognizes the interface card and performs necessary initialization on the interface card to prepare for subsequent acquisition of interface card data.

[0069] Based on the above embodiments, in some embodiments, executing each monitoring item acquisition function according to a preset period includes:

[0070] S111: Calling each monitoring item acquisition function through the first thread to obtain the corresponding monitoring result;

[0071] S112: Asynchronously write each monitoring result into the cache.

[0072] In this embodiment, the interface card monitors using a dual-thread architecture. Specifically, the first thread calls the acquisition function for each monitoring item to obtain the corresponding monitoring results. Simultaneously, the second thread listens for access commands uploaded by the user through the access interface and retrieves the corresponding target monitoring results from the cache based on the second thread.

[0073] It should be noted that the access interface is an interface independent of the configuration interface, and is only used to display the data obtained by monitoring as an interface for users to view or call other interfaces. In this embodiment, there is no restriction on the specific type of the access interface, for example, it can be a D-Bus interface. In addition, the first thread executes the monitoring task regularly, calls the acquisition function in the dynamic library, and updates the database cache. The second thread responds to requests from users and quickly returns data from the cache without blocking the call path. Specifically, the lightweight database supports historical data query and power-off retention. If there is too much data, it can be put into the database for other processes to read. Subsequently, each monitoring result is written asynchronously to the cache. The cache is an intermediate storage of monitoring data, maintained by the monitoring thread and read by the service thread. It can avoid directly acquiring hardware for each request and improve the response speed.

[0074] Correspondingly, the generation process of the access command specifically includes determining the access bus name, access object path, and access interface name. Determine the attribute definition and signal definition of the access command. It should be noted that the attribute definition is the monitoring data of the interface card obtained as the interface release, such as Value (read-only), type double, representing the current sensor value; Unit (read-only), type string, representing the unit of the value (for example: "Celsius", "Volts"); Thresholds (read-only), type dict<string,double> , representing preset thresholds, such as high-temperature warnings. The signal definition, PropertiesChanged, is a standard mechanism used by access interfaces to notify property changes. In OpenBMC, it is widely used in scenarios such as sensor monitoring, status synchronization, and web interface updates to ensure real-time consistency between system components. PropertiesChanged indicates that when the value or status of a numerical sensor monitored by the interface card changes, this signal is sent to notify subscribers. Therefore, an access command is ultimately generated based on the access bus name, access object path, access interface name, property definition, and signal definition.

[0075] In this embodiment, a dual-thread separation architecture is used to ensure that the system does not block the response of the upper layer when performing data collection, thereby improving the real-time performance and stability of the system.

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

[0077] Figure 2 Schematic diagram of an interface card monitoring device provided by an embodiment of the present invention. The device is applied to an open management controller; Figure 2 As shown, the device includes:

[0078] The registration module 10 is used to obtain the pre-configured dynamic libraries corresponding to each interface card and register the corresponding interface card based on the initialization function of each dynamic library; wherein the dynamic library includes the initialization function and multiple monitoring item acquisition functions.

[0079] The mapping module 11 is used to establish a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function.

[0080] The acquisition module 12 is used to execute each monitoring item acquisition function according to a preset period to obtain the monitoring results of the monitoring items corresponding to each interface card, so that when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item.

[0081] In some embodiments, it further includes:

[0082] An update module is used to update a local configuration file according to a new configuration file uploaded by a user when receiving the new configuration file through the configuration interface;

[0083] The first determination submodule is used to determine the monitoring items to be modified according to the new configuration file;

[0084] Establish a submodule to establish a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function.

[0085] In some embodiments, the process of generating a new configuration file includes: determining the configuration bus name, configuration object path and configuration interface name; determining the configuration method information and attribute definition of the monitoring item to be modified; wherein the configuration method information includes at least configuration update, configuration view and configuration reset; the attribute definition includes at least read-only information and read-write information; generating a new configuration file based on the configuration bus name, configuration object path, configuration interface name, configuration method information and attribute definition.

[0086] In some embodiments, it further includes:

[0087] The first judgment module is used to judge whether the monitoring item to be modified is in the pre-built legal item whitelist; wherein the legal item whitelist contains information of multiple monitoring items that are allowed to be called; if it is confirmed that the monitoring item to be modified is not in the pre-built legal item whitelist, the first output module is triggered; if it is confirmed that the monitoring item to be modified is in the pre-built legal item whitelist, the second judgment module is triggered;

[0088] The first output module is used to output a prompt message indicating that the monitoring item configuration is illegal and stop the current configuration process;

[0089] The second judgment module is used to judge whether the monitoring item to be modified is correctly bound to the legal function pointer in the dynamic library; if it is confirmed that the monitoring item to be modified is not correctly bound to the legal function pointer in the dynamic library, the second output module is triggered; if it is confirmed that the monitoring item to be modified is correctly bound to the legal function pointer in the dynamic library, the legal determination module is triggered;

[0090] The second output module is used to output a prompt message indicating that the binding of a legal function pointer has failed and to stop the current configuration process;

[0091] The legality determination module is used to determine the legality of the monitoring item to be modified and trigger the establishment of a sub-module.

[0092] In some embodiments, the registration module 10 includes:

[0093] The loading module is used to load the dynamic library corresponding to the interface card through the dynamic library opening function;

[0094] The calling module is used to call the initialization function in the dynamic library to register the interface card.

[0095] In some embodiments, the acquisition module 12 includes:

[0096] The first acquisition submodule is used to call each monitoring item acquisition function through the first thread to obtain the corresponding monitoring result;

[0097] The writing submodule is used to asynchronously write each monitoring result into the cache.

[0098] In some embodiments, it further includes:

[0099] A monitoring module, configured to monitor access commands uploaded by users through a second thread and an access interface;

[0100] The generation process of the access command includes: determining the access bus name, access object path and access interface name; determining the attribute definition and signal definition of the access command; generating the access command according to the access bus name, access object path, access interface name, attribute definition and signal definition;

[0101] Correspondingly, determining the corresponding target monitoring item according to the access command includes: based on the second thread, obtaining the corresponding target monitoring result from the cache according to the target monitoring item.

[0102] For the description of the features in the embodiment corresponding to the interface card monitoring device, reference can be made to the relevant description of the embodiment corresponding to the interface card monitoring method, which will not be repeated here.

[0103] An embodiment of the present invention further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the interface card monitoring method.

[0104] An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned embodiments of the interface card monitoring method when running.

[0105] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0106] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned interface card monitoring method embodiments are implemented.

[0107] An embodiment of the present invention further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned interface card monitoring method embodiments are implemented.

[0108] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0109] The above describes in detail the interface card monitoring method, apparatus, device, and medium provided by the present invention. This document uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is intended only to facilitate understanding of the method and core concepts of the present invention. It should be noted that those skilled in the art may make various improvements and modifications to the present invention without departing from the principles of the present invention, and such improvements and modifications fall within the scope of protection of the claims of the present invention.< / string>

Claims

1. An interface card monitoring method, characterized in that: Applied to an open management controller; the method includes: Obtaining a pre-configured dynamic library corresponding to each interface card, and registering the corresponding interface card based on the initialization function of each dynamic library; wherein the dynamic library contains an initialization function and multiple monitoring item acquisition functions; Establishing a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function; Executing each monitoring item acquisition function according to a preset period to obtain monitoring results of the monitoring items corresponding to each interface card, so that when a user's access command is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item; Before obtaining the pre-configured dynamic libraries corresponding to the interface cards, the following steps are also included: When a new configuration file uploaded by a user is received through the configuration interface, the local configuration file is updated according to the new configuration file; Determine the monitoring items to be modified according to the new configuration file; Establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function; The process of generating the new configuration file includes: Determine the configuration bus name, configuration object path, and configuration interface name; Determine the configuration method information and attribute definition of the monitoring item to be modified; wherein the configuration method information includes at least configuration update, configuration view and configuration reset; the attribute definition includes at least read-only information and read-write information; The new configuration file is generated according to the configuration bus name, the configuration object path, the configuration interface name, the configuration method information and the attribute definition.

2. The interface card monitoring method according to claim 1, wherein: Before establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function, and after determining the monitoring item to be modified according to the new configuration file, the method further includes: Determine whether the monitoring item to be modified is in a pre-built legal item whitelist; wherein the legal item whitelist contains information of multiple monitoring items that are allowed to be called; If it is confirmed that the monitoring item to be modified is not in the pre-built legal item whitelist, a prompt message indicating that the monitoring item configuration is illegal is output and the current configuration process is stopped; If it is confirmed that the monitoring item to be modified is in the pre-built legal item whitelist, then determine whether the monitoring item to be modified is correctly bound to a legal function pointer in the dynamic library; If it is confirmed that the monitoring item to be modified is not correctly bound to the legal function pointer in the dynamic library, a prompt message indicating that the binding of the legal function pointer fails is output, and the current configuration process is stopped; If it is confirmed that the monitoring item to be modified is correctly bound to the legal function pointer in the dynamic library, the monitoring item to be modified is determined to be legal, and the step of establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function is entered.

3. The interface card monitoring method according to claim 1, wherein: Registering the corresponding interface card based on the initialization function of each dynamic library includes: Load the dynamic library corresponding to the interface card through a dynamic library opening function; The initialization function in the dynamic library is called to register the interface card.

4. The interface card monitoring method according to claim 1, wherein: Executing each monitoring item acquisition function according to a preset period includes: Calling each monitoring item acquisition function through the first thread to obtain the corresponding monitoring result; Asynchronously writing each of the monitoring results into a cache.

5. The interface card monitoring method according to claim 1, wherein: After executing each monitoring item acquisition function according to a preset period to obtain monitoring results of the monitoring items corresponding to each interface card, the method further includes: Monitoring the access command uploaded by the user through the second thread and the access interface; The process of generating the access command includes: Determine the access bus name, access object path and access interface name; Determining attribute definitions and signal definitions of the access command; Generate the access command according to the access bus name, the access object path, the access interface name, the attribute definition and the signal definition; Correspondingly, obtaining the corresponding target monitoring result according to the target monitoring item includes: Based on the second thread, the corresponding target monitoring result is obtained from the cache according to the target monitoring item.

6. An interface card monitoring device, characterized in that: Applicable to an open management controller; the device includes: A registration module is used to obtain a pre-configured dynamic library corresponding to each interface card and register the corresponding interface card based on the initialization function of each dynamic library; wherein the dynamic library contains an initialization function and multiple monitoring item acquisition functions; A mapping module, configured to establish a mapping relationship between the monitoring items of each interface card and the corresponding monitoring item acquisition function; an acquisition module, configured to execute each of the monitoring item acquisition functions according to a preset period to obtain monitoring results of the monitoring items corresponding to each of the interface cards, so that when an access command from a user is received, the corresponding target monitoring item is determined according to the access command, and the corresponding target monitoring result is obtained according to the target monitoring item; Also includes: An update module, configured to update a local configuration file according to a new configuration file uploaded by a user when receiving the new configuration file through the configuration interface; A first determining submodule, configured to determine a monitoring item to be modified according to the new configuration file; Establish a submodule for establishing a mapping relationship between the monitoring item to be modified and the corresponding monitoring item acquisition function; In some embodiments, the process of generating the new configuration file includes: determining the configuration bus name, the configuration object path and the configuration interface name; determining the configuration method information and attribute definition of the monitoring item to be modified; wherein the configuration method information includes at least configuration update, configuration view and configuration reset; the attribute definition includes at least read-only information and read-write information; generating the new configuration file according to the configuration bus name, the configuration object path, the configuration interface name, the configuration method information and the attribute definition.

7. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the interface card monitoring method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the interface card monitoring method according to any one of claims 1 to 5 when executed by a processor.

Images