Out-of-band equipment monitoring method, device, equipment, medium and program product

Abstract

The invention provides an out-of-band equipment monitoring method and device, equipment, a medium and a program product, which can be applied to the field of financial science and technology. The method comprises the following steps: establishing a configuration channel corresponding to equipment to be managed, and marking the equipment to be managed with the successfully established channel as managed equipment; wherein the equipment to be managed comprises out-of-band equipment of isomorphic main bodies and / or heterogeneous main bodies; receiving a first alarm message sent by the managed equipment through the corresponding configuration channel in real time, and performing distributed flow batch cooperative processing on the first alarm message to obtain first alarm information; scanning the managed equipment through an active polling mechanism according to a preset message format to obtain second alarm information; and monitoring the managed equipment based on the first alarm information and / or the second alarm information.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial technology, and more particularly to an out-of-band device monitoring method, device, equipment, medium and program product. BACKGROUND

[0002] In the field of financial technology, device out-of-band alarm monitoring is a key line of defense to ensure the continuity of core business. It can bypass the main system of faulty devices, capture hardware failures, power abnormalities, temperature and humidity overruns, and other problems in real time, and provide early warning of risks. Financial businesses have very high requirements for stability and security. This device out-of-band monitoring can shorten fault location time, avoid transaction interruption and data loss, help financial institutions meet regulatory requirements, and maintain customer trust and market reputation.

[0003] In the current super-large-scale, multi-brand, multi-model mixed deployment server environment, the key hardware running state monitoring of different manufacturers' servers relies on their private management information base, making multi-manufacturer device management significantly different, and there is a problem of heterogeneous alarms that cannot be normalized. The existing decentralized, brand-bound out-of-band management system architecture cannot meet the needs of efficient, unified, and intelligent centralized monitoring and operation and maintenance management. SUMMARY

[0004] In view of the above problems, the present application provides an out-of-band device monitoring method, device, equipment, medium and program product for unified management.

[0005] According to a first aspect of the present application, an out-of-band device monitoring method is provided, applied to a control end, the method comprising: establishing a configuration channel corresponding to a device to be managed, and marking the device to be managed whose channel establishment is successful as a managed device; wherein the device to be managed includes out-of-band devices of homogeneous subjects and / or heterogeneous subjects; receiving a first alarm message uploaded by the managed device through the corresponding configuration channel in real time, and performing distributed stream batch collaborative processing on the first alarm message to obtain first alarm information; scanning the managed device through an active polling mechanism according to a preset message format to obtain second alarm information; and monitoring the managed device based on the first alarm information and / or the second alarm information.

[0006] According to an embodiment of the present application, the distributed flow batch collaborative processing of the first alarm message comprises: constructing a message queue instance and configuring cluster parameters of a message queue cluster; wherein the message queue cluster is composed of distributed server nodes; receiving the first alarm message based on the message queue instance and performing format conversion processing on the first alarm message to obtain first alarm data; forwarding the first alarm data to a corresponding message queue cluster according to the cluster parameters; forwarding the first alarm data to a flow processing task cluster through the message queue cluster; and processing the first alarm data in real time through the flow processing task cluster.

[0007] According to an embodiment of the present application, the real-time processing of the first alarm data through the flow processing task cluster comprises: reorganizing the first alarm data based on the preset message format through the flow processing task cluster to obtain reorganized messages; parsing the reorganized messages to obtain message keys; and mapping the first alarm data to standard alarm information based on the message keys to obtain the first alarm information.

[0008] According to an embodiment of the present application, the scanning of the managed device through the active polling mechanism according to the preset message format comprises: acquiring device state information of the managed device by scanning the managed device through the active polling mechanism based on an intelligent platform management interface protocol; creating a second alarm message according to the preset message format and the device state information; and extracting the second alarm information based on the second alarm message.

[0009] According to an embodiment of the present application, the establishment of the configuration channel corresponding to the device to be managed comprises: starting a trap function of the device to be managed based on a simple network management protocol; establishing a trap channel with the device to be managed according to the started trap function, so that the device to be managed sends simulation messages through the trap channel; and receiving the simulation messages of the device to be managed to complete the establishment of the configuration channel corresponding to the device to be managed.

[0010] According to an embodiment of the present application, the method further comprises: re-establishing the configuration channel corresponding to the device to be managed if the simulation messages of the device to be managed are not received; and if the re-establishment fails, prompting a failure information and initiating a manual operation request.

[0011] The second aspect of the present application provides an out-of-band device monitoring apparatus, comprising: a channel establishing module, configured to establish a configuration channel corresponding to a device to be managed, and mark the device to be managed as a managed device if the device to be managed succeeds in establishing the channel; wherein the device to be managed comprises an out-of-band device of a homogeneous body and / or a heterogeneous body; a first alarm module, configured to receive a first alarm message sent by the managed device through the corresponding configuration channel in real time, and perform distributed stream batch collaborative processing on the first alarm message to obtain first alarm information; a second alarm module, configured to scan the managed device according to a preset message format through an active polling mechanism to obtain second alarm information; and a monitoring module, configured to monitor the managed device based on the first alarm information and / or the second alarm information.

[0012] The third aspect of the present application provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method.

[0013] The fourth aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, wherein the computer program or instructions are executed by a processor to implement the steps of the method.

[0014] The fifth aspect of the present application further provides a computer program product comprising a computer program or instructions, wherein the computer program or instructions are executed by a processor to implement the steps of the method.

[0015] In the embodiments of the present application, by establishing a configuration channel and marking the state of being managed, homogeneous and heterogeneous out-of-band devices are uniformly managed, and multiple master devices are covered; alarm messages sent on the configuration channel are received in real time, and alarm information obtained through active polling is combined to avoid false negatives of a single method; alarm messages sent by out-of-band devices are processed in a distributed stream batch collaborative manner to break through the barriers of manufacturers and balance real-time performance and processing efficiency; based on the actual environment of out-of-band devices, out-of-band devices are monitored based on double alarm information, strong heterogeneous compatibility and unified management capabilities are provided, the efficiency of data center operation is improved, business continuity is ensured, and the management complexity is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0016] The above and other objects, features and advantages of the present application will become more apparent from the following description of the embodiments of the present application taken with reference to the accompanying drawings, in which:

[0017] Figure 1 An application scenario diagram of an out-of-band device monitoring method, apparatus, device, medium and program product according to an embodiment of the present application is schematically shown;

[0018] Figure 2A flowchart illustrating an out-of-band device monitoring method according to an embodiment of this application is shown schematically.

[0019] Figure 3 This schematically illustrates a first alarm message processing flowchart of an out-of-band device monitoring method according to an embodiment of this application;

[0020] Figure 4 This illustration schematically shows a cluster node interaction diagram of an out-of-band device monitoring method according to an embodiment of this application;

[0021] Figure 5 This schematically illustrates a structural block diagram of an out-of-band device monitoring device according to an embodiment of this application; and

[0022] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing an out-of-band device monitoring method according to an embodiment of this application. Detailed Implementation

[0023] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0024] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0025] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0026] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0027] With the rapid development of fintech, banking institutions' data centers are handling an ever-increasing volume of business, leading to a continuous expansion in the scale of their server equipment. The brands and models of servers procured and deployed are becoming increasingly diverse and complex, resulting in a wide variety of out-of-band devices. This surge in the number of server devices and the heterogeneity of their brands and models pose a significant challenge to the operational and maintenance capabilities of the infrastructure, particularly to the real-time monitoring of the health status of out-of-band devices.

[0028] When the main business system of the device (such as a server operating system crash or a network device main port failure) fails, the operation and maintenance personnel can still intervene through the out-of-band channel of the out-of-band device to avoid the device losing connection, quickly locate hardware failures, and restore the device operation. This is especially critical for fields such as finance that have extremely high requirements for business continuity.

[0029] Currently, monitoring the critical hardware operating status of servers from different manufacturers relies on their proprietary Management Information Base (MIB), and this MIB information cannot be obtained through standard, universal MIB libraries. This directly leads to significant differences in core elements such as specific rule definitions, trigger threshold settings, and alarm level classifications between out-of-band management units of different brands, and even different models of the same brand.

[0030] In today's large-scale, multi-brand, and multi-model server environments, the existing decentralized, brand-bound out-of-band device management system architecture can no longer meet the needs for efficient, unified, and intelligent centralized monitoring and operation and maintenance management. There is a pressing need to address the richness and diversity of device alarm information, as well as the challenges of cross-system integration. Therefore, there is an urgent need for a device out-of-band alarm monitoring solution that can effectively resolve the differences in proprietary MIBs across multiple vendors, break down management silos, and provide unified access, centralized parsing, standardized presentation, and intelligent analysis.

[0031] This application provides an out-of-band device monitoring method applied to a control terminal. The method includes: establishing a configuration channel corresponding to a device to be managed, and marking the device to be managed as a managed device if the channel is successfully established; wherein the device to be managed includes out-of-band devices of homogeneous and / or heterogeneous entities; receiving a first alarm message sent by the managed device through the corresponding configuration channel in real time, and performing distributed batch processing on the first alarm message to obtain a first alarm information; scanning the managed device through an active polling mechanism according to a preset message format to obtain a second alarm information; and monitoring the managed device based on the first alarm information and / or the second alarm information.

[0032] In the embodiments of this application, by establishing a configuration channel and marking the management status, homogeneous and heterogeneous out-of-band devices are managed in a unified manner, covering multiple main devices; alarm messages sent from the configuration channel are received in real time, and alarm information is combined with active polling to avoid missed alarms in a single method; distributed batch processing of alarm messages sent from out-of-band devices breaks down vendor barriers and balances real-time performance and processing efficiency; for the actual environment of out-of-band devices, out-of-band devices are monitored based on dual alarm information, which has strong heterogeneous compatibility and unified management capabilities, improves data center operation and maintenance efficiency, ensures business continuity, and reduces management complexity.

[0033] It should be noted that the out-of-band device monitoring method and apparatus of this application can be used in the field of fintech, or in any field other than fintech. The application field of the out-of-band device monitoring method and apparatus of this application is not limited.

[0034] Figure 1 The illustration shows an application scenario diagram of the out-of-band device monitoring method, apparatus, device, medium, and program product according to embodiments of this application.

[0035] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0036] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0037] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0038] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0039] It should be noted that the out-of-band device monitoring method provided in this application embodiment can generally be executed by server 105. Correspondingly, the out-of-band device monitoring device provided in this application embodiment can generally be located in server 105. The out-of-band device monitoring method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the out-of-band device monitoring device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0040] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0041] The following will be based on Figure 1 The described scene, through Figures 2-4 The out-of-band device monitoring method according to the embodiments of this application will be described in detail.

[0042] Figure 2 A flowchart illustrating an out-of-band device monitoring method according to an embodiment of this application is shown.

[0043] like Figure 2 As shown, the out-of-band device monitoring method of this embodiment includes operations S210 to S240. This out-of-band device monitoring method is applied to a control terminal, which serves as a unified management terminal for out-of-band devices, such as a management platform / system, control platform / system, etc., but is not limited to a specific execution entity. The execution entity can be any electronic device, such as a terminal device or a server device, etc. The execution entity can also be any software application or client. For ease of explanation, a management system is used as the control terminal for description.

[0044] In operation S210, a configuration channel corresponding to the device to be managed is established, and the device to be managed that has successfully established the channel is marked as a managed device; wherein, the device to be managed includes out-of-band devices of homogeneous and / or heterogeneous entities.

[0045] Devices awaiting management are out-of-band devices that are not included in the unified operation and maintenance management system for monitoring, configuration, and fault handling. Devices already under management are out-of-band devices that have completed the interface configuration with the unified operation and maintenance management system and have been included in the platform's standardized monitoring, management, and fault handling system, and can be uniformly managed by the management system.

[0046] The managed equipment usually meets two key conditions: (1) an effective connection has been established, such as the configuration channel and alarm transmission channel (such as trap channel) between the management / control system have been successfully built; (2) it can be fully controlled by the system, can actively report status or alarms to the system, and can also be obtained by the system through polling, without the need for maintenance personnel to operate a single device.

[0047] The Simple Network Management Protocol (SNMP) and the Intelligent Platform Management Interface (IPMI) are used to enable the trap function of the monitored devices from the system side, and establish a configuration channel (such as the SNMP-SET channel) between the monitored devices and the system. Devices that have successfully established a configuration channel are now considered managed devices.

[0048] It is worth noting that heterogeneous entities refer to differences in the supply entities of out-of-band equipment. This includes different manufacturers / brands, as well as brands / product entities with different product lines and different technical architectures under the same manufacturer. The core difference is that they are different from homogeneous entities with the same manufacturer, brand, and technical system.

[0049] Homogeneous entities are those whose suppliers of out-of-band equipment are completely identical, usually referring to the same manufacturer and the same brand, with no differences in source across manufacturers or brands.

[0050] Compared to out-of-band devices with homogeneous entities, out-of-band devices with heterogeneous entities will exhibit differences in protocols (e.g., out-of-band devices from different manufacturers may support different management protocols), MIB libraries (the proprietary MIB libraries of different manufacturers are incompatible and require specific adaptation), and management interfaces (e.g., some devices provide network management interfaces, while others only support command lines).

[0051] A configuration channel represents the communication path for performing write operations (configuring device parameters) via the SNMP protocol. The process of establishing a configuration channel represents the complete process of the management system sending configuration commands to out-of-band devices and completing parameter modifications.

[0052] Out-of-band devices refer to devices that do not rely on the main business network / system and support out-of-band management. These devices or functional modules are managed, monitored, or maintained through a dedicated channel. The core principle is physical or logical isolation from the in-band (the channel for normal business data transmission). Even if the main business system fails, the device can still be operated. Examples of out-of-band devices include servers (which can be independently controlled for power-on / off and hardware status monitoring via a remote management card), network devices (accessed via a dedicated management port, such as switches and routers, for configuration modification and troubleshooting), and storage devices (which allow remote monitoring of disk health via a storage management port, enabling hardware fault diagnosis even if the storage service link is interrupted).

[0053] When operating S220, the first alarm message sent by the managed device through the corresponding configuration channel is received in real time, and the first alarm message is processed in a distributed batch collaborative manner to obtain the first alarm information.

[0054] If a managed device detects an anomaly (such as excessive temperature or port failure) during operation, it will automatically trigger a built-in alarm mechanism to generate an alarm message containing the anomaly type, time, and device identifier. This process is completed independently by the device and is unrelated to the management system.

[0055] Once the configuration channel is successfully established, as long as the Trap channel is correctly established, managed devices will automatically send generated alarm messages through this Trap channel to a message receiving server with a pre-configured Internet Protocol Address (IP) and port. When a managed device sends an alarm message, the alarm source field of the message will be automatically marked as the managed device, ensuring that the server can accurately identify which device the alarm came from without manual intervention.

[0056] Distributed stream-batch collaborative processing generates a large number of first alarm messages from managed devices. Based on a distributed architecture (multi-node cluster), distributed stream-batch collaborative processing breaks down the traditional separation between stream processing and batch processing technologies. Through a unified underlying engine, application programming interface, and computing logic, it supports both real-time processing of unbounded data streams and offline batch processing of bounded datasets. Its core purpose is to solve the pain points of traditional stream / batch separation models, such as redundant technology stacks, inconsistent data definitions, and difficulty in aligning real-time and offline results.

[0057] It is worth noting that the first alarm message is a Trap message automatically generated and reported by the managed equipment. It can be composed of key-value pairs, the core of which is to associate the object identifier with the corresponding object information. The object identifier is used to uniquely identify a specific parameter or status of the equipment, while the object information is the specific value of that parameter or a description of its status. The combination of the two clearly conveys the alarm content of the equipment.

[0058] When operating S230, according to the preset message format, the managed devices are scanned through an active polling mechanism to obtain the second alarm information.

[0059] The alarms received by the management system are divided into two categories based on the sending mechanism: one is alarms automatically reported by out-of-band devices, and the other is alarms detected by the management system itself.

[0060] The management system scans managed devices at set intervals using a proactive polling mechanism to obtain their status information. It then converts this status information into standardized alarm messages according to a preset message format, explicitly marking the alarm source field as a system alarm. The entire process is proactively initiated and completed by the management system to supplement any anomalies not proactively reported by the devices.

[0061] Most abnormal alarms are automatically generated and uploaded by managed devices, but some may still be missed. Therefore, an active polling mechanism is established to compensate for network jitter, improve alarm monitoring coverage, and ensure comprehensive monitoring of devices. An out-of-band monitoring and management system is established through a dual-alarm mechanism to achieve unified integration and management of out-of-band alarms generated by out-of-band devices from various brands, improving the efficiency of device-related alarm handling and the standardization of operation and maintenance.

[0062] When operating S240, monitor managed devices based on the first alarm information and / or the second alarm information.

[0063] The management system constructs a two-layer monitoring system based on the first and second alarm information to achieve comprehensive status control of the managed equipment.

[0064] When the first alarm message is received (the managed device actively reports through the Trap channel), the management system analyzes the anomaly type, occurrence time and device identifier in real time, quickly locates the faulty device and triggers an immediate alarm notification to ensure that sudden problems are captured in a timely manner.

[0065] For the second alarm information (generated by the management system through proactive polling), the system compares it with the baseline status of the equipment periodically to identify potential abnormal trends, such as performance indicators slowly deviating from the normal range, thereby achieving preventative monitoring.

[0066] Meanwhile, the management system cross-validates the two types of alarm information. If the same device generates two types of alarms simultaneously within a short period of time, the alarm level is automatically escalated. If there is only a single source alarm, a secondary verification mechanism (such as increasing the polling frequency) is activated to avoid false alarms.

[0067] The management system displays the integrated alarm information in visual charts, marks the health status of the equipment, and supports filtering and analysis by alarm source, level, type, and other dimensions, providing maintenance personnel with accurate fault location basis and decision support, and comprehensively ensuring the stable operation of the equipment.

[0068] In the embodiments of this application, by establishing a configuration channel and marking the management status, homogeneous and heterogeneous out-of-band devices are managed in a unified manner, covering multiple main devices; alarm messages sent from the configuration channel are received in real time, and alarm information is combined with active polling to avoid missed alarms in a single method; distributed batch processing of alarm messages sent from out-of-band devices breaks down vendor barriers and balances real-time performance and processing efficiency; for the actual environment of out-of-band devices, out-of-band devices are monitored based on dual alarm information, which has strong heterogeneous compatibility and unified management capabilities, improves data center operation and maintenance efficiency, ensures business continuity, and reduces management complexity.

[0069] According to an embodiment of this application, in operation S210, establishing a configuration channel corresponding to the device under management includes: enabling the trap function of the device under management based on the Simple Network Management Protocol; establishing a trap channel with the device under management based on the enabled trap function, so that the device under management can send simulated messages through the trap channel; and receiving simulated messages from the device under management to complete the establishment of the configuration channel corresponding to the device under management.

[0070] Simple Network Management Protocol (SNMP) is a standard protocol for network device management. Its core function is to enable the management system to communicate with out-of-band devices in the network (such as servers, network devices, storage devices, etc.) to achieve device status monitoring, configuration management, and troubleshooting.

[0071] The management system's front end initiates a request to establish a configuration channel, sending configuration commands to the managed devices using the SNMP protocol. First, it enables the trap function on the managed devices, including turning on the trap switch, setting the trap version, and setting the community name. Second, it establishes a trap channel, configuring the server information the device needs to connect to—specifically, the management system's message receiving server. This server deploys the message receiving program configured by the management system to receive alarms sent from the trap channel. Server information includes IP address and port, and the currently configured channel is open. Finally, it sends simulated messages through the out-of-band device's trap channel, i.e., to the server and port configured by the management system. The message receiving program deployed on the management system receives and records these messages and performs subsequent operations.

[0072] The Trap function is a mechanism for out-of-band devices to proactively send alarm information to the management system. Its core principle is that the management platform doesn't need to actively query the system; the device itself detects an anomaly and proactively reports it. When a device malfunctions or experiences an anomaly (such as power outage, excessive temperature, or port disconnection), the built-in Trap function is automatically triggered. It packages alarm information including the fault type, occurrence time, and device identifier, and proactively pushes it to a pre-configured management system address, allowing maintenance personnel to be aware of device problems in real time without frequent polling of device status.

[0073] The Trap channel is a logical / physical channel dedicated to transmitting Trap alarm information between out-of-band devices and the management system. It provides an independent transmission path for alarm data, preventing resource contention or data loss with business data. As a dedicated alarm lane, its path is independent and separate from the main business data channels of out-of-band devices (such as channels for transmitting transaction data or file data). Even if the main business channel is congested or fails, Trap alarms can still be transmitted through the dedicated channel, ensuring that fault information is not blocked. Parameters are controllable; the Trap channel is pre-configured with transmission parameters (such as the protocol port used, encryption method, and receiver address) to ensure that Trap alarms are accurately and securely delivered to the management platform. Data isolation is achieved through the Trap channel, which is used only for transmitting critical operational information such as Trap alarms, preventing the mixing of other irrelevant data and improving the efficiency and reliability of alarm transmission.

[0074] In the embodiments of this application, the trap function of out-of-band devices is enabled through the Simple Network Management Protocol, a dedicated trap channel is established, and the validity of the channel is verified by using simulated messages to ensure that the configuration channel is reliably established, providing a stable configuration channel path for subsequent alarm transmission of the device and improving management efficiency.

[0075] According to an embodiment of this application, when the managed device sends a simulated message through the trap channel, the control terminal needs to receive the simulated message from the managed device in a timely manner. If the simulated message from the managed device is not received, the control terminal re-establishes the configuration channel corresponding to the managed device. If the re-establishment fails, a failure message is displayed, and a manual operation request is initiated.

[0076] Out-of-band devices send simulated messages. The management system determines whether the Trap channel for the out-of-band device has been opened and correctly configured based on whether the simulated message is received. If the configuration channel has not been correctly established, the active polling mechanism attempts to establish the configuration channel again. If the attempt fails, a failure message is displayed (e.g., the SNMP-SET channel for the managed device failed to be established), and a manual operation request is initiated. The maintenance personnel can then manually establish the SNMP-SET channel. Once successfully established, the device is added to the managed device list.

[0077] In the embodiments of this application, when no simulated message is received, the channel is automatically retried to reduce the probability of channel establishment failure. If the retry fails, a prompt is given and manual intervention is requested to avoid channel establishment being stalled and to ensure the orderly progress of the out-of-band device management process.

[0078] Figure 3 The diagram illustrates a first alarm message processing flowchart of an out-of-band device monitoring method according to an embodiment of this application.

[0079] like Figure 3As shown, in operation S220, the first alarm message is processed in a distributed batch collaborative manner, which includes operations S310 to S350.

[0080] When operating S310, a message queue instance is built, and the cluster parameters of the message queue cluster are configured; the message queue cluster consists of distributed server nodes.

[0081] A message queue cluster is a distributed message queue system composed of multiple server nodes, used for the reception, storage, and distribution of distributed messages. As middleware, the message queue cluster receives messages from various data sources, stores them by topic, and then distributes them according to downstream needs (such as stream processing tasks), achieving asynchronous data transmission, buffering, and peak smoothing to ensure high throughput and data reliability.

[0082] Create a message queue instance and configure the cluster parameters for connecting to the message queue cluster (such as server address, port, and cluster core configuration information). The message queue instance is the message queue producer instance, acting as the initiator of data transmission. Its main functions include: continuously receiving alarm messages from upstream to ensure stable data access; performing data format conversion and encapsulation according to message queue specifications to ensure correct data recognition by the cluster; reliably transmitting processed alarm data to the message queue cluster via sending methods, providing a real-time and continuous data source for downstream stream processing tasks; and in some scenarios, providing feedback on data transmission status (such as success / failure notifications) to ensure data transmission traceability.

[0083] When operating S320, the first alarm message is received based on the message queue instance, and the first alarm message is converted into a format to obtain the first alarm data.

[0084] The message queue instance continuously listens to the Trap channel to capture alarm messages from managed devices. Once an alarm message sent by a managed device is captured, the receiving process is immediately initiated. The alarm message is first checked for integrity, and after confirming that the format is correct, it is stored in a temporary buffer to avoid data loss.

[0085] During the conversion phase, the management system parses the message structure according to preset rules. First, it extracts core fields such as device identifier, alarm type, and occurrence time, and removes redundant information. Then, it maps the unstructured raw message content into a key-value pair format that can be directly processed by the message queue, such as device identifier and alarm level as keys, and corresponding specific values ​​or descriptions as values.

[0086] Simultaneously, the field formats are standardized, for example, converting times to millisecond-level timestamps and mapping alarm levels to numerical codes. After conversion, the first alarm data is generated, and the format compliance is automatically verified to ensure it meets the processing requirements of the message queue cluster, laying the foundation for subsequent distributed forwarding.

[0087] When operating the S330, the first alarm data is forwarded to the corresponding message queue cluster according to the cluster parameters.

[0088] Read the cluster parameters of the message queue, including cluster node distribution, topic mapping rules, load balancing strategies and other core cluster configuration information, to determine the target cluster and processing topic corresponding to the first alarm data.

[0089] A dedicated sending method is invoked. This method first matches the corresponding message queue cluster topic to the specified topic based on information such as device type and alarm level in the alarm data, combined with the topic mapping rules in the cluster parameters. For example, server temperature alarm data is assigned to the "hardware failure" topic, and network anomaly alarms are assigned to the "connection" topic.

[0090] The sending method uses the load balancing strategy in the cluster parameters to select nodes with lower loads within the cluster as forwarding targets, avoiding excessive pressure on a single node. Data integrity is verified in real time during forwarding. If a single transmission fails, a retry mechanism is automatically triggered to ensure that the first alarm data is accurately and stably delivered to the designated topic in the message queue cluster, preparing data for subsequent stream processing tasks.

[0091] When operating S340, the first alarm data is forwarded to the stream processing task cluster via the message queue cluster.

[0092] After receiving the first alarm data, the message queue cluster first stores it according to the specified topic to ensure that the data is temporarily stored in an orderly manner and without loss. Then, the cluster identifies the corresponding stream processing task type according to the preset distribution rules, such as matching hardware failure data with hardware processing tasks and network anomaly data with network processing tasks.

[0093] Next, the internal forwarding interface is called to push the data to the corresponding task node in the stream processing task cluster, while the forwarding status is monitored in real time. If a node is busy, the data is automatically temporarily stored in the cluster cache queue and pushed again when the node is idle, ensuring that the data flows to the stream processing stage efficiently and stably, avoiding transmission interruption.

[0094] When operating the S350, the first alarm data is processed in real time through a stream processing task cluster.

[0095] A stream processing task cluster is a computing cluster composed of multiple distributed stream processing task nodes, specifically designed for real-time and efficient processing of continuously generated streaming data (such as first alarm data). The stream processing tasks perform real-time processing, ensuring real-time performance, while also providing comprehensive processing for uploaded alarms, including alarm rule standardization, basic message supplementation, and compatibility with downstream centralized management system indicator specifications.

[0096] Each node in the stream processing task cluster subscribes to the corresponding topic in the message queue cluster, pulls the first alarm data in real time, and processes the alarm data in parallel to generate standardized first alarm information.

[0097] The streaming task processing feature is the ability to process cross-source heterogeneous data in a unified manner. It can use distributed streaming and batch processing to process data in a unified manner, including real-time processing of unbounded data streams (such as real-time alarm cleaning) and batch processing of bounded datasets (such as historical alarm backtracking analysis). Furthermore, it achieves the reuse of streaming and batch processing logic through a unified underlying engine.

[0098] In the embodiments of this application, alarm messages are processed collaboratively by message queue clusters and stream processing task clusters to achieve efficient reception, conversion and real-time processing of alarm data, solve the normalization problem of heterogeneous alarms from multiple vendors, further realize data interoperability with various systems, make out-of-band management of data center equipment more efficient and convenient, and greatly improve the efficiency of docking and the level of operation and maintenance standardization.

[0099] According to an embodiment of this application, in operation S350, the first alarm data is processed in real time through a stream processing task cluster, including: reconstructing the first alarm data based on a preset message format through the stream processing task cluster to obtain a reconstructed message; parsing the reconstructed message to obtain message keywords; and mapping the first alarm data to standard alarm information based on the message keywords to obtain the first alarm information.

[0100] Processing alarm data through a stream processing task cluster breaks the limitation of processing alarm messages separately by brand. First, the data is reconstructed according to a preset message format, missing fields are added, and the field order is adjusted to generate a reconstructed message with a unified structure. Then, the reconstructed message is parsed to extract core keywords such as device identifier, alarm type, occurrence time, and outliers. The reconstructed message has a unified message format, achieving cross-brand alarms that are universally applicable across the entire network with a single conversion. This allows for northbound integration with downstream centralized monitoring systems, requiring only one configuration to access alarm data from all devices, simplifying the integration process and significantly improving integration efficiency and operational standardization.

[0101] After parsing and reassembling the messages, the data is converted into a unified format based on the mapping rules between the message keywords and standard alarm information. This enables all messages to be uniformly mapped into several categories of standardized alarm information, such as alarms related to the central processing unit, memory, hard drive, power supply, fan, temperature, etc. "Temperature exceeds upper limit" is mapped to "Hardware high temperature alarm". Standardized fields such as alarm level and impact range are added, and finally the first alarm information is generated. The entire process is responded to in real time to ensure that the data is standardized and usable.

[0102] In the embodiments of this application, a standardized processing flow is used to formulate a unified message format for device alarms, reorganize and parse alarm data, and uniformly map heterogeneous original messages from multi-brand devices into standardized alarm information. This achieves a one-time conversion of cross-brand alarms, making them universal across the entire network, eliminating message differences between different main devices, and realizing the standardization and consistency of alarm data.

[0103] In distributed stream-batch collaborative processing Figure 4 The diagram illustrates the cluster node interaction of an out-of-band device monitoring method according to an embodiment of this application.

[0104] like Figure 4 As shown, the acquisition nodes (the message receiving servers of the management system) collect alarm message data from managed devices (such as servers, network devices, etc.). Next, the data is transmitted to message queue nodes (the nodes of the message queue cluster) for temporary storage, serving as a buffer and data routing mechanism. Subsequently, stream processing task nodes (the nodes of the stream processing task cluster) read the data from the message queue nodes and perform real-time filtering, transformation, aggregation, and other processing operations. Simultaneously, the web (World Wide Web) node provides a web interface module responsible for configuring and monitoring the entire system (such as stream processing task nodes and message queue nodes). All processed data and relevant information from the web nodes are ultimately stored in the database, achieving end-to-end management of managed device data from acquisition, transmission, processing to storage, ensuring efficient and stable device monitoring.

[0105] According to an embodiment of this application, in operation S230, the managed devices are scanned through an active polling mechanism based on a preset message format. This includes scanning the managed devices through an active polling mechanism based on the intelligent platform management interface protocol to obtain the device status information of the managed devices; creating a second alarm message based on the preset message format and device status information; and extracting second alarm information based on the second alarm message.

[0106] The Intelligent Platform Management Interface Protocol (IPMI) is a standardized interface protocol for server hardware monitoring and remote management. Even if the server operating system crashes, loses power (hardware support required), or the system is not installed, the administrator can still directly manage the server hardware through the IPMI protocol to achieve out-of-band management.

[0107] When extracting the second alarm information, the system first scans each managed device one by one based on the IPMI protocol and through an active polling mechanism to obtain device status information such as power on / off status, Trap channel connection status, and hardware sensor data.

[0108] Secondly, these device status information are structured according to a preset message format to create a second alarm message. When parsing this message, the core content such as device identifier, polling time, status parameter type, and specific value are extracted according to the field structure.

[0109] Finally, the extracted status information is compared with the device baseline data. If the actual device power-on / off status does not match the baseline, it is marked as "abnormal operating status"; if the Trap channel parameters exceed the normal range, it is determined as "channel communication failure"; if the hardware sensor values ​​deviate from the threshold, it is identified as "hardware parameter exceeding limits". The comparison results are integrated to supplement information such as alarm level and impact range, generating structured second alarm information. The polling timestamp and the device's unique identifier are associated to ensure traceability, completing the extraction of second alarm information. Active polling compensates for alarm omissions caused by network jitter and improves monitoring coverage.

[0110] In the embodiments of this application, a unified intelligent platform management interface protocol is used to actively poll and overcome the limitations of out-of-band device types, thereby stably acquiring status information. Messages are generated according to a unified preset message format, and alarms are extracted to ensure data standardization and consistency. Alarm sources are proactively scanned and supplemented to reduce information omissions and improve the comprehensiveness and reliability of out-of-band device monitoring.

[0111] Based on the above-described out-of-band device monitoring method, this application also provides an out-of-band device monitoring device. The following will be combined with... Figure 5 The device is described in detail.

[0112] Figure 5 A schematic block diagram of an out-of-band device monitoring device according to an embodiment of this application is shown.

[0113] like Figure 5 As shown, the out-of-band device monitoring device 500 in this embodiment includes a channel establishment module 510, a first alarm module 520, a second alarm module 530, and a monitoring module 540.

[0114] The channel establishment module 510 is used to establish a configuration channel corresponding to the device to be managed, and to mark the device to be managed as a managed device if the channel is successfully established; wherein, the device to be managed includes out-of-band devices of homogeneous and / or heterogeneous entities. In one embodiment, the channel establishment module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0115] The first alarm module 520 is used to receive the first alarm message sent by the managed device through the corresponding configuration channel in real time, and to perform distributed batch processing on the first alarm message to obtain the first alarm information. In one embodiment, the first alarm module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0116] The second alarm module 530 is used to scan the managed devices according to a preset message format through an active polling mechanism to obtain second alarm information. In one embodiment, the second alarm module 530 can be used to perform the operation S230 described above, which will not be repeated here.

[0117] The monitoring module 540 is used to monitor the managed devices based on the first alarm information and / or the second alarm information. In one embodiment, the monitoring module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0118] According to an embodiment of this application, the first alarm module 520 includes: a message queue unit, used to construct a message queue instance and configure cluster parameters of the message queue cluster; wherein the message queue cluster is composed of distributed server nodes; a message processing unit, used to receive the first alarm message based on the message queue instance and perform format conversion processing on the first alarm message to obtain first alarm data; a first data forwarding unit, used to forward the first alarm data to the corresponding message queue cluster according to the cluster parameters; a second data forwarding unit, used to forward the first alarm data to the stream processing task cluster through the message queue cluster; and a stream processing unit, used to process the first alarm data in real time through the stream processing task cluster.

[0119] According to an embodiment of this application, the stream processing unit includes: a message reassembly subunit, configured to reassemble the first alarm data based on the preset message format through the stream processing task cluster to obtain a reassembled message; a message parsing subunit, configured to parse the reassembled message to obtain message keywords; and a data mapping subunit, configured to map the first alarm data to standard alarm information based on the message keywords to obtain the first alarm information.

[0120] According to an embodiment of this application, the second alarm module 530 includes: a scanning unit, used to scan the managed devices through the active polling mechanism based on the intelligent platform management interface protocol to obtain the device status information of the managed devices; a message creation unit, used to create a second alarm message according to the preset message format and the device status information; and an information extraction unit, used to extract the second alarm information based on the second alarm message.

[0121] According to an embodiment of this application, the channel establishment module 510 includes: a trap function activation unit, used to activate the trap function of the managed device based on the Simple Network Management Protocol; a trap channel establishment unit, used to establish a trap channel with the managed device according to the activated trap function, so that the managed device can send simulated messages through the trap channel; and a simulated message receiving unit, used to receive the simulated messages of the managed device to complete the establishment of the configuration channel corresponding to the managed device.

[0122] According to an embodiment of this application, the channel establishment module 510 further includes: a secondary establishment unit, used to re-establish a configuration channel corresponding to the managed device if no simulated message is received from the managed device; and a prompting unit, used to prompt a failure message and initiate a manual operation request if the re-establishment fails.

[0123] According to embodiments of this application, any multiple modules among the channel establishment module 510, the first alarm module 520, the second alarm module 530, and the monitoring module 540 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the channel establishment module 510, the first alarm module 520, the second alarm module 530, and the monitoring module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the channel establishment module 510, the first alarm module 520, the second alarm module 530, and the monitoring module 540 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0124] Figure 6A block diagram schematically illustrates an electronic device suitable for implementing an out-of-band device monitoring method according to an embodiment of this application.

[0125] like Figure 6 As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0126] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0127] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0128] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0129] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0130] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the out-of-band device monitoring method provided in the embodiments of this application.

[0131] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0132] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0133] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0134] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0135] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0136] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A method for monitoring out-of-band devices, characterized in that, Applied to the control terminal, the method includes: Establish a configuration channel corresponding to the device to be managed, and mark the device to be managed as a managed device if the channel is successfully established; wherein, the device to be managed includes out-of-band devices with homogeneous and / or heterogeneous main bodies; The system receives the first alarm message sent by the managed device through the corresponding configuration channel in real time, and performs distributed batch processing on the first alarm message to obtain the first alarm information. According to a preset message format, the managed devices are scanned using an active polling mechanism to obtain the second alarm information; and Based on the first alarm information and / or the second alarm information, monitor the managed devices.

2. The method according to claim 1, characterized in that, The step of performing distributed batch processing on the first alarm message includes: Build a message queue instance and configure the cluster parameters of the message queue cluster; wherein the message queue cluster consists of distributed server nodes; The message queue instance receives the first alarm message and performs format conversion processing on the first alarm message to obtain the first alarm data. Based on the cluster parameters, the first alarm data is forwarded to the corresponding message queue cluster; The message queue cluster forwards the first alarm data to the stream processing task cluster; and The first alarm data is processed in real time by the stream processing task cluster.

3. The method according to claim 2, characterized in that, The real-time processing of the first alarm data through the stream processing task cluster includes: The first alarm data is reconstructed based on the preset message format through the stream processing task cluster to obtain a reconstructed message; Parse the reconstructed message to obtain the message keyword; and Based on the message keywords, the first alarm data is mapped to standard alarm information to obtain the first alarm information.

4. The method according to claim 1, characterized in that, The step of scanning the managed devices through an active polling mechanism according to a preset message format includes: Based on the intelligent platform management interface protocol, the managed devices are scanned through the active polling mechanism to obtain the device status information of the managed devices; Based on the preset message format and the device status information, a second alarm message is created; and The second alarm information is extracted based on the second alarm message.

5. The method according to claim 1, characterized in that, The establishment of a configuration channel corresponding to the device to be managed includes: Based on the Simple Network Management Protocol, enable the trap function of the managed device; Based on the activated trap function, a trap channel is established with the managed device, enabling the managed device to send simulated messages through the trap channel; and Receive the simulated message from the device under management to establish the configuration channel corresponding to the device under management.

6. The method according to claim 5, characterized in that, The method further includes: If no simulated message is received from the managed device, a new configuration channel corresponding to the managed device is established; and If the creation fails again, a failure message will be displayed, and a manual operation request will be initiated.

7. An external device monitoring device, characterized in that, The device includes: The channel establishment module is used to establish a configuration channel corresponding to the device to be managed, and to mark the device to be managed as a managed device if the channel is successfully established; wherein, the device to be managed includes out-of-band devices of homogeneous and / or heterogeneous entities; The first alarm module is used to receive the first alarm message sent by the managed device through the corresponding configuration channel in real time, and to perform distributed batch processing on the first alarm message to obtain the first alarm information. The second alarm module is used to scan the managed devices according to a preset message format using an active polling mechanism to obtain second alarm information; and The monitoring module is used to monitor the managed devices based on the first alarm information and / or the second alarm information.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

Images