Monitoring data acquisition method, device, equipment, medium and computer program product

Abstract

The invention discloses a monitoring data acquisition method, device and equipment, a medium and a computer program product, and the method comprises the steps: responding to a data acquisition request sent by a prometheus node, and calling an agent in a corresponding white-box switch according to the data acquisition request; the agent is an acquisition program deployed on the white box switch; reading a redis database in the white box switch through the agent, obtaining monitoring data of the white box switch according to the redis database, and transmitting the monitoring data back to the prometheus node; and the redis database stores the real-time state data of the white-box switch. According to the invention, a prometheus architecture is adopted, the agent is developed and deployed in the white-box switch, the monitoring data of the white-box switch is directly acquired, and the acquisition efficiency of the monitoring data is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a monitoring data acquisition method, apparatus, equipment, medium, and computer program product. Background Technology

[0002] Currently, common switch monitoring technologies are mainly based on SNMP (Simple Network Management Protocol). SNMP, as a traditional network management standard protocol widely used in TCP / IP networks, provides a unified way for network management systems (NMS) to monitor, configure, and manage devices connected to the network.

[0003] However, SNMP collects monitoring data through a polling mechanism, which is far less efficient than Prometheus (by a factor of 70). Furthermore, SNMP's object identifiers (OIDs) are distributed in a tree structure, and traversing this tree structure makes SNMP data processing much slower, making it unsuitable for collecting large-scale time-series data. Summary of the Invention

[0004] The purpose of this invention is to provide a monitoring data acquisition method, device, equipment, medium, and computer program product. It adopts the Prometheus architecture and directly acquires monitoring data from white-box switches by developing and deploying an agent in the white-box switch, thereby effectively improving the acquisition efficiency of monitoring data.

[0005] To achieve the above objectives, embodiments of the present invention provide a monitoring data acquisition method, including: In response to a data collection request sent by a Prometheus node, the agent in the corresponding white-box switch is invoked according to the data collection request; the agent is a collection program deployed on the white-box switch. The agent reads the Redis database in the white-box switch, obtains the monitoring data of the white-box switch based on the Redis database, and sends the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

[0006] As an improvement to the above scheme, the step of responding to a data collection request sent by a Prometheus node and invoking the agent in the corresponding white-box switch according to the data collection request includes: In response to a data collection request sent by a Prometheus node, an HTTP request is sent to the corresponding monitoring endpoint of the white-box switch according to the data collection request, thereby invoking the agent in the white-box switch.

[0007] As an improvement to the above solution, the step of reading the Redis database in the white-box switch through the agent, obtaining the monitoring data of the white-box switch based on the Redis database, and sending the monitoring data back to the Prometheus node includes: The agent reads the Redis database in the white-box switch. The original monitoring data of the white-box switch is obtained from the Redis database, and the format of the original monitoring data is converted into the Prometheus time-series data format to obtain the monitoring data. The monitoring data is transmitted back to the Prometheus node via the endpoint of the white-box switch.

[0008] As an improvement to the above solution, the method further includes: Write the change information of the white-box switch into the message middleware; The configuration update service listens to the message middleware and generates a device list file based on the change information; Load the device list file into the Prometheus node.

[0009] As an improvement to the above scheme, the message middleware is the message queue etcd.

[0010] As an improvement to the above solution, the method further includes: The alarm rules for the monitoring data are customized in the Prometheus node according to the preset monitoring indicators; When the alarm rule is met, the alarm information is pushed to the alarm module of the Prometheus node and reported via Webhook.

[0011] This invention also provides a monitoring data acquisition device, comprising: The agent invocation module is used to respond to data collection requests sent by Prometheus nodes and invoke the corresponding agent in the white-box switch according to the data collection request; the agent is the collection program deployed on the white-box switch. The monitoring data acquisition module is used to read the Redis database in the white-box switch through the agent, obtain the monitoring data of the white-box switch based on the Redis database, and send the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

[0012] This invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the monitoring data acquisition method described in any of the above embodiments.

[0013] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the monitoring data acquisition method described above.

[0014] This invention also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the monitoring data acquisition method described above.

[0015] Compared to existing technologies, the beneficial effects of the monitoring data acquisition method, apparatus, device, medium, and computer program product provided in this embodiment of the invention are as follows: In response to a data acquisition request sent by a Prometheus node, the corresponding agent in the white-box switch is invoked according to the data acquisition request; the agent is a acquisition program deployed on the white-box switch; the agent reads the Redis database in the white-box switch, obtains the monitoring data of the white-box switch from the Redis database, and sends the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch. This embodiment of the invention adopts the Prometheus architecture and, by developing and deploying an agent in the white-box switch, directly acquires the monitoring data of the white-box switch, effectively improving the efficiency of monitoring data acquisition. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a preferred embodiment of a monitoring data acquisition method provided by the present invention; Figure 2 This is an interactive schematic diagram of a monitoring data acquisition method provided by the present invention; Figure 3 This is an interactive diagram illustrating the configuration update process in a monitoring data acquisition method provided by the present invention. Figure 4 This is a schematic diagram of a preferred embodiment of a monitoring data acquisition device provided by the present invention; Figure 5 This is a schematic diagram of a preferred embodiment of a terminal device provided by the present invention. Detailed Implementation

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

[0018] Please see Figure 1 , Figure 1 This is a flowchart illustrating a preferred embodiment of a monitoring data acquisition method provided by the present invention. The monitoring data acquisition method includes: S1, in response to the data collection request sent by the Prometheus node, the agent in the corresponding white-box switch is invoked according to the data collection request; the agent is the collection program deployed on the white-box switch; S2, the agent reads the Redis database in the white-box switch, obtains the monitoring data of the white-box switch based on the Redis database, and sends the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

[0019] For details, please refer to Figure 2 , Figure 2This is an interactive schematic diagram of a monitoring data acquisition method provided by the present invention. This embodiment of the invention provides a monitoring data acquisition method for a switch, fully utilizing the characteristics of a white-box switch, namely, the system itself is a complete and open network operating system, which can use custom methods for rule distribution and data acquisition to achieve more flexible network forwarding and data processing capabilities. Unlike the traditional SNMP method of switches, this embodiment of the invention uses the SDK of the powerful open-source monitoring software Prometheus for monitoring data acquisition. By responding to the data acquisition request sent by the Prometheus node, the corresponding agent in the white-box switch is invoked according to the data acquisition request. It should be noted that a white-box switch is a switch based on open standards and programmable hardware. Its core feature is the decoupling of hardware and software, allowing users to freely choose or customize the operating system (such as a network operating system, Sonic, NOS) and application functions according to their needs. The agent is the acquisition program deployed on the white-box switch. The Prometheus node sends a data acquisition request to at least one white-box switch, meaning that the Prometheus node can simultaneously collect monitoring data from multiple white-box switches. The agent can directly read the Redis database in the white-box switch. The Redis database stores real-time status data of the white-box switch (such as port traffic, queue length, error packet count, etc.). The agent obtains incremental data by subscribing to Redis key-value changes or by periodically polling, avoiding the performance overhead of full scans. Monitoring data of the white-box switch is obtained based on the port traffic in the Redis database and then sent back to the Prometheus node.

[0020] It should be noted that this embodiment of the invention can also provide a front-end page through the management and control system, allowing users to view various monitoring data of each white-box switch. In actual production use, Prometheus can support the monitoring system to visualize data up to 30 days in advance, demonstrating certain advantages in both time and spatial performance. In the time dimension, monitoring graphs in the production system can be displayed in seconds, simplifying the workload of daily monitoring and maintenance of equipment. In the spatial dimension, Prometheus's excellent data compression algorithm (based on the Gorilla algorithm from Facebook) allows monitoring data from the past 90 days to be stored entirely on a standalone server.

[0021] This invention adopts the Prometheus architecture and leverages the programmable nature of white-box switches. By developing and deploying an agent in the white-box switch to expose the monitoring interface, Prometheus nodes can directly capture the monitoring data of the white-box switch, effectively improving the efficiency of monitoring data collection.

[0022] In another preferred embodiment, step S1, in response to a data collection request sent by a Prometheus node, involves invoking the agent in the corresponding white-box switch according to the data collection request, including: S11, in response to the data collection request sent by the Prometheus node, an HTTP request is sent to the corresponding monitoring endpoint of the white-box switch according to the data collection request, and the agent in the white-box switch is invoked.

[0023] Specifically, since Prometheus typically uses the HTTP protocol to capture monitoring data, this embodiment of the invention responds to the data collection request sent by the Prometheus node by sending an HTTP request to the monitoring endpoint of the corresponding white-box switch, calling the agent in the white-box switch, and exposing the endpoint externally via HTTP REST API for the Prometheus node to collect monitoring data.

[0024] In another preferred embodiment, step S2, which involves reading the Redis database in the white-box switch through the agent, obtaining monitoring data of the white-box switch based on the Redis database, and sending the monitoring data back to the Prometheus node, includes: S21, the agent reads the Redis database in the white-box switch; S22, Obtain the original monitoring data of the white-box switch from the Redis database, and convert the format of the original monitoring data into the Prometheus time-series data format to obtain the monitoring data; S23, the monitoring data is transmitted back to the Prometheus node through the endpoint of the white-box switch.

[0025] Specifically, in this embodiment of the invention, an agent is developed and deployed in a white-box switch. This agent can directly read the Redis database in the sonic system of the white-box switch. The Redis database stores real-time status data of the white-box switch (such as port traffic, queue length, error packet count, etc.). The agent obtains incremental data by subscribing to Redis key-value changes or by periodically polling, avoiding the performance overhead of full scans. Monitoring data of the white-box switch is obtained based on the port traffic in the Redis database, and the format of the raw monitoring data in Redis is converted into Prometheus time-series data format to obtain the monitoring data. The agent of the white-box switch starts an HTTP server, providing a monitoring endpoint conforming to the Prometheus specification, and transmits the monitoring data back to the Prometheus node through the endpoint.

[0026] In yet another preferred embodiment, the method further includes: Write the change information of the white-box switch into the message middleware; The configuration update service listens to the message middleware and generates a device list file based on the change information; Load the device list file into the Prometheus node.

[0027] It's important to note that device information for Prometheus data collection is typically manually entered into the Prometheus configuration file. Every time a node is added or removed (i.e., a white-box switch is added or removed from the network), this configuration file must be rewritten, and the Prometheus server must be manually restarted. In situations with frequent changes in the production network, it's easy to miss steps like modifying the configuration file or restarting the service, resulting in monitoring failures.

[0028] Based on this, this embodiment of the invention designs a scheme that utilizes Prometheus's native service discovery mechanism for automatic node information updates and automatic configuration file loading, according to the control plane architecture. For details, please refer to... Figure 3 , Figure 3This is a schematic diagram illustrating the configuration update interaction in a monitoring data acquisition method provided by this invention. Since the objects for which Prometheus nodes collect monitoring data correspond to a device entity in the control plane (management system), each time a device is added or removed from the control plane, change information can be written to the control plane's message middleware to notify the entire system that a white-box switch has joined or left the cluster. The server deploying the Prometheus nodes starts a new configuration update service. This service listens to the message middleware and, based on its stored device list, adds the newly added or removed devices to regenerate the device list file. The Prometheus nodes are configured with a service list file, which is reloaded periodically to automatically update the service list of the Prometheus nodes.

[0029] This invention utilizes Prometheus's native service discovery mechanism, employing a method of writing message middleware when dynamically adding or deleting monitoring entities and listening to the message middleware on the monitoring server to automatically distribute, configure, and load white-box monitoring configurations. This achieves automatic configuration loading and discovery, reducing the workload of operation and maintenance.

[0030] As a preferred option, the message middleware is the message queue etcd.

[0031] For example, in this embodiment of the invention, the message middleware is the message queue etcd. Each time a device is added or removed from the control plane, change information can be written to the control plane's message queue etcd. The server deploying Prometheus starts a new configuration update service. This service listens to the message queue etcd and regenerates the device list file based on the device list stored in its memory, adding the newly added or removed devices. Prometheus is configured with a service list file, which is reloaded periodically to collect and monitor the device list file.

[0032] In yet another preferred embodiment, the method further includes: The alarm rules for the monitoring data are customized in the Prometheus node according to the preset monitoring indicators; When the alarm rule is met, the alarm information is pushed to the alarm module of the Prometheus node and reported via Webhook.

[0033] Specifically, as a supplement to traditional monitoring solutions such as SNMP, this embodiment of the invention also employs Prometheus' native alarm module, AlertManager, as a complement to the SNMP Trap alarm solution. Prometheus provides a powerful query language, PromQL, which can be used to customize alarm rules for monitoring data and send notifications based on the alarm configuration. This embodiment of the invention uses the configured controller REST interface URL as a webhook, and the controller reports a custom alarm when the alarm threshold is met.

[0034] In this embodiment of the invention, the alarm function of Prometheus is more flexible. It can customize any rules based on monitoring data and can configure webhooks for custom alarm reporting.

[0035] Accordingly, the present invention also provides a monitoring data acquisition device capable of implementing all the processes of the monitoring data acquisition method in the above embodiments.

[0036] Please see Figure 4 , Figure 4 This is a schematic diagram of a preferred embodiment of a monitoring data acquisition device provided by the present invention. The monitoring data acquisition device includes: The agent calling module 401 is used to respond to the data collection request sent by the Prometheus node and call the corresponding agent in the white-box switch according to the data collection request; the agent is the collection program deployed on the white-box switch. The monitoring data acquisition module 402 is used to read the Redis database in the white-box switch through the agent, obtain the monitoring data of the white-box switch according to the Redis database, and send the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

[0037] Specifically, this invention provides a monitoring data acquisition device for a switch, fully utilizing the characteristics of a white-box switch—that is, the system itself is a complete and open network operating system, allowing for custom rule distribution and data acquisition to achieve more flexible network forwarding and data processing capabilities. Unlike the traditional SNMP method used by switches, this invention employs the SDK of the powerful open-source monitoring software Prometheus for monitoring data acquisition. The agent calling module responds to data acquisition requests sent by the Prometheus node, invoking the corresponding agent in the white-box switch based on the data acquisition request. It should be noted that a white-box switch is a switch based on open standards and programmable hardware, its core feature being hardware and software decoupling, allowing users to freely choose or customize operating systems (such as network operating systems, Sonic, NOS) and application functions according to their needs. The agent is the acquisition program deployed on the white-box switch. The Prometheus node sends data acquisition requests to at least one white-box switch, meaning the Prometheus node can simultaneously collect monitoring data from multiple white-box switches. The monitoring data acquisition module can directly read the Redis database in the white-box switch via an agent. The Redis database stores real-time status data of the white-box switch (such as port traffic, queue length, and error packet count). The agent obtains incremental data by subscribing to Redis key-value changes or by periodically polling, avoiding the performance overhead of a full scan. Based on the port traffic data in the Redis database, the module obtains the monitoring data of the white-box switch and sends this data back to the Prometheus node.

[0038] It should be noted that this embodiment of the invention can also provide a front-end page through the management and control system, allowing users to view various monitoring data of each white-box switch. In actual production use, Prometheus can support the monitoring system to visualize data up to 30 days in advance, demonstrating certain advantages in both time and spatial performance. In the time dimension, monitoring graphs in the production system can be displayed in seconds, simplifying the workload of daily monitoring and maintenance of equipment. In the spatial dimension, Prometheus's excellent data compression algorithm (based on the Gorilla algorithm from Facebook) allows monitoring data from the past 90 days to be stored entirely on a standalone server.

[0039] This invention adopts the Prometheus architecture and leverages the programmable nature of white-box switches. By developing and deploying an agent in the white-box switch to expose the monitoring interface, Prometheus nodes can directly capture the monitoring data of the white-box switch, effectively improving the efficiency of monitoring data collection.

[0040] Preferably, the agent calling module 401 is specifically used for: In response to a data collection request sent by a Prometheus node, an HTTP request is sent to the corresponding monitoring endpoint of the white-box switch according to the data collection request, thereby invoking the agent in the white-box switch.

[0041] Specifically, since Prometheus typically uses the HTTP protocol to capture monitoring data, this embodiment of the invention responds to the data collection request sent by the Prometheus node by sending an HTTP request to the monitoring endpoint of the corresponding white-box switch, calling the agent in the white-box switch, and exposing the endpoint externally via HTTP REST API for the Prometheus node to collect monitoring data.

[0042] Preferably, the monitoring data acquisition module 402 includes: A database reading unit is used to read the Redis database in the white-box switch via the agent; The data format conversion unit is used to obtain the original monitoring data of the white-box switch from the Redis database, and convert the format of the original monitoring data into the Prometheus time-series data format to obtain the monitoring data. The monitoring data backhaul unit is used to backhaul the monitoring data to the Prometheus node through the endpoint of the white-box switch.

[0043] Specifically, in this embodiment of the invention, an agent is developed and deployed in a white-box switch. This agent can directly read the Redis database in the sonic system of the white-box switch. The Redis database stores real-time status data of the white-box switch (such as port traffic, queue length, error packet count, etc.). The agent obtains incremental data by subscribing to Redis key-value changes or by periodically polling, avoiding the performance overhead of full scans. Monitoring data of the white-box switch is obtained based on the port traffic in the Redis database, and the format of the raw monitoring data in Redis is converted into Prometheus time-series data format to obtain the monitoring data. The agent of the white-box switch starts an HTTP server, providing a monitoring endpoint conforming to the Prometheus specification, and transmits the monitoring data back to the Prometheus node through the endpoint.

[0044] Preferably, the device further includes a configuration update module for: Write the change information of the white-box switch into the message middleware; The configuration update service listens to the message middleware and generates a device list file based on the change information; Load the device list file into the Prometheus node.

[0045] It's important to note that device information for Prometheus data collection is typically manually entered into the Prometheus configuration file. Every time a node is added or removed (i.e., a white-box switch is added or removed from the network), this configuration file must be rewritten, and the Prometheus server must be manually restarted. In situations with frequent changes in the production network, it's easy to miss steps like modifying the configuration file or restarting the service, resulting in monitoring failures.

[0046] Based on this, this embodiment of the invention designs a configuration update module that utilizes Prometheus's native service discovery mechanism to automatically update node information and load configuration files, according to the control plane architecture. Specifically, since the object collecting monitoring data by the Prometheus node corresponds to a device entity in the control plane (management system), each time a device is added or removed from the control plane, change information can be written to the control plane's message middleware to notify the entire system that a white-box switch has joined or left the cluster. The server deploying the Prometheus node starts a new configuration update service. This service listens to the message middleware and, based on its stored device list, adds the newly added or removed devices to regenerate the device list file. The Prometheus node is configured with a service list file, which is reloaded periodically to automatically update the Prometheus node's service list.

[0047] This invention utilizes Prometheus's native service discovery mechanism, employing a method of writing message middleware when dynamically adding or deleting monitoring entities and listening to the message middleware on the monitoring server to automatically distribute, configure, and load white-box monitoring configurations. This achieves automatic configuration loading and discovery, reducing the workload of operation and maintenance.

[0048] Preferably, the message middleware is the message queue etcd.

[0049] For example, in this embodiment of the invention, the message middleware is the message queue etcd. Each time a device is added or removed from the control plane, change information can be written to the control plane's message queue etcd. The server deploying Prometheus starts a new configuration update service. This service listens to the message queue etcd and regenerates the device list file based on the device list stored in its memory, adding the newly added or removed devices. Prometheus is configured with a service list file, which is reloaded periodically to collect and monitor the device list file.

[0050] Preferably, the device further includes a monitoring and alarm module, used for: The alarm rules for the monitoring data are customized in the Prometheus node according to the preset monitoring indicators; When the alarm rule is met, the alarm information is pushed to the alarm module of the Prometheus node and reported via Webhook.

[0051] Specifically, as a supplement to traditional monitoring solutions such as SNMP, this embodiment of the invention also employs Prometheus' native alarm module, AlertManager, as a complement to the SNMP Trap alarm solution. Prometheus provides a powerful query language, PromQL, which can be used to customize alarm rules for monitoring data and send notifications based on the alarm configuration. This embodiment of the invention uses the configured controller REST interface URL as a webhook, and the controller reports a custom alarm when the alarm threshold is met.

[0052] In this embodiment of the invention, the alarm function of Prometheus is more flexible. It can customize any rules based on monitoring data and can configure webhooks for custom alarm reporting.

[0053] In specific implementation, the working principle, control process and technical effects of the monitoring data acquisition device provided in the embodiments of the present invention are the same as those of the monitoring data acquisition method in the above embodiments, and will not be repeated here.

[0054] Please see Figure 5 , Figure 5 This is a schematic diagram of a preferred embodiment of a terminal device provided by the present invention. The terminal device includes a processor 501, a memory 502, and a computer program stored in the memory 502 and configured to be executed by the processor 501. When the processor 501 executes the computer program, it implements the monitoring data acquisition method described in any of the above embodiments.

[0055] Preferably, the computer program can be divided into one or more modules / units (such as computer program 1, computer program 2, ...), and the one or more modules / units are stored in the memory 502 and executed by the processor 501 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.

[0056] The processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor 501 may be any conventional processor. The processor 501 is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0057] The memory 502 mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., and the data storage area can store related data, etc. In addition, the memory 502 can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard disk, a smart media card (SMC), a secure digital card (SD), and a flash card, etc., or the memory 502 can also be other volatile solid-state storage devices.

[0058] It should be noted that the aforementioned terminal devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 5 The structural diagram is merely an example of the terminal device described above and does not constitute a limitation on the terminal device described above. It may include more or fewer components than shown in the diagram, or combine certain components, or use different components.

[0059] This invention also provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program, when running, controls the device where the computer-readable storage medium is located to execute the monitoring data acquisition method described in any of the above embodiments.

[0060] This invention also provides a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the monitoring data acquisition method described in any of the above embodiments.

[0061] This invention provides a monitoring data acquisition method, apparatus, device, medium, and computer program product. In response to a data acquisition request sent by a Prometheus node, the method invokes an agent in a corresponding white-box switch according to the data acquisition request. The agent is a data acquisition program deployed on the white-box switch. The agent reads the Redis database in the white-box switch, obtains the monitoring data of the white-box switch from the Redis database, and sends the monitoring data back to the Prometheus node. The Redis database stores the real-time status data of the white-box switch. This invention adopts a Prometheus architecture and, by developing and deploying an agent in the white-box switch, directly acquires the monitoring data of the white-box switch, effectively improving the efficiency of monitoring data acquisition.

[0062] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the system embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0063] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for acquiring monitoring data, characterized in that, include: In response to a data collection request sent by a Prometheus node, the corresponding data collection agent in the white-box switch is invoked according to the data collection request; the agent is a collection program deployed on the white-box switch. The agent reads the Redis database in the white-box switch, obtains the monitoring data of the white-box switch based on the Redis database, and sends the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

2. The monitoring data acquisition method as described in claim 1, characterized in that, The response to the data collection request sent by the Prometheus node, including invoking the agent in the corresponding white-box switch according to the data collection request, includes: In response to a data collection request sent by a Prometheus node, an HTTP request is sent to the corresponding monitoring endpoint of the white-box switch according to the data collection request, thereby invoking the agent in the white-box switch.

3. The monitoring data acquisition method as described in claim 2, characterized in that, The step of reading the Redis database in the white-box switch through the agent, obtaining the monitoring data of the white-box switch based on the Redis database, and sending the monitoring data back to the Prometheus node includes: The agent reads the Redis database in the white-box switch. The original monitoring data of the white-box switch is obtained from the Redis database, and the format of the original monitoring data is converted into the Prometheus time-series data format to obtain the monitoring data. The monitoring data is transmitted back to the Prometheus node via the endpoint of the white-box switch.

4. The monitoring data acquisition method as described in claim 1, characterized in that, The method further includes: Write the change information of the white-box switch into the message middleware; The configuration update service listens to the message middleware and generates a device list file based on the change information; Load the device list file into the Prometheus node.

5. The monitoring data acquisition method as described in claim 4, characterized in that, The message middleware is the message queue etcd.

6. The monitoring data acquisition method as described in claim 1, characterized in that, The method further includes: The alarm rules for the monitoring data are customized in the Prometheus node according to the preset monitoring indicators; When the alarm rule is met, the alarm information is pushed to the alarm module of the Prometheus node and reported via Webhook.

7. A monitoring data acquisition device, characterized in that, include: The agent invocation module is used to respond to data collection requests sent by Prometheus nodes and invoke the corresponding agent in the white-box switch according to the data collection request; the agent is the collection program deployed on the white-box switch. The monitoring data acquisition module is used to read the Redis database in the white-box switch through the agent, obtain the monitoring data of the white-box switch based on the Redis database, and send the monitoring data back to the Prometheus node; the Redis database stores the real-time status data of the white-box switch.

8. A terminal device, characterized in that, The device includes a processor and a memory, the memory storing a computer program configured to be executed by the processor, wherein the processor, when executing the computer program, implements the monitoring data acquisition method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the device containing the computer-readable storage medium executes the computer program, it implements the monitoring data acquisition method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program or computer instructions, which, when executed by a processor, implement the monitoring data acquisition method as described in any one of claims 1 to 6.

Images