Monitoring alarm method and system and computer readable storage medium

Abstract

The invention provides a monitoring alarm method and system, and a computer readable storage medium, and solves the problems that the mode of directly pulling monitoring data is not flexible enough, is poor in expandability and is not safe enough when monitored equipment is in a state that the monitored equipment is limited to be accessed by a public network. The method is applied to the monitoring alarm system, the monitoring alarm system comprises at least one first server and a second server, each first server is deployed on a monitored device in the same local area network, and the local area network is in a state of being limited by public network access; the method comprises the following steps: acquiring target monitoring data of monitored equipment located in the same local area network as a first server based on the local area network through each first server; acquiring a public network access address of a second server through each first server, and pushing the target monitoring data to the second server; and receiving the target monitoring data from each first server through the second server, and carrying out monitoring alarm on the monitored equipment.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of monitoring, and in particular to a monitoring alarm method, system and computer readable storage medium. BACKGROUND

[0002] In the field of operation and maintenance management of information systems, the monitoring alarm system plays a crucial role. It not only ensures the stable operation of the information system, but also discovers and solves potential problems in time, thereby avoiding or reducing the impact of information system failures.

[0003] At present, existing monitoring solutions, such as using Prometheus combined with cAdvisor, have been applied in multiple scenarios. These monitoring solutions adopt a pull data method, which requires the monitoring server to access the monitored device, thus facing challenges when the monitored device is in a public network access limited state.

[0004] For example, in the scenario of network isolation or security restriction (such as unmanned mixing station scenario), Prometheus cannot directly pull data from cAdvisor. In this case, the implementation of the monitoring solution can include the following two ways: way ①, Prometheus and cAdvisor are deployed in the same network, and Prometheus can access the cAdvisor deployed on the monitored device through the local area network; way ②, the node of cAdvisor (i.e. the monitored device where cAdvisor is located) is configured with a public network accessible address, i.e. the node of cAdvisor has a public network access address that allows Prometheus to access. However, the above way ① has the problems of inflexible deployment of the monitoring alarm system and poor scalability, and both way ① and way ② need to directly pull data from the monitored device, which is not secure. SUMMARY

[0005] The purpose of the present disclosure is to provide a monitoring alarm method, system and computer readable storage medium to at least alleviate one of the problems of inflexible, poor scalability and insecurity of the direct pull monitoring data method when the monitored device is in a public network access limited state.

[0006] In a first aspect, the embodiments of the present disclosure provide a monitoring alarm method applied to a monitoring alarm system, the monitoring alarm system comprising at least one first server and a second server, each first server being deployed on a monitored device, the first server and the monitored device being in the same local area network, and the local area network to which the monitored device belongs being in a public network access limited state.

[0007] The monitoring alarm method comprises:

[0008] acquire, by each of the first service ends, target monitoring data of the monitored device in the same local area network as the first service end based on the local area network;

[0009] acquire, by each of the first service ends, a public network access address of the second service end, and push the target monitoring data to the second service end through the public network access address of the second service end;

[0010] receive, by the second service end, the target monitoring data from each of the first service ends, and perform monitoring and alarm on the monitored device based on the target monitoring data.

[0011] In a second aspect, the embodiments of the present disclosure further provide a monitoring and alarm system, comprising: at least one first service end and a second service end; each of the first service ends is deployed on a monitored device, the first service end is deployed in the same local area network as the monitored device where the first service end is located; and the local area network to which the monitored device belongs is in a public network access limited state;

[0012] The first service end is configured to acquire target monitoring data of the monitored device in the same local area network as the first service end based on the local area network.

[0013] The first service end is further configured to acquire a public network access address of the second service end, and push the target monitoring data to the second service end through the public network access address of the second service end.

[0014] The second service end is configured to receive the target monitoring data from each of the first service ends, and perform monitoring and alarm on the monitored device based on the target monitoring data.

[0015] In a third aspect, the embodiments of the present disclosure further provide a computer readable storage medium, which stores computer executable instructions, and when the computer executable instructions are called and run by a processor, the computer executable instructions cause the processor to run the monitoring and alarm method of the first aspect.

[0016] The embodiments of the present disclosure bring the following beneficial effects:

[0017] The method is applied to a monitoring and alarming system, the monitoring and alarming system comprises at least one first service end and a second service end, each first service end is deployed on a monitored device, the first service end is in the same local area network as the monitored device where the first service end is located, and the local area network to which the monitored device belongs is in a limited public network access state; when monitoring and alarming is performed, each first service end can obtain target monitoring data of the monitored device in the same local area network as the first service end based on the local area network; the public network access address of the second service end is obtained by each first service end, and the target monitoring data is pushed to the second service end through the public network access address of the second service end; the target monitoring data from each first service end is received by the second service end, and the monitored device is monitored and alarmed based on the target monitoring data. In this way, the monitoring and alarming system is divided into two parts of the first service end and the second service end, the first service end is deployed on the monitored device in the same local area network, although the local area network to which the first service end belongs is in a limited public network access state, the first service end can push the monitoring data to the second service end through the public network access address of the second service end, so as to perform monitoring and alarming through the second service end, and the monitoring and alarming of the monitored device in a network isolation or a safe limited environment is realized. Since the first service end adopts a push data mode and is not allowed to be accessed by the public network, the monitored device cannot be accessed by the outside through the first service end, and the security of the monitored device is improved; and the deployment mode of the monitoring and alarming system is relatively flexible, when the monitored device is changed, only the corresponding first service end needs to be adaptively deployed according to the monitored device, and the scalability is relatively strong. Therefore, the problems that the direct pull monitoring data mode is not flexible, has poor scalability and is not safe when the monitored device is in a limited public network access state can be alleviated.

[0018] In order to make the above objectives, characteristics and advantages of the present disclosure more obvious and easy to understand, the following preferred embodiments are specifically described below, and the accompanying drawings are described in detail as follows. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or the prior art description. Obviously, the drawings in the following description are some embodiments of the present disclosure, and those skilled in the art can also obtain other drawings according to these drawings without any creative effort.

[0020] Figure 1 The architecture schematic diagram of the prior monitoring and alarming system;

[0021] Figure 2A structural schematic diagram of a monitoring and alarming system provided by an embodiment of the present disclosure is shown in FIG. 1.

[0022] Figure 3 A structural schematic diagram of a monitoring and alarming system provided by an embodiment of the present disclosure is shown in FIG. 1.

[0023] Figure 4 A structural schematic diagram of a monitoring and alarming system provided by an embodiment of the present disclosure is shown in FIG. 1. DETAILED DESCRIPTION

[0024] To make the objectives, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions of the present disclosure will be described below in detail with reference to the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, but not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present disclosure.

[0025] The terms "comprise" and "have" and any variations thereof mentioned in the embodiments of the present disclosure are intended to cover the inclusions without exclusivity. For example, a process, method, system, product or device that includes a list of steps or units is not limited to the listed steps or units, but can optionally include other steps or units not listed or can optionally include other steps or units inherent to such processes, methods, products or devices.

[0026] At present, the traditional monitoring system mainly focuses on hardware indicators such as CPU usage, memory usage, disk usage and network I / O (Input / Output).

[0027] In the existing monitoring technical solution, the index monitoring system constructed based on Prometheus+Grafana+cAdvisor is a widely used solution. As shown in FIG. 2, the core components of this solution include: Figure 1

[0028] (1) Prometheus

[0029] ​Prometheus is an open-source monitoring and alerting tool suite widely used for recording real-time time series data. It works by scraping metrics from configured targets, storing this data, and providing a powerful query language (PromQL) to retrieve and process this data. Prometheus is particularly well-suited for handling multi-dimensional data, such as the metrics provided by container management platforms like Kubernetes. Prometheus is widely popular due to its simplicity, powerful features, and adaptability to cloud-native environments.

[0030] Main features:

[0031] 1. Multi-dimensional data model: Prometheus uses time series data, each identified by a unique metric name and key values, labeled by a set of labels.

[0032] 2. Flexible query language: PromQL, the Prometheus Query Language, is used for real-time data querying and aggregation.

[0033] 3. Independent of distributed storage: Prometheus servers are standalone and do not rely on network storage.

[0034] 4. Service discovery or static configuration: Supports discovering scraping targets through service discovery or static configuration.

[0035] 5. Multiple graph and dashboard forms: Provides powerful data visualization through integration with tools like Grafana.

[0036] (2) Grafana

[0037] Grafana is an open-source metrics analysis and visualization suite, often used in conjunction with Prometheus. It allows users to create rich dashboards that showcase data queried from Prometheus. Grafana provides a variety of visualization tools, such as graphs, tables, and alert panels, to help users understand and analyze data intuitively.

[0038] (3) cAdvisor (Container Advisor)

[0039] cAdvisor is an open-source container monitoring tool designed to provide resource usage and performance data about containers running in containerized environments like Docker. It automatically discovers all containers and collects information such as CPU, memory, filesystem, and network usage. cAdvisor's data can be scraped directly by Prometheus, enabling monitoring of container-level metrics.

[0040] Key features:

[0041] 1. Container-level performance metrics: cAdvisor can collect and report information such as CPU usage, memory usage, network traffic, and disk I / O for containers.

[0042] 2. Real-time monitoring: Provides real-time container performance data.

[0043] 3. Support for multiple container technologies: Although primarily designed for Docker, cAdvisor also supports other container technologies like Kubernetes.

[0044] 4. Simple integration and usage: cAdvisor can run as a standalone container and is easy to integrate with existing monitoring tools like Prometheus.

[0045] 5. Web UI: Provides a basic web user interface to display real-time data for containers.

[0046] 6. REST API: Provides a REST API that allows other applications to access container performance data. ( Representational State Transfer, REST API: Provides a REST API that allows other applications to access container performance data.

[0047] The workflow of this monitoring system is typically as follows:

[0048] 1. Data collection

[0049] cAdvisor runs on the host machine (i.e., the device being monitored) and collects various metrics about the host and the containers running on it in real-time.

[0050] 2. Data storage

[0051] For example, Figure 1As shown, Prometheus periodically scrapes these metrics data from cAdvisor and stores them in its own database.

[0052] 3. Data querying and visualization

[0053] As Figure 1 shown, users connect to Prometheus through Grafana and use PromQL to query and analyze these data. Grafana provides rich visualization options, allowing users to view and understand these data in the form of charts and tables, etc.

[0054] 4. Alerts

[0055] Prometheus can also evaluate the collected data according to predefined rules and trigger alerts when potential problems are detected. These alerts can be sent through various means, such as email, SMS, or integrated into other alert management systems.

[0056] The above solution can effectively monitor hardware resources and container running status, providing rich data support for system administrators. However, in scenarios such as network isolation or security restrictions, Prometheus cannot directly pull data from cAdvisor. In this case, Prometheus and cAdvisor need to be deployed in the same network, or the nodes of cAdvisor need to have a public network accessible address. In some environments with strict network security requirements, such as unmanned mixing station scenarios, this direct pulling method is not flexible and secure enough. Based on this, the embodiments of the present disclosure provide a monitoring and alerting method, system and computer readable storage medium, which can alleviate the problem of limited public network access in the construction of hardware and container monitoring systems, to adapt to more complex and restrictive network environments, while also having good flexibility and scalability.

[0057] The embodiments of the present disclosure will be further described below with reference to the accompanying drawings.

[0058] The embodiment mainly aims at a monitored device in a public network access limited state, which can be but is not limited to a mixing station server of an unmanned mixing station. In a specific application scenario, the monitored device can be in a network isolation or security limited environment, and is allowed to access only a specific public network service but not allowed to be accessed by a public network server. The network isolation means that only the public network is allowed to be accessed but not allowed to be accessed by the public network server, that is, only out but not in for the public network. The security limited environment means that the whole network is not open (that is, not allowed to be accessed by any network), and only communication with some specific servers (the access addresses of the servers are fixed) is allowed, which are independent of whether the servers are in the public network or not, and can be specified servers of a third-party service provider with a cooperation relationship.

[0059] Referring to Figure 2 A structural schematic diagram of a monitoring and alarming system is shown, and the monitoring and alarming system comprises: at least one first server 210 and a second server 220; each first server 210 is deployed on a monitored device 100, and the first server 210 is deployed in the same local area network as the monitored device 100 where the first server 210 is located; and the local area network to which the monitored device 100 belongs is in a public network access limited state.

[0060] Specifically, the first server 210 is configured to acquire target monitoring data of the monitored device 100 in the same local area network as the first server 210 based on the local area network.

[0061] The first server 210 is further configured to acquire a public network access address of the second server 220, and push the target monitoring data to the second server 220 through the public network access address of the second server 220.

[0062] The second server 220 is configured to receive the target monitoring data from each first server 210, and perform monitoring and alarming on the monitored device 100 based on the target monitoring data.

[0063] In the embodiment, the monitored device 100 can be in a network isolation or security limited environment, and the monitored device 100 can be but is not limited to a mixing station server of an unmanned mixing station. The first server 210 can run on the monitored device 100, and the first server 210 is mainly used for collecting and transmitting monitoring data of the monitored device 100 to the second server 220. The second server 220 is mainly used for executing monitoring and alarming actions of the monitored device 100, and the second server 220 can be a monitoring server or a cloud end.

[0064] The first service end 210 is in the same local area network as the monitored device 100, and thus can obtain target monitoring data of the monitored device 100 through the local area network. The target monitoring data can be multi-source data required, for example, the target monitoring data can include one or more of hardware indicator data of the monitored device 100, container indicator data running on the monitored device 100, process indicator data of the monitored device 100, and custom indicator data for a preset program running on the monitored device 100, etc. The hardware indicator data can include one or more of CPU usage, memory usage, disk usage, and network I / O, the container indicator data can include one or more of CPU usage, memory usage, and network I / O of the container, the process indicator data can include one or more of process scheduling, interrupt processing, signals, process priority, process switching, process state, and process memory, and the custom indicator data can be set according to actual needs.

[0065] The first service end 210 can store a public network access address of the second service end 220, so as to push the target monitoring data to the second service end 220 through the public network access address of the second service end 220.

[0066] The second service end 220 can receive the target monitoring data pushed by each first service end 210, and perform monitoring and alarm of the corresponding monitored device 100.

[0067] In the embodiments of the present disclosure, the monitoring and alarm system is divided into two parts of the first service end and the second service end, the first service end is deployed on the monitored device in the same local area network, although the local area network to which the first service end belongs is in a public network access limited state, the first service end can push monitoring data to the second service end through the public network access address of the second service end, so as to perform monitoring and alarm through the second service end, and realize monitoring and alarm of the monitored device in a network isolation or security limited environment. Since the first service end adopts a push data mode and is not allowed to be accessed by the public network, the external cannot access the monitored device through the first service end, and the security of the monitored device is improved; and the deployment mode of the monitoring and alarm system is relatively flexible, when the monitored device is changed, only the corresponding first service end needs to be adaptively deployed according to the monitored device, and the scalability is relatively strong. Therefore, the embodiments of the present disclosure can alleviate the problems that the direct pull monitoring data mode is not flexible, has poor scalability, and is not safe when the monitored device is in a public network access limited state.

[0068] In some possible embodiments, as Figure 2As shown, the first server 210 includes a cAdvisor module 211 and a metric adapter 212; the first server 210 can collect the running data of the monitored device 100 where the first server 210 is located in real time through the cAdvisor module 211 to obtain real-time monitoring data, and periodically pull the real-time monitoring data from the cAdvisor module 211 in the same local area network through the metric adapter 212, and perform data standardization processing on the real-time monitoring data to obtain target monitoring data. In this way, standardized target monitoring data can be obtained, which facilitates subsequent processing of the second server 220.

[0069] It should be noted that the data collection of the first server 210 is not limited to being implemented through the cAdvisor module 211, and in other embodiments, it can also be implemented through other types of data collection modules, such as node-exporter and the like.

[0070] In a specific implementation, the cAdvisor module 211 can but is not limited to exposing the collected metrics (metric data, i.e., the real-time monitoring data described above) through an HTTP (Hypertext Transfer Protocol) interface. The cAdvisor module 211 provides an extensive set of metrics, covering various performance parameters of the monitored device 100 and the containers running thereon. The metric adapter 212 can periodically obtain real-time monitoring data from the HTTP interface of the cAdvisor module 211 through the HTTP protocol. The metric adapter 212 can implement periodic pulling of real-time monitoring data through a timing task, for example, the metric adapter 212 performs data pulling every 60 seconds, and each time it pulls the data in the current data collection period, i.e., the data in the last 60 seconds. In this way, the timing task ensures the real-time nature of the data, so that the monitoring and alerting system can timely reflect the latest performance metrics.

[0071] In a possible implementation, in order to implement data collection of multiple data sources, the cAdvisor module 211 is configured with multiple data sources, and the real-time monitoring data includes multiple types of real-time metric data corresponding to the multiple data sources, and the multiple types of real-time metric data include one or more of hardware metric data corresponding to the monitored device 100, container metric data, process metric data, and custom metric data for a preset program. Specifically, the cAdvisor module 211 can collect hardware metric data (such as CPU usage, memory usage, disk usage, and network I / O data) of the monitored device 100 where the cAdvisor module 211 is located, container metric data (such as CPU usage, memory usage, and network I / O of the container) running on the monitored device 100, process metric data, and custom metric data for a preset program, and the like.

[0072] In order to improve the accuracy, processing efficiency and transmission efficiency of the target monitoring data, the above data standardization processing can include data cleaning and data compression. The data cleaning can include data screening and data filtering, etc. The data screening can include screening data in a specified time range, and the specified time range can be a time range corresponding to a current data collection period. The data screening can improve the accuracy of the data. The data filtering can include removing unnecessary data such as timestamps, and the data filtering can improve the processing efficiency of the data. The data compression can reduce the amount of data in the transmission process, thereby reducing the network load and improving the transmission efficiency.

[0073] Further, in the case that the cAdvisor module 211 is configured with multiple data sources, the metric adapter 212 can determine a data cleaning manner corresponding to each type of real-time monitoring data based on the data source identifier corresponding to each type of real-time monitoring data in the real-time monitoring data; wherein the data cleaning manner includes one or more of a data screening manner, a data filtering manner and a format conversion manner; performing data cleaning on each type of real-time monitoring data in the corresponding data cleaning manner to obtain cleaned data; and performing data compression on the cleaned data corresponding to each type of real-time monitoring data to obtain the target monitoring data. In this way, data standardization processing under multiple data sources is realized.

[0074] The data source identifier is used to uniquely identify a data source. When the cAdvisor module 211 performs data collection, the real-time monitoring data collected will be marked with the corresponding data source identifier, so that the metric adapter 212 pulls the real-time monitoring data with the data source identifier. In a specific implementation, the metric adapter 212 can be pre-configured with a correspondence between the data source identifier and the data cleaning manner. By looking up the correspondence, the data cleaning manner corresponding to each type of real-time monitoring data can be determined, and the data cleaning of each type of real-time monitoring data can be realized.

[0075] It should be noted that the correspondence between the data source identifier and the data cleaning manner can be set according to actual needs, which is not limited here; the data compression manner corresponds to the data decompression manner of the second server 220, and can be set according to actual needs, which is not limited here. In addition, the specific processing manner of the real-time monitoring data can be set according to actual needs, and is not limited to data cleaning and data compression, for example, data encryption processing can also be performed; the data cleaning manner is not limited to data screening, data filtering and format conversion, for example, data normalization processing can also be performed.

[0076] In some possible embodiments, as Figure 2As shown, the second server 220 is deployed with a push gateway 221, and the public access address of the second server 220 is the public access address of the push gateway 221. The public access address of the push gateway 221 is stored in the index adapter 212, and the index adapter 212 is configured to transmit the target monitoring data to the push gateway 221 through HTTPS (Hypertext Transfer Protocol Secure, HyperText Transfer Protocol Secure). The push gateway 221 is a transit station for data, and the second server 220 can obtain the target monitoring data pushed by the first server 210 through the push gateway 221. The data transmission between the index adapter 212 and the push gateway 221 through HTTPS can ensure the security of the data in the transmission process and prevent the data from being intercepted or tampered.

[0077] It should be noted that the communication protocol between the index adapter 212 and the push gateway 221 is not limited to HTTPS, and other communication protocols such as HTTP can also be used in other embodiments.

[0078] The push gateway 221 can be one or more, and one push gateway 221 corresponds to one or more index adapters 212. The monitored devices 100 can be grouped according to whether data isolation is required, that is, a plurality of monitored devices 100 that do not need data isolation between each other are taken as a group of monitored devices 100, and the index adapter 212 deployed on each group of monitored devices 100 corresponds to a push gateway 221, that is, the index adapter 212 deployed on each group of monitored devices 100 stores the public access address of the same push gateway 221, so as to realize the data isolation of the monitored devices 100 and further improve the security of the data.

[0079] In order to further improve the independence of the monitoring and alarm of different monitored devices 100, for example, Figure 2 As shown, the push gateway 221 is multiple, and one push gateway 221 corresponds to one index adapter 212. In this way, each push gateway 221 only stores the related data of one monitored device 100, and the corresponding monitored device 100 can be independently monitored and alarmed to ensure that the data of different monitored devices 100 will not be incorrectly obtained.

[0080] In some possible embodiments, for example, Figure 2As shown, the second server 220 further includes a monitoring and alarming module 222, which stores an intranet access address or a public network access address of the push gateway 221. Specifically, the push gateway 221 is configured to receive target monitoring data transmitted by each index adapter 212; the monitoring and alarming module 222 is configured to pull the target monitoring data from the push gateway 221 based on the intranet access address or the public network access address of the push gateway 221; and the monitoring and alarming module 222 is further configured to monitor and alarm the monitored device 100 based on the target monitoring data. Through the data relay of the push gateway 221, the data acquisition of the monitoring and alarming module 222 is realized.

[0081] The push gateway 221 can be adapted to the monitoring and alarming module 222. In a possible implementation, the monitoring and alarming module 222 can be Prometheus, and the push gateway 221 can be Pushgateway, which is an open source component of Prometheus. In this way, the existing open source component Pushgateway is used as the push gateway 221, which can reduce the development difficulty of the monitoring and alarming system.

[0082] The monitoring and alarming module 222 such as Prometheus can evaluate the target monitoring data based on predefined rules and perform alarm processing when a problem is detected. The specific alarm mode can be set according to actual needs, for example, sending a corresponding alarm through an email and / or a short message, or through Alertmanager for alarm notification. The Alertmanager is an alarm management component of Prometheus, which is configured to receive, route and process alarm notifications from Prometheus.

[0083] It should be noted that when different monitoring and alarming modules 222 are used, the push gateways 221 can be the same or different; the monitoring and alarming module 222 is not limited to Prometheus, and the push gateway 221 is not limited to Pushgateway; and the specific monitoring and alarming mode is not limited in the embodiment.

[0084] In a possible implementation, there is one or more Pushgateway, and one Pushgateway corresponds to one or more index adapters. The index adapter stores a public network access address of the corresponding Pushgateway. In this way, the data isolation of the monitored device 100 is realized, and the security of the data is further improved.

[0085] In some possible embodiments, as shown in FIG. 2B, the second server 220 further includes a data storage module 223, which is configured to store the target monitoring data transmitted by the push gateway 221. Figure 2As shown, the second server 220 further includes a visualization module 223 communicatively connected with the monitoring and alarming module 222, the visualization module 223 being configured to pull target monitoring data from the monitoring and alarming module 222, and perform visualization display of the target monitoring data according to the target monitoring data and pre-configured monitoring charts and alarming rules. Through the visualization module 223, visualization display of data can be achieved.

[0086] The visualization module 223 is adapted to the monitoring and alarming module 222, and the embodiment is not limited to the visualization module 223. For example, when the monitoring and alarming module 222 is Prometheus, the visualization module 223 can adopt Grafana; for another example, when the monitoring and alarming module 222 is ELK, the visualization module 223 can adopt Kibana; for another example, when the monitoring and alarming module 222 is Heapster, the visualization module 223 can adopt Grafana or Google Cloud Monitoring UI, etc.

[0087] The specific working process of the monitoring and alarming system will be described in detail below with reference to the accompanying drawings. Figure 3 For example, the monitored device 100 is a mixing station server, the data collection module of the first server 210 adopts a cAdvisor module, the metrics adapter 212 of the first server 210 adopts a developed metrics_collector module, the push gateway 221 of the second server 220 adopts a Pushgateway, the monitoring and alarming module 222 of the second server 220 adopts Prometheus, the visualization module 223 of the second server 220 adopts Grafana, and the plurality of types of real-time index data includes hardware index data and container index data.

[0088] The core technical problem that the embodiment aims to solve is how to effectively monitor the hardware indexes and container indexes of the mixing station server in a network isolated or security limited environment. Specifically, the following key problems need to be solved:

[0089] 1. Data collection obstacles caused by network isolation

[0090] In the existing monitoring system constructed by Prometheus + Grafana + cAdvisor, Prometheus needs to directly pull data from cAdvisor. However, in a network isolated environment, such as an unmanned mixing station scenario, Prometheus cannot directly access cAdvisor running in the isolated network, resulting in ineffective collection of monitoring data.

[0091] 2. Flexibility and scalability of the monitoring and alarming system

[0092] The limitations of the existing solutions in specific environments indicate the need for a more flexible and scalable monitoring solution to adapt to various network requirements, especially in distributed and multi-site application scenarios. Here, a site refers to a mixing station, and one site corresponds to one mixing station server, which runs multiple containers.

[0093] Therefore, the goal of the present embodiment is to develop a new monitoring solution that can effectively collect and transmit hardware and container metrics in a network-isolated or security-limited environment, while ensuring data security, improving the flexibility and scalability of the monitoring alarm system.

[0094] The core innovation of the present embodiment lies in solving the problem of data collection and monitoring in a network-isolated or security-limited environment, especially for hardware and container metrics. As shown in Figure 3 The overall implementation of the monitoring alarm system includes:

[0095] 1. Deploy cAdvisor module on mixing station server

[0096] cAdvisor is responsible for collecting hardware metrics of the mixing station server (such as CPU usage, memory usage, disk usage, and network I / O data) and container metrics running on the mixing station server (such as container CPU usage, memory usage, network I / O, etc.).

[0097] 2. Deploy Prometheus Pushgateway on private cloud

[0098] Pushgateway, as an intermediate layer, is used to receive the collected metrics data from cAdvisor.

[0099] 3. Deploy metrics_collector module on mixing station server

[0100] The metrics_collector module is responsible for processing real-time metrics data collected by cAdvisor (including filtering, screening, and calculations such as normalization), and then sending the processed data (i.e., target monitoring data) to Pushgateway.

[0101] 4. Deploy Prometheus on private cloud

[0102] Prometheus pulls real-time metrics data processed by metrics_collector (i.e., target monitoring data) from Pushgateway.

[0103] 5. Deploy Grafana on a private cloud

[0104] Grafana is used to pull data from Prometheus and configure monitoring charts and alert rules based on these data to achieve visual display of data.

[0105] The key technical points of this embodiment include:

[0106] 1. Development and implementation of metrics_collector module

[0107] One of the core innovations of this embodiment is the development of the metrics_collector module. The key role of this module is to collect metrics data from cAdvisor in a network-isolated environment, such as a mixing station. metrics_collector uses HTTP protocol to obtain real-time metrics data from cAdvisor, and then performs filtering, screening, and calculation on these data to obtain the final target monitoring data. This processing not only optimizes the relevance and accuracy of the data, but also reduces the load in the data transmission process through data compression.

[0108] 2. Innovative use of Pushgateway

[0109] The traditional Prometheus monitoring solution uses a "Pull" model, directly pulling data from cAdvisor. This embodiment breaks this limitation by using Pushgateway as the center of information transfer. metrics_collector collects and processes data and then pushes it to Pushgateway. Subsequently, Pushgateway pulls these data. The innovation of this method lies in its solution to the network isolation problem, while improving the flexibility and reliability of the system, as different sites can deploy different Pushgateway, ensuring that failures in different sites do not affect each other.

[0110] In summary, the core technical points of this embodiment are the development of the metrics_collector module and the innovative application of Pushgateway. These two aspects together solve the problem of data collection and monitoring in a network-isolated environment, while improving the flexibility and reliability of the monitoring and alarm system.

[0111] To facilitate understanding, this embodiment also provides specific implementation methods of the above monitoring and alarm system, as follows:

[0112] 1. Deploy cAdvisor module on the server side of the mixing station

[0113] cAdvisor is responsible for collecting hardware metrics data (such as CPU usage, memory usage, disk usage, and network I / O data) of the blender server and container metrics data (such as CPU usage, memory usage, network I / O, etc.) running on the server, and exposing the collected metrics (i.e. metrics data) through an HTTP interface.

[0114] 2. Deploying Pushgateway on the private cloud

[0115] Pushgateway serves as an intermediate layer to receive the metrics data collected from cAdvisor. After being deployed on the private cloud, it can provide both internal and external network access addresses, so that the internal Prometheus and the metrics_collector module in the blender station can access it simultaneously. The traditional Prometheus monitoring solution uses a "Pull" model, which directly pulls data from cAdvisor. This embodiment breaks this limitation by using Pushgateway as an information transfer center. After collecting and processing the data, metrics_collector pushes the data to Pushgateway. Then, Prometheus pulls the data from Pushgateway. The innovation of this method lies in that it solves the problem of network isolation and improves the flexibility and reliability of the system, because different sites can deploy different Pushgateway, thus ensuring that failures in different sites do not affect each other.

[0116] 3. Deploying the metrics_collector module on the blender server side

[0117] The detailed implementation of metrics_collector is as follows:

[0118] 1) Data acquisition

[0119] metrics_collector acquires real-time metrics data from the HTTP interface of cAdvisor through the HTTP protocol. cAdvisor provides a detailed set of metrics covering various performance parameters of the server and containers.

[0120] 2) Data processing

[0121] The acquired real-time metrics data is filtered by data selection within a specified time range, and then filtered by removing timestamps. Specifically, the metrics data after data selection contains multiple different metrics, each with a timestamp. The metrics_collector performs string matching on these metrics data, identifies and removes the timestamp in each metric. In addition, the metrics data after data filtering can also be normalized and calculated. The purpose of the data processing step is to simplify the data and only keep the core performance metrics, thereby improving the processing efficiency and transmission efficiency of the data.

[0122] 3) Data compression

[0123] After removing the timestamp, the metrics_collector compresses all the metrics data. Data compression is to reduce the amount of data in the transmission process, thereby reducing network load and improving transmission efficiency. This step is particularly important in a network environment with limited bandwidth.

[0124] 4) Data transmission

[0125] The compressed data is transmitted securely to the Pushgateway through the HTTPS protocol. The HTTPS protocol is used to ensure the security of the data during transmission, preventing data from being intercepted or tampered with.

[0126] 5) Timing task setting

[0127] The metrics_collector sets a periodic timing task that executes the above data collection, processing and transmission process every 60 seconds. This timing task ensures the real-time nature of the data, allowing the monitoring and alerting system to reflect the latest performance metrics in a timely manner.

[0128] Through the above processing process, the metrics_collector not only optimizes the accuracy of the data, but also effectively reduces the load in the data transmission process through data compression and the setting of the timing task, improving the efficiency and reliability of the entire monitoring and alerting system.

[0129] 4. Deploy Prometheus on a private cloud

[0130] Prometheus pulls data from the Pushgateway that has been processed by the metrics_collector and pushed to the Pushgateway through the internal network address or public network address.

[0131] 5. Deploy Grafana on a private cloud

[0132] Grafana is used to pull data from Prometheus and visualize the data based on the configured monitoring charts and alert rules.

[0133] The technical solution of the embodiment brings multiple benefits through its unique design and implementation steps:

[0134] 1. Solving data collection problems in network isolation environment

[0135] By deploying the metrics_collector module on the server of the mixing station and using Pushgateway as a transit, the data collection problem in the network isolation environment is effectively solved. This method ensures the smooth collection and transmission of monitoring data even if the server of the mixing station cannot directly communicate with the private cloud.

[0136] 2. Improve data processing efficiency and accuracy

[0137] The metrics_collector module filters, filters and calculates the raw data collected from cAdvisor, which not only reduces the amount of data transmitted to Pushgateway, but also ensures that the transmitted data is more accurate and useful. Such processing reduces network burden and improves data processing efficiency and accuracy.

[0138] 3. Enhance the flexibility and scalability of the monitoring and alarm system

[0139] The solution of the embodiment allows different mixing stations to deploy different metrics_collector and Pushgateway, which means that the monitoring and alarm systems of each site can run independently and do not affect each other. This design greatly enhances the flexibility and scalability of the entire monitoring system, especially suitable for multi-site, distributed operation environment.

[0140] 4. Improve the security of monitoring data

[0141] Since the monitoring data has been preliminarily processed and filtered before transmission, the risk of transmitting sensitive or redundant data is reduced, thereby enhancing the security of the data.

[0142] 5. Optimize resource utilization and cost efficiency

[0143] By optimizing the data collection and transmission process, the embodiment reduces the demand for network bandwidth and storage resources, which not only improves resource utilization efficiency, but also reduces operation and maintenance costs.

[0144] 6. Improve user experience and operational convenience

[0145] In combination with the visualization tool of Grafana, the embodiment provides intuitive and easy-to-understand monitoring data display, so that the user can more conveniently analyze and interpret the monitoring data, thereby improving the operation convenience and user experience.

[0146] The embodiment of the present disclosure further provides a monitoring alarm method, which is applied to the monitoring alarm system described above, and the monitoring alarm system comprises at least one first server and a second server, each first server is deployed on a monitored device, the first server is in the same local area network as the monitored device, and the local area network to which the monitored device belongs is in a limited public network access state.

[0147] Referring to Figure 4 As shown in a flowchart of a monitoring alarm method, the method mainly comprises the following steps S410 to S430:

[0148] In step S410, each first server acquires target monitoring data of the monitored device in the same local area network as the first server based on the local area network.

[0149] In some possible embodiments, the first server comprises a cAdvisor module and an index adapter; and step S410 can be implemented in the following manner: each cAdvisor module collects the running data of the monitored device in which the cAdvisor module is located in real time to obtain real-time monitoring data; and each index adapter periodically pulls the real-time monitoring data from the cAdvisor module in the same local area network and performs data standardization processing on the real-time monitoring data to obtain the target monitoring data. In this way, the standardized target monitoring data can be obtained, which facilitates the processing of the second server.

[0150] Optionally, the cAdvisor module is configured with multiple data sources, the real-time monitoring data comprises multiple types of real-time index data corresponding to the multiple data sources one by one, and the multiple types of real-time index data comprise one or more of hardware index data, container index data, process index data and custom index data for a preset program corresponding to the monitored device. By configuring multiple data sources in the cAdvisor module, the data collection of the multiple data sources is realized.

[0151] In a possible implementation, the data standardization processing includes data cleaning and data compression; the data standardization processing on the real-time monitoring data to obtain the target monitoring data includes: determining a data cleaning manner corresponding to each type of real-time index data based on a data source identifier corresponding to each type of real-time index data in the real-time monitoring data; wherein the data cleaning manner includes one or more of a data screening manner, a data filtering manner, and a format conversion manner; performing data cleaning on each type of real-time index data in the corresponding data cleaning manner to obtain cleaned data; and performing data compression on the cleaned data corresponding to each type of real-time index data to obtain the target monitoring data. In this way, data standardization processing under multiple data sources is implemented, and the accuracy, processing efficiency, and transmission efficiency of the target monitoring data are improved.

[0152] In step S420, the public network access address of the second server is obtained by each first server, and the target monitoring data is pushed to the second server through the public network access address of the second server.

[0153] Optionally, the second server is deployed with a push gateway, and the public network access address of the second server is a public network access address of the push gateway; the public network access address of the push gateway is stored in the index adapter, and the index adapter is configured to transmit the target monitoring data to the push gateway through HTTPS. Using HTTPS for data transmission between the index adapter and the push gateway can ensure the security of the data during transmission and prevent the data from being intercepted or tampered with.

[0154] Further optionally, the push gateway includes one or more Pushgateways, and one Pushgateway corresponds to one or more index adapters, and the public network access address of the corresponding Pushgateway is stored in the index adapter. In this way, data isolation of the monitored device is implemented, and the security of the data is further improved.

[0155] In step S430, the target monitoring data from each first server is received by the second server, and the monitored device is monitored and alarmed based on the target monitoring data.

[0156] In some possible embodiments, the second server includes a monitoring and alarming module, and the monitoring and alarming module stores an intranet access address or a public network access address of the push gateway; based on this, step S430 can be implemented through the following process: the target monitoring data transmitted by each index adapter is received through the push gateway; the target monitoring data is pulled from the push gateway through the intranet access address or the public network access address of the push gateway by the monitoring and alarming module; and the monitored device is monitored and alarmed based on the target monitoring data by the monitoring and alarming module. Through the data relay of the push gateway, data acquisition of the monitoring and alarming module is implemented.

[0157] Further optionally, the second server further comprises a visualization module in communication connection with the monitoring and alarming module, and the monitoring and alarming method further comprises: pulling the target monitoring data from the monitoring and alarming module by the visualization module, and performing visualized display of the target monitoring data according to the target monitoring data and the pre-configured monitoring chart and alarm rule. The visualization module is used to realize the visualized display of the data.

[0158] The monitoring and alarming method provided by the embodiments of the present disclosure is applied to a monitoring and alarming system, the monitoring and alarming system comprises at least one first server and a second server, each first server is deployed on a monitored device, the first server and the monitored device where the first server is located are in the same local area network, and the local area network to which the monitored device belongs is in a limited public network access state; when monitoring and alarming is performed, the target monitoring data of the monitored device in the same local area network as the first server can be acquired by each first server based on the local area network; the public network access address of the second server is acquired by each first server, and the target monitoring data is pushed to the second server through the public network access address of the second server; the target monitoring data from each first server is received by the second server, and the monitored device is monitored and alarmed based on the target monitoring data. In this way, the monitoring and alarming system is divided into two parts of the first server and the second server, the first server is deployed on the monitored device in the same local area network, although the local area network to which the first server belongs is in a limited public network access state, the first server can push the monitoring data to the second server through the public network access address of the second server, so that the monitoring and alarming is performed through the second server, and the monitoring and alarming of the monitored device in a network isolation or a safe limited environment is realized. Since the first server adopts a push data mode and is not allowed to be accessed by the public network, the monitored device cannot be accessed by the outside through the first server, and the security of the monitored device is improved; and the deployment mode of the monitoring and alarming system is relatively flexible, when the monitored device is changed, only the corresponding first server needs to be adaptively deployed according to the monitored device, and the scalability is relatively strong. Therefore, the embodiments of the present disclosure can alleviate the problems that the direct pull monitoring data mode is not flexible, has poor scalability and is not safe when the monitored device is in a limited public network access state.

[0159] The monitoring and alarming method provided by the embodiments of the present disclosure has the same technical features as the monitoring and alarming system provided by the above-mentioned embodiments, so it can also solve the same technical problems and achieve the same technical effects.

[0160] The embodiment of the present disclosure further provides a computer readable storage medium applied to a monitoring and alarming system, the monitoring and alarming system comprising at least one first server and a second server, each first server being deployed on a monitored device, the first server and the monitored device being in the same local area network, and the local area network to which the monitored device belongs being in a limited public network access state; the computer readable storage medium stores a computer program, and when the computer program is run by a processor, the processor executes the following steps:

[0161] acquiring, by each first server, target monitoring data of the monitored device in the same local area network as the first server based on the local area network;

[0162] acquiring, by each first server, a public network access address of the second server, and pushing the target monitoring data to the second server through the public network access address of the second server;

[0163] receiving, by the second server, the target monitoring data from each first server, and monitoring and alarming the monitored device based on the target monitoring data.

[0164] In a feasible implementation, the first server comprises a cAdvisor module and an index adapter; when the processor executes the step of acquiring, by each first server, target monitoring data of the monitored device in the same local area network as the first server based on the local area network, the processor is specifically configured to: acquire, by each cAdvisor module, real-time monitoring data of the monitored device in which the cAdvisor module is located; and periodically pull, by each index adapter, the real-time monitoring data from the cAdvisor module in the same local area network, and perform data standardization processing on the real-time monitoring data to obtain the target monitoring data.

[0165] In a feasible implementation, the cAdvisor module is configured with multiple data sources, the real-time monitoring data comprises multiple types of real-time index data corresponding to the multiple data sources, and the multiple types of real-time index data comprise one or more of hardware index data, container index data, process index data and custom index data for a preset program corresponding to the monitored device.

[0166] In an implementable embodiment, the data standardization processing includes data cleaning and data compression; when performing the data standardization processing on the real-time monitoring data to obtain the target monitoring data, the processor is specifically configured to: determine a data cleaning manner corresponding to each type of real-time index data based on a data source identifier corresponding to each type of real-time index data in the real-time monitoring data; wherein the data cleaning manner includes one or more of a data screening manner, a data filtering manner, and a format conversion manner; perform data cleaning on each type of real-time index data in the corresponding data cleaning manner to obtain cleaned data; and perform data compression on the cleaned data corresponding to each type of real-time index data to obtain the target monitoring data.

[0167] In an implementable embodiment, the second server is deployed with a push gateway, and a public network access address of the second server is a public network access address of the push gateway; the index adapter stores the public network access address of the push gateway, and the index adapter is configured to transmit the target monitoring data to the push gateway through HTTPS.

[0168] In an implementable embodiment, the push gateway includes one or more Pushgateways, and one Pushgateway corresponds to one or more index adapters, and the index adapter stores a public network access address of the corresponding Pushgateway.

[0169] In an implementable embodiment, the second server includes a monitoring and alarming module, and the monitoring and alarming module stores an intranet access address or a public network access address of the push gateway; when performing receiving the target monitoring data from each first server through the second server and monitoring and alarming the monitored device based on the target monitoring data, the processor is specifically configured to: receive the target monitoring data transmitted by each index adapter through the push gateway; pull the target monitoring data from the push gateway through the monitoring and alarming module based on the intranet access address or the public network access address of the push gateway; and monitor and alarm the monitored device based on the target monitoring data through the monitoring and alarming module.

[0170] In an implementable embodiment, the second server further includes a visualization module in communication connection with the monitoring and alarming module, and the processor is further configured to: pull the target monitoring data from the monitoring and alarming module through the visualization module, and perform visualized display of the target monitoring data according to the target monitoring data and preconfigured monitoring charts and alarm rules.

[0171] Through the above manner, the monitoring alarm of the monitored device in a network isolation or a security limited environment is realized. Since the first server adopts a push data manner and is not allowed to be accessed by the public network, the monitored device cannot be accessed by the external through the first server, and the security of the monitored device is improved. In addition, the deployment manner of the monitoring alarm system is relatively flexible. When the monitored device is changed, only the corresponding first server needs to be adaptively deployed for the monitored device, and the scalability is relatively strong. Therefore, the problems that the direct pull monitoring data manner is not flexible, has poor scalability and is not safe when the monitored device is in a public network access limited state can be alleviated.

[0172] In the embodiments of the present disclosure, the computer program, when executed by the processor, can also execute other machine readable instructions to perform the methods described in other embodiments. For specific method steps and principles, refer to the description of the embodiments, which will not be described in detail here.

[0173] The flowcharts and block diagrams in the drawings show the possible implementation architecture, function and operation of the system, method and computer program product according to the embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of code containing one or more executable instructions for implementing a specified logic function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different orders from those noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0174] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e. they can be located in one place or distributed on multiple network units. Some or all of the units can be selected to achieve the purpose of the present embodiment according to actual needs.

[0175] In addition, the functional units in the embodiments provided by the present disclosure can be integrated in one processing unit, or each unit can exist alone physically, or two or more units can be integrated in one unit.

[0176] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present disclosure can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the monitoring and alarming method described in the various embodiments of the present disclosure. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0177] It should be noted that similar reference numbers and letters represent similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0178] Finally, it should be noted that the above-described embodiments are only specific implementations of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, and are not limiting. The protection scope of the present disclosure is not limited thereto. Although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art who is familiar with the technical field of the present disclosure can make modifications or easily think of changes to the technical solutions described in the foregoing embodiments, or make equivalent replacements to some of the technical features; and these modifications, changes or replacements do not cause the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present disclosure. All should be covered within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method of monitoring an alarm, characterized by, The application is applied to a monitoring and alarming system, the monitoring and alarming system comprises at least one first server and a second server, each first server is deployed on a monitored device, the first server is in the same local area network with the monitored device, and the local area network of the monitored device is in a limited public network access state; The monitoring and alarming method comprises: Each first server obtains target monitoring data of the monitored device in the same local area network as the first server based on the local area network; Each first server obtains a public network access address of the second server and pushes the target monitoring data to the second server through the public network access address of the second server; The second server receives the target monitoring data from each first server and monitors and alarms the monitored device based on the target monitoring data.

2. The monitoring alarm method of claim 1, wherein, The first server comprises a cAdvisor module and an index adapter; Each first server obtains target monitoring data of the monitored device in the same local area network as the first server based on the local area network, comprising: Each cAdvisor module collects the running data of the monitored device in real time to obtain real-time monitoring data; Each index adapter periodically pulls the real-time monitoring data from the cAdvisor module in the same local area network and processes the real-time monitoring data to obtain the target monitoring data.

3. The method of claim 2, wherein, The cAdvisor module is configured with multiple data sources, the real-time monitoring data comprises multiple types of real-time index data corresponding to the multiple data sources, and the multiple types of real-time index data comprise one or more of hardware index data, container index data, process index data and custom index data for a preset program corresponding to the monitored device.

4. The method of claim 3, wherein, The data standardization processing comprises data cleaning and data compression; the target monitoring data obtained by processing the real-time monitoring data comprises: Based on the data source identifier corresponding to each type of real-time index data in the real-time monitoring data, determine the data cleaning mode corresponding to each type of real-time index data; wherein the data cleaning mode comprises one or more of data screening mode, data filtering mode and format conversion mode; Each type of real-time index data is cleaned in the corresponding data cleaning mode to obtain cleaned data; Each type of real-time index data is cleaned in the corresponding data cleaning mode to obtain cleaned data; 5. The method of claim 2, wherein, The second server is deployed with a push gateway, the public network access address of the second server is the public network access address of the push gateway; the index adapter stores the public network access address of the push gateway, and the index adapter is used to transmit the target monitoring data to the push gateway through HTTPS.

6. The method of claim 5, wherein, The push gateway comprises a Pushgateway, and one of the Pushgateways corresponds to one or more of the metric adapters, and the metric adapters store public network access addresses of the corresponding Pushgateways.

7. The method of claim 5, wherein the monitoring alarm is a visual alarm. The second server comprises a monitoring and alarming module, and the monitoring and alarming module stores the intranet access address or the public network access address of the push gateway. The second server receives the target monitoring data from each of the first servers and performs monitoring and alarming on the monitored devices based on the target monitoring data. The push gateway receives the target monitoring data transmitted by each of the metric adapters. The monitoring and alarming module pulls the target monitoring data from the push gateway based on the intranet access address or the public network access address of the push gateway. The monitoring and alarming module performs monitoring and alarming on the monitored devices based on the target monitoring data.

8. The method of claim 7, wherein, The second server further comprises a visualization module in communication connection with the monitoring and alarming module, and the monitoring and alarming method further comprises: The visualization module pulls the target monitoring data from the monitoring and alarming module, and performs visualized display of the target monitoring data according to the target monitoring data and preconfigured monitoring charts and alarming rules.

9. A monitoring alarm system, characterized in that The second server comprises a push gateway, and the public network access address of the second server is the public network access address of the push gateway; the metric adapter stores the public network access address of the push gateway, and the metric adapter is configured to transmit the target monitoring data to the push gateway through HTTPS. The first server comprises a cAdvisor module and a metric adapter. The cAdvisor module is configured to collect running data of the monitored device in real time to obtain real-time monitoring data. The metric adapter is configured to periodically pull the real-time monitoring data from the cAdvisor module in the same local area network and perform data standardization processing on the real-time monitoring data to obtain the target monitoring data. The second server comprises a push gateway, and the public network access address of the second server is the public network access address of the push gateway; the metric adapter stores the public network access address of the push gateway, and the metric adapter is configured to transmit the target monitoring data to the push gateway through HTTPS. ​ 10. The supervisory alarm system of claim 9, wherein, ​ ​ ​ 11. The supervisory alarm system of claim 10, wherein, ​ 12. The supervisory alarm system of claim 11, wherein, The push gateway comprises a Pushgateway, and one or more of the Pushgateways correspond to one or more of the index adapters, and the index adapters store public network access addresses of the corresponding Pushgateways.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer executable instructions, and when the computer executable instructions are called and run by the processor, the computer executable instructions cause the processor to run the monitoring and alarming method in any one of claims 1-8.

Images