Method and system for supporting security monitoring and cloud synchronization of edge service equipment

Abstract

The invention discloses a method and a system for supporting security monitoring and cloud synchronization of edge service equipment, and relates to the technical field of cloud computing. The method comprises the following steps: deploying a local monitoring module at an edge node to carry out index acquisition and temporary storage; a data transfer module is deployed to pull data from a federated interface of the local monitoring module; the data transfer module actively pushes the data to a cloud time sequence database through secure connection after preprocessing such as adding an identity tag to the data; and the cloud provides unified visualization and alarm based on the stored data. According to the method, cloud pulling is converted into edge pushing, the monitoring data collection problem caused by the fact that the cloud cannot directly access the edge nodes is solved, and reliable convergence and unified operation and maintenance management of the edge monitoring data are achieved on the premise that network safety is guaranteed.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and edge computing technology, and specifically to a method and system for synchronizing security monitoring data of edge service devices to the cloud in an edge computing environment. Background Technology

[0002] With the widespread application of edge computing technology, a large number of edge nodes are deployed in terminal scenarios close to data sources or users, such as factory workshops, smart parks, and remote sites. These edge nodes typically run critical business services and require continuous performance monitoring and status collection to ensure the stability, reliability, and maintainability of these services.

[0003] Currently, in centralized cloud data center environments, mainstream monitoring solutions (such as Prometheus) generally adopt a "pull" model for metric collection. Under this model, the monitoring server deployed in the cloud center proactively initiates HTTP requests to the metric interfaces (such as / metrics) exposed by the monitored services, periodically fetching monitoring data. This model works well in environments where network reachability is guaranteed and all services can be directly accessed by the central server.

[0004] However, in edge computing scenarios, the above-mentioned pull model faces fundamental challenges:

[0005] 1. Network access restrictions: Edge nodes are typically located within the enterprise intranet, behind firewalls, or in areas with limited network conditions. Direct and stable reverse access to the monitoring endpoints within these edge nodes is not possible from the public cloud or central monitoring platform.

[0006] 2. Security policy constraints: For security reasons, the service interfaces of edge nodes are generally not allowed to be exposed to the outside world, especially to active connections from the Internet, in order to avoid expanding the attack surface.

[0007] 3. Poor architectural adaptability: Even if the network is temporarily connected through complex network tunnels, reverse proxies and other means, it will introduce high operation and maintenance costs, complex configuration management and additional points of failure, making it difficult to adapt to large-scale, distributed edge computing scenarios.

[0008] Therefore, existing technologies lack a technical solution that can efficiently and reliably aggregate massive amounts of monitoring data from edge nodes to the cloud for unified management and analysis while ensuring network security. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a method and system for supporting security monitoring and cloud synchronization of edge service devices. This method constructs a complete local monitoring and data relay system at the edge and utilizes an "active push" mode to securely, reliably, and in near real-time synchronize edge monitoring data to the cloud, even under constraints where direct access to edge nodes from the cloud is not possible.

[0010] To achieve the above objectives, this application provides a method for supporting security monitoring and cloud synchronization of edge service devices, applied to a system containing at least one edge node and a cloud platform, the method comprising:

[0011] By utilizing the local monitoring module deployed within each edge node, metrics are collected and stored for the first time for the business services running on that node;

[0012] Using a data relay module deployed within each edge node, monitoring indicator data is periodically pulled from the aggregation interface provided by the local monitoring module;

[0013] The data transfer module is used to preprocess the retrieved monitoring indicator data. The preprocessing includes at least adding edge node identity tags to the monitoring indicator data to identify its source.

[0014] Using the data relay module, the preprocessed monitoring indicator data is actively pushed to the cloud time-series database in the cloud platform for secondary storage via a secure network connection;

[0015] The cloud platform utilizes the monitoring metrics data stored in the cloud-based time-series database to perform unified visualization and alarm analysis.

[0016] Optionally, the local monitoring module includes a first acquisition module and a first storage module;

[0017] The first acquisition module is used to capture the indicator interface data exposed by each business service on the edge node;

[0018] The first storage module is used to temporarily store the indicator interface data and to provide a federated interface for batch acquisition of the indicator interface data.

[0019] Furthermore, the data transfer module is configured with an input plugin, which is configured to periodically access the federation interface to obtain the aggregated monitoring metric data stream;

[0020] The address of the federated interface is the service address of the first storage module, and it contains query parameters for filtering target monitoring indicator data.

[0021] Optionally, the preprocessing further includes at least one of the following operations:

[0022] Filter the monitoring indicator data to remove preset non-critical indicators;

[0023] The monitoring indicator data is relabeled to unify or supplement the indicator labeling system;

[0024] Aggregate or downsample monitoring indicator data to reduce data transmission volume.

[0025] Optionally, the data relay module is configured with an output plug-in, a local buffer module, and a retry mechanism;

[0026] The output plugin is configured to convert the preprocessed monitoring metric data into a protocol format supported by the cloud time series database and send it.

[0027] The local buffer module is used to temporarily cache monitoring indicator data to be sent when there is a network anomaly or the cloud service is unavailable.

[0028] The retry mechanism is used to automatically retry according to a preset backoff strategy when the push fails, until the push is successful or the maximum number of retries is reached.

[0029] Furthermore, the secure network connection is an HTTPS connection based on token authentication, basic authentication, or two-way TLS authentication.

[0030] Optionally, the cloud-based time-series database is VictoriaMetrics or a time-series database compatible with the Prometheus remote write protocol;

[0031] The cloud platform deploys Grafana and configures the cloud-based time-series database as a data source to achieve the visualization and alarm analysis functions.

[0032] This application also provides a system that supports security monitoring and cloud synchronization of edge service devices, including an edge-side subsystem deployed on edge nodes and a cloud-side subsystem deployed on a cloud platform;

[0033] The edge-side subsystem includes:

[0034] The local monitoring module is used to collect and temporarily store metrics of the business services running on the edge nodes, and expose a federated query interface.

[0035] The data relay module is used to pull monitoring indicator data from the federated query interface and preprocess the pulled monitoring indicator data. The preprocessing includes at least adding edge node identity tags, and then sending the processed monitoring indicator data to the cloud through an active push method.

[0036] The cloud subsystem includes:

[0037] The data receiving and storage module is used to receive and persistently store monitoring indicator data from each edge node;

[0038] The data display and analysis module is used to visualize and analyze the monitoring indicator data stored in the data receiving and storage module.

[0039] Compared with the prior art, the technical solution provided in this application has the following beneficial effects:

[0040] 1. Solving the network reachability problem: By pushing the "pull" action of data collection down to the edge node and having the edge node actively "push" data to the cloud, it perfectly adapts to the typical network topology where "edge nodes can access the cloud unidirectionally, but the cloud cannot access the edge node inboundly," thus achieving cross-network isolated synchronization of monitoring data.

[0041] 2. Enhanced security: Edge nodes do not need to expose any monitoring ports. All data exits are completed through secure connections initiated by the edge nodes (such as HTTPS with Auth), which greatly reduces the attack surface and conforms to the best security practices for edge environments.

[0042] 3. Enhanced reliability and robustness: By introducing mechanisms such as local buffering, batch sending, and failure retry in the data relay module, the system effectively addresses the instability and intermittent interruptions of the edge network, ensuring the eventual consistency of monitoring data under extreme network conditions and preventing data loss.

[0043] 4. Achieve a unified operation and maintenance view: Monitoring data from all edge nodes is aggregated in the cloud. With the help of high-performance time-series databases and visualization tools, operation and maintenance personnel can achieve global monitoring, historical backtracking, correlation analysis and unified alarms for distributed edge services in a single console, which greatly improves operation and maintenance efficiency.

[0044] 5. Excellent scalability and flexibility: The solution adopts a modular and plug-in design. The local monitoring and data transfer modules on the edge side can be flexibly configured and tailored according to actual resource conditions and monitoring granularity requirements; the cloud storage and display components can also be elastically expanded according to the data scale. Attached Figure Description

[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Furthermore, these drawings and textual descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to specific embodiments.

[0046] Figure 1 This is a schematic diagram of the overall system architecture provided in an embodiment of the present invention;

[0047] Figure 2 This is a flowchart of a method provided in an embodiment of the present invention. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0049] This application provides a system that supports security monitoring of edge service devices and cloud synchronization. Figure 1 This is a schematic diagram of the overall system architecture provided in an embodiment of the present invention.

[0050] like Figure 1 As shown, the system consists of two main parts: an edge subsystem deployed on edge nodes and a cloud subsystem deployed on a cloud platform.

[0051] The edge-side subsystem includes:

[0052] The local monitoring module is used to collect and temporarily store metrics of the business services running on the edge nodes, and expose a federated query interface.

[0053] The data relay module is used to pull monitoring indicator data from the federated query interface and preprocess the pulled monitoring indicator data. The preprocessing includes at least adding edge node identity tags, and then sending the processed monitoring indicator data to the cloud through an active push method.

[0054] The cloud subsystem includes:

[0055] The data receiving and storage module is used to receive and persistently store monitoring indicator data from each edge node;

[0056] The data display and analysis module is used to visualize and analyze the monitoring indicator data stored in the data receiving and storage module.

[0057] Based on this solution, by building a complete local monitoring and data relay system at the edge and using the "proactive push" mode, edge monitoring data can be securely, reliably, and in near real-time synchronized to the cloud under the constraint that edge nodes cannot be directly accessed from the cloud.

[0058] More specifically, the local monitoring module includes a first acquisition module and a first storage module; the first acquisition module is used to capture the indicator interface data exposed by each business service on the edge node; the first storage module is used to temporarily store the indicator interface data and provide a federated interface for batch acquisition of the indicator interface data.

[0059] Furthermore, the data transfer module is configured with an input plugin, which is configured to periodically access the federation interface to obtain the aggregated monitoring indicator data stream; the address of the federation interface is the service address of the first storage module, and includes query parameters for filtering target monitoring indicator data.

[0060] In addition, in some embodiments, the data relay module is configured with an output plugin, a local buffer module, and a retry mechanism; the output plugin is configured to convert the preprocessed monitoring indicator data into a protocol format supported by the cloud time series database and send it; the local buffer module is used to temporarily cache the monitoring indicator data to be sent when the network is abnormal or the cloud service is unavailable; the retry mechanism is used to automatically retry according to a preset backoff strategy when the push fails, until the push is successful or the maximum number of retries is reached.

[0061] In one specific embodiment, the specific deployment on the edge side and the cloud side is as follows:

[0062] 1. Edge-side deployment:

[0063] On each edge node (e.g., an edge cluster running Kubernetes or a physical server), deploy the following core components:

[0064] Kube-Prometheus-Stack (as a local monitoring module): This is an integrated monitoring stack that includes at least:

[0065] Prometheus serves as the core time-series database and data collector. It automatically discovers all Pods / Services within the cluster that require monitoring through service discovery mechanisms (such as Kubernetes Service Discovery), and periodically (e.g., every 15 seconds) accesses their ` / metrics` endpoint to capture raw monitoring metrics (such as CPU utilization, memory usage, HTTP request latency, etc.). The captured data is stored in Prometheus's local time-series database.

[0066] Node Exporter (optional): Used to collect host-level metrics (such as CPU, memory, disk, network).

[0067] Related ServiceMonitor CRDs: Used to define how to discover and capture metrics for custom applications.

[0068] This stack creates a Kubernetes Service that allows Prometheus's APIs (including query and federation interfaces) to be accessed within the cluster, for example: http: / / kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090.

[0069] Telegraf (as a data transfer module): Deployed in an edge cluster as a DaemonSet or a standalone Pod. Telegraf is a highly configurable data acquisition agent whose core responsibility is to retrieve data from the local Prometheus instance, process it, and push it to the cloud. Its configuration file defines the "Input," "Processor," "Aggregator," and "Output" plugins.

[0070] 2. Cloud-based deployment:

[0071] Deploy the following components in a cloud platform (such as a public cloud VPC or an enterprise private cloud):

[0072] VictoriaMetrics cluster (as a data receiving and storage module): This is a high-performance, scalable time-series database compatible with Prometheus Query Language (PromQL) and various data writing protocols (such as InfluxDB LineProtocol, Prometheus Remote Write). It provides a highly available HTTP write interface (e.g., https: / / <vm-host>The `:8428 / write` function is used to receive data and provide a query interface. Alternatively, other time-series databases compatible with the Prometheus remote write protocol can also be used.

[0073] Grafana (as a data visualization and analysis module): Deployed in the cloud, configured with a cloud-based time-series database (such as VictoriaMetrics) as its data source. Operations personnel use Grafana to create dashboards, visualize monitoring metrics for all edge nodes, and configure alerting rules.

[0074] Based on the above system, its working process is as follows: First, using the local monitoring module deployed inside each edge node, the business services running on that node are sampled and stored as metrics. Then, using the data relay module deployed inside each edge node, monitoring metric data is periodically pulled from the aggregation interface provided by the local monitoring module. Next, the data relay module preprocesses the pulled monitoring metric data, including at least adding an edge node identity tag to identify its source. Then, using the data relay module, the preprocessed monitoring metric data is actively pushed to the cloud-based time-series database in the cloud platform for second storage via a secure network connection (e.g., an HTTPS connection based on token authentication, basic authentication, or two-way TLS authentication). Finally, the cloud platform uses the monitoring metric data stored in the cloud-based time-series database for unified visualization and alarm analysis.

[0075] To better understand, the method of this application is illustrated with examples.

[0076] See Figure 2 The complete process of monitoring data from generation to cloud display includes:

[0077] Step S201: Edge local indicator collection.

[0078] Specifically, business applications (such as microservices) on edge nodes expose metric endpoints ( / metrics) conforming to the Prometheus format through client libraries (such as Prometheus Goclient). The local Prometheus instance periodically accesses these endpoints based on pre-configured crawling tasks, storing the metrics in its TSDB. For example, an HTTP request count metric for an order service might be collected and stored in the form of http_requests_total{method="POST",handler=" / api / order"}.

[0079] Step S202: Expose the federation interface.

[0080] Specifically, Prometheus includes a built-in ` / federate` API endpoint (federated interface) for exporting all or part of time-series data matching specific rules at once. In this embodiment, this interface is configured to allow access from data relay modules such as Telegraf. A typical federated query URL example is as follows:

[0081] http: / / kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090 / federate? match[]={__name__=~".+"}

[0082] After decoding this URL, the query parameter is `match[] = {__name__ = ~".+"}`, which means matching all metric names. In actual production, to optimize performance, more precise matching rules are usually used to filter key metrics, such as `match[] = {__name__ = ~"http_.+|node_cpu_.+"}`.

[0083] Step S203: Telegraf fetching and preprocessing.

[0084] The preprocessing includes at least adding edge node identity tags to the monitoring indicator data to identify its source. It may also include at least one of the following operations: filtering the monitoring indicator data to remove preset non-critical indicators; re-labeling the monitoring indicator data to unify or supplement the indicator labeling system; and aggregating or downsampling the monitoring indicator data to reduce data transmission volume.

[0085] Specifically, taking Telegraf as an example for the data transfer module; the Telegraf input plugin is configured as prometheus or prometheus_scrape. Below is a simplified configuration snippet defining how to pull data from the federated interface:

[0086]

[0087] The code indicates that Telegraf will access this URL every 30 seconds to obtain a batch of metrics in Prometheus format.

[0088] Before sending the data, Telegraf performs crucial preprocessing:

[0089] 1. Add identification tags: This is key to distinguishing data across multiple nodes. Use Telegraf's tags configuration or global_tags to add fixed tags to each metric collected from that edge node, for example:

[0090]

[0091] In this way, the metrics stored in the cloud will carry these tags, making it easier to filter and aggregate by cluster and node.

[0092] 2. Metric filtering and relabeling: You can use configuration options such as tagexclude, taginclude, fieldpass, and fielddrop, or more powerful processor plugins (such as Starlark), to discard unnecessary high-frequency detailed metrics, or to clean and standardize metric names and tags.

[0093] Step S204: Data push and reliability assurance.

[0094] Telegraf's output plugin is configured to use either InfluxDB (due to its protocol compatibility with VictoriaMetrics) or VictoriaMetrics. An example configuration is shown below:

[0095]

[0096] To ensure that data is not lost during network fluctuations or when cloud services are temporarily unavailable, Telegraf provides the following reliability mechanisms:

[0097] Batch processing and buffering: The amount of data sent each time is controlled by `metric_batch_size` (e.g., 1000) and `flush_interval` (e.g., 10s). The in-memory buffer queue has an upper limit set by `metric_buffer_limit`.

[0098] Persistent queue (optional): For scenarios with extremely high reliability requirements, a disk persistent queue can be enabled, which can still recover unsent data after the Telegraf process restarts.

[0099] Retry mechanism: Automatic retry when transmission fails, configured by max_retries (e.g., 5) and retry_interval (e.g., "10s"), and usually employs an exponential backoff strategy.

[0100] Step S205: Cloud reception, storage and display.

[0101] Specifically, after receiving the data stream pushed by Telegraf in the Influx LineProtocol format, VictoriaMetrics' write endpoint parses it and writes it to the underlying time-series storage engine.

[0102] For Grafana deployed in the cloud, add VictoriaMetrics as a data source. Operations personnel can then create dashboards and write queries using the PromQL query language. For example, to view the average CPU utilization of all edge nodes over the past 5 minutes, a query can be written as follows:

[0103] avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))by(edge_cluster_id,edge_node)

[0104] Alert rules can also be configured in Grafana or VictoriaMetrics to trigger notifications (such as emails, DingTalk, or webhooks) when a certain metric of an edge node exceeds a threshold.

[0105] Based on the above plan, the following optimizations can be made during implementation:

[0106] 1. Security reinforcement. This includes:

[0107] Encryption of transmission: Use HTTPS (configure TLS in the Telegraf output plugin and the VictoriaMetrics writer).

[0108] Authentication: Use Token authentication (as in the example above), or configure two-way TLS (mTLS) for more stringent two-way authentication.

[0109] Network policy: Within a Kubernetes cluster, use NetworkPolicy to restrict access to Prometheus' federated interfaces to only Telegraf Pods.

[0110] 2. Performance and cost optimization. This includes:

[0111] Metric sampling: During the Telegraf fetching phase, the full set of metrics is avoided by using a more precise match[] parameter.

[0112] Data downsampling: For historical data stored for a long time, you can use the downsampling function in VictoriaMetrics or the cloud to retain only the data with lower precision to save storage space.

[0113] Telegraf resource configuration: Adjust the CPU / memory limits of the Telegraf Pod appropriately based on the metrics and network conditions, especially the buffer pool size.

[0114] 3. Multi-edge node management. This includes:

[0115] Assign a unique edge_cluster_id to each edge node or cluster.

[0116] A load balancer or Ingress can be deployed in front of VictoriaMetrics in the cloud to receive data from all nodes in a unified manner.

[0117] In Grafana, you can use the Variables feature to dynamically switch between dashboards for different edge clusters or nodes.

[0118] As can be seen from the above specific implementation methods, the present invention provides a complete, reliable, secure and easy-to-maintain edge monitoring data cloud synchronization solution, which effectively solves the monitoring blind spot problem in edge computing scenarios and lays a solid foundation for the observability of distributed systems.

[0119] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0120] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0121] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0122] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0123] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0124] Furthermore, the functional units in the various embodiments of this invention can be integrated into a single processing module, or each unit can exist physically separately, or two or more units can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0125] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0126] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for supporting security monitoring and cloud synchronization of edge service devices, characterized in that, Applied to a system comprising at least one edge node and a cloud platform, the method includes the following steps: By utilizing the local monitoring module deployed within each edge node, metrics are collected and stored for the first time for the business services running on that node; Using a data relay module deployed within each edge node, monitoring indicator data is periodically pulled from the aggregation interface provided by the local monitoring module; The data transfer module is used to preprocess the retrieved monitoring indicator data. The preprocessing includes at least adding edge node identity tags to the monitoring indicator data to identify its source. Using the data relay module, the preprocessed monitoring indicator data is actively pushed to the cloud time-series database in the cloud platform for secondary storage via a secure network connection; The cloud platform utilizes the monitoring metrics data stored in the cloud-based time-series database to perform unified visualization and alarm analysis.

2. The method according to claim 1, characterized in that, The local monitoring module includes a first acquisition module and a first storage module; The first acquisition module is used to capture the indicator interface data exposed by each business service on the edge node; The first storage module is used to temporarily store the indicator interface data and to provide a federated interface for batch acquisition of the indicator interface data.

3. The method according to claim 2, characterized in that, The data transfer module is configured with an input plugin, which is configured to periodically access the federation interface to obtain aggregated monitoring metric data streams. The address of the federated interface is the service address of the first storage module, and it contains query parameters for filtering target monitoring indicator data.

4. The method according to claim 1, characterized in that, The preprocessing also includes at least one of the following operations: Filter the monitoring indicator data to remove preset non-critical indicators; The monitoring indicator data is relabeled to unify or supplement the indicator labeling system; Aggregate or downsample monitoring indicator data to reduce data transmission volume.

5. The method according to claim 1, characterized in that, The data relay module is equipped with an output plug-in, a local buffer module, and a retry mechanism. The output plugin is configured to convert the preprocessed monitoring metric data into a protocol format supported by the cloud time series database and send it. The local buffer module is used to temporarily cache monitoring indicator data to be sent when there is a network anomaly or the cloud service is unavailable. The retry mechanism is used to automatically retry according to a preset backoff strategy when the push fails, until the push is successful or the maximum number of retries is reached.

6. The method according to claim 1 or 5, characterized in that, The secure network connection is an HTTPS connection based on token authentication, basic authentication, or two-way TLS authentication.

7. The method according to claim 1, characterized in that, The cloud-based time-series database is VictoriaMetrics or a time-series database compatible with the Prometheus remote write protocol; The cloud platform deploys Grafana and configures the cloud-based time-series database as a data source to achieve the visualization and alarm analysis functions.

8. A system supporting security monitoring and cloud synchronization of edge service devices, characterized in that, This includes edge-side subsystems deployed at edge nodes and cloud-side subsystems deployed on cloud platforms; The edge-side subsystem includes: The local monitoring module is used to collect and temporarily store metrics of the business services running on the edge nodes, and expose a federated query interface. The data relay module is used to pull monitoring indicator data from the federated query interface and preprocess the pulled monitoring indicator data. The preprocessing includes at least adding edge node identity tags, and then sending the processed monitoring indicator data to the cloud through an active push method. The cloud subsystem includes: The data receiving and storage module is used to receive and persistently store monitoring indicator data from each edge node; The data display and analysis module is used to visualize and analyze the monitoring indicator data stored in the data receiving and storage module.

Images