A High-PPS DDoS Attack Detection and Alarm System and Method Based on Containerized Flow Analysis

Abstract

The application discloses a high PPS DDoS attack detection and alarm system and method based on containerized flow analysis, and belongs to the technical field of network security.The system comprises a traffic collection and processing component, a data storage and visualization component, an alarm engine component, an alarm execution module and a double whitelist filtering module; the traffic collection and processing component is containerized by Docker Compose, adopts an ElastiFlow Logstash container, opens a 6343 / UDP port to receive sFlow flow data sent by a network device, decodes and maps the flow data into a standard Elasticsearch document structure, and sets the JVM heap memory to 4G through an environment variable; a decoupling architecture of 'lightweight alarm triggering + heavy-duty detail completion' is adopted; ElastAlert2 only performs high-performance purpose IP data packet aggregation and threshold judgment (calculation is pushed down to an Elasticsearch distributed engine), and a Python script only performs secondary query when alarm triggering, so that a full-link process from traffic anomaly to email notification is completed within 5 minutes.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a high PPS DDoS attack detection and alerting system and method based on containerized flow analysis. Background Technology

[0002] With the continuous improvement of data center network bandwidth, large-scale DDoS attacks targeting public IP addresses are becoming increasingly frequent. High PPS (packets per second) attacks, in particular, are prone to causing network outbound congestion and server paralysis due to their small packet size and high quantity. Currently, mainstream network traffic monitoring and DDoS attack detection systems primarily collect data based on flow protocols such as NetFlow and sFlow, combined with log analysis tools for alerting. However, they generally suffer from the following technical shortcomings: The system deployment is complex, and a large amount of glue code is needed to connect the collection, storage, alarm and notification links. There is a lack of integrated deployment solutions, resulting in high operation and maintenance costs. Traditional streaming data processing methods involve massive amounts of data, requiring operations and maintenance personnel to manually log into multiple systems to query and analyze data. Attack response latency is high, and it often takes tens of minutes or even hours from the occurrence of an attack to the location of the target. The rigid alarm rules, which use fixed thresholds, cannot distinguish between normal business surges and real attacks, and lack an effective whitelist exclusion mechanism, which easily generates a large number of false alarms and triggers an alarm storm. The alarm information is crude, only indicating that there is abnormal traffic, but it cannot provide detailed contextual information such as the source of the attack, the target of the attack, the protocol type, the amount of traffic, and the scope of impact, making it impossible for operation and maintenance personnel to quickly formulate a handling strategy.

[0003] While existing technologies offer solutions for traffic analysis based on the ELK stack (Elasticsearch, Logstash, Kibana) combined with ElastiFlow, these solutions mostly remain at the data visualization level. They are not deeply optimized for the characteristics of high PPSDDoS attacks, nor do they achieve automated detail completion and accurate alerts, thus failing to meet the real-time detection needs of large data center network egress points. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide a high PPS DDoS attack detection and alarm system and method based on containerized flow analysis; it can solve the problems of complex deployment, high response latency, high false alarm rate and incomplete alarm information in the existing DDoS attack detection technology.

[0005] Technical Solution: To solve the above-mentioned technical problems, according to one aspect of the present invention, more specifically, a high PPS DDoS attack detection and alarm system based on containerized flow analysis, comprising: a traffic acquisition and processing component, a data storage and visualization component, an alarm engine component, an alarm execution module, and a dual whitelist filtering module: The traffic acquisition and processing component is containerized and orchestrated using Docker Compose, employs the ElastiFlowLogstash container, opens port 6343 / UDP to receive sFlow stream data sent by network devices, decodes and maps the stream data into a standard Elasticsearch document structure, and sets the JVM heap memory to 4G through environment variables. The data storage and visualization components include an Elasticsearch container and a Kibana container. The Elasticsearch container enables security authentication and mounts a host data volume to achieve persistent data storage, while the Kibana container provides a visual query interface. The alarm engine component uses the ElastAlert2 container, which mounts a custom rule directory and a script directory. The core rule uses the metric_aggregation type, which is used to aggregate the total number of network packets to the destination IP within a 5-minute time window and trigger an alarm when the cumulative number of packets exceeds the threshold. The alarm execution module is a Python alarm script that is called after an alarm is triggered by ElastAlert2. It receives two key variables: the destination IP and the total number of aggregated data packets. It performs a secondary query to Elasticsearch to complete the attack context information and generates a detailed alarm email to be sent to the email server. The dual whitelist filtering module is deployed in the alarm engine component and the alarm execution module, respectively. The alarm engine component excludes whitelisted IPs at the Elasticsearch query level using the must_not statement, and the alarm execution module verifies the whitelisted IPs again at the script entry point to block the sending of false alarm emails.

[0006] Furthermore, the core rule configuration of ElastAlert2 includes: Index matching rule: Match elastiflow-* indexes; Aggregate window configuration: buffer_time.minutes is set to 5, i.e., 5 minutes; Aggregate key configuration: destination.ip is the destination IP address; Aggregate metric configuration: the sum value of network.packets, i.e., the total number of packets; Threshold configuration: max_threshold is set to 80,000,000, which means 80 million packets / 5 minutes; Whitelist filtering: Exclude specific destination IPs at the Elasticsearch query level using must_not; Repeat alarm suppression configuration: set realert.minutes to 1, meaning no repeat alarms will occur within 1 minute.

[0007] Furthermore, the attack context information completed by the Python alarm script includes: a list of source IP addresses, a range of source ports, a destination port, a protocol type, a cumulative number of bytes, an average bandwidth in Mbps, geographical location information, an AS number, and information about the data collection device.

[0008] Furthermore, the Python alarm script automatically converts the cumulative number of bytes over 5 minutes into the average bandwidth in Mbps. The conversion formula is: average Mbps = (cumulative number of bytes × 8) / (5 × 60 × 1000000).

[0009] Furthermore, the system enables one-click deployment via DockerCompose, requiring only the modification of the Elasticsearch security password, email SMTP configuration, and whitelist of IP addresses for operations and maintenance personnel to complete the deployment.

[0010] According to another aspect of the present invention, a method for detecting and alerting high PPS DDoS attacks based on containerized flow analysis is provided. This method is implemented based on the aforementioned system for detecting and alerting high PPS DDoS attacks based on containerized flow analysis, and includes the following steps: S1. Containerized Deployment: Start four containers—ElastiFlow Logstash, Elasticsearch, Kibana, and ElastAlert2—using Docker Compose orchestration and complete basic configuration. S2. Traffic Acquisition and Transmission: The network device generates sFlow stream data at a specified sampling rate and sends it to port 6343 / UDP of the ElastiFlow Logstash container. Logstash decodes the stream data into a standard Elasticsearch document and writes it to Elasticsearch. S3. Data storage and visualization: Elasticsearch performs distributed storage for received streaming data, while Kibana provides a visualization interface for operations and maintenance personnel to query and analyze. S4. Aggregated Alarm Detection: ElastAlert2 aggregates and calculates the total number of network packets for each destination IP according to a preset 5-minute aggregation window. When the cumulative number of packets for a destination IP in 5 minutes exceeds the threshold of 80 million, an alarm is triggered and a Python alarm script is called. S5. Double whitelist filtering: First, ElastAlert2 excludes whitelisted IPs during the query phase, and then the Python alarm script verifies the whitelisted IPs again during the execution phase. If a whitelist is found, the process terminates. S6. Attack Details Completion: The Python alert script queries Elasticsearch for all flow records of the target IP within a 5-minute window, extracts and organizes the attack context information; S7. Alert Notification: A Python alert script generates an alert email containing complete attack information and sends it to operations and maintenance personnel via an email server. Furthermore, in step S1, the basic configuration includes: setting the Elasticsearch security authentication password, configuring the custom rule directory and script directory of ElastAlert2, and configuring the SMTP email parameters and whitelist IP list of the Python alarm script.

[0011] Furthermore, in step S2, the network device sFlow sampling rate is 1:100000.

[0012] Furthermore, in step S6, the attack context information includes: a list of source IP addresses, a range of source ports, a destination port, a protocol type, a cumulative number of bytes, an average bandwidth per Mbps, geographical location information, an AS number, and information about the data collection device.

[0013] Furthermore, step S6 also includes an automatic traffic trend conversion step: the Python alarm script automatically calculates the average Mbps bandwidth based on the cumulative number of bytes, and the conversion formula is: average Mbps = (cumulative number of bytes × 8) / (5 × 60 × 1000000).

[0014] Beneficial effects: Employing a decoupled architecture of "lightweight alarm triggering + heavyweight detail completion": ElastAlert2 only performs high-performance destination IP packet aggregation and threshold judgment (calculation pushed down to the Elasticsearch distributed engine), while the Python script only performs a secondary query when an alarm is triggered, ensuring the entire process from traffic anomaly to email notification is completed within 5 minutes. Alarm information is "diagnostic and report-oriented": automatically completing 9 types of core contextual information, including source IP list, port range, protocol type, bandwidth, geographical location, AS number, and collection device. Operations personnel no longer need to manually query traffic graphs and perform packet capture analysis across systems, significantly shortening the average fault location time. A 1-minute duplicate alarm suppression mechanism prevents repeated alarm bombardment from the same IP, ensuring operations personnel focus on real attack events.

[0015] Rule-level whitelist: During the Elasticsearch query phase, whitelisted IPs are directly excluded using the `must_not` statement, reducing invalid aggregation calculations and filtering known business traffic at the source. Script-level whitelist: Secondary validation is performed before email sending to block false alarms caused by rule-level omissions (such as temporarily added business IPs). Combined with a reasonable 5-minute aggregation window: Effectively filters sudden traffic spikes (such as second-level business peaks), avoiding false alarms triggered by short-term data packet fluctuations.

[0016] Docker Compose orchestrates four core components (ElastiFlow Logstash, Elasticsearch, Kibana, and ElastAlert2) for out-of-the-box operation. No manual installation of dependencies like Java or Python is required, nor is writing complex Logstash pipeline scripts or Elasticsearch query statements necessary. Deployment requires only modifications to three core configurations: the Elasticsearch security password, email SMTP parameters, and the whitelist of IP addresses. This significantly reduces deployment time and supports rapid migration and horizontal scaling.

[0017] ElastiFlow Logstash, configured with 4GB of JVM heap memory, ensures stable processing of hundreds of thousands of sFlow streams per second. Aggregation computation is entirely pushed down to the Elasticsearch distributed engine, with the alerting engine and scripts consuming only a small amount of CPU and memory resources. An 8-core, 16GB standard server can support traffic detection needs at data center egress rates exceeding 100Gbps, reducing hardware costs compared to traditional dedicated detection equipment. Persistent data storage: Elasticsearch mounts host data volumes, supporting long-term storage and retrospective querying of historical traffic data.

[0018] Alarm rules are configured via YAML files: Aggregation windows, thresholds, and re-alarm intervals can be quickly adjusted without modifying code, and it supports adding detection rules for other flow protocols such as NetFlow and IPFIX. The Python alarm scripts feature a modular design: easily expandable to various notification channels such as WeChat, DingTalk, WeChat Work, and SMS. The Kibana visualization interface supports custom dashboards: visualization components such as traffic trend charts, attack type statistics, and geographic distribution can be added according to operational needs. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the system principle; Figure 2 This is a flowchart illustrating the method. Figure 3 This is a flowchart of alarm execution and dual whitelist filtering. Detailed Implementation

[0020] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Example 1

[0022] 1. System Deployment Environment (1) Hardware environment Server configuration: 2 servers with 8 cores and 16GB RAM each (primary / backup mode) Operating System: CentOS 7.9 64-bit, kernel version 3.10.0-1160.el7.x86_64 Storage: 500GB SSD data volume (for Elasticsearch data storage) Network: Dual gigabit network cards, one for management network and one for traffic collection network. (2) Software environment Docker version: 20.10.21-ce Docker Compose version: 2.12.2 Container images: ElastiFlow Logstash: elastiflow / logstash:6.5.0 Elasticsearch: [docker.elastic.co / elasticsearch / elasticsearch:7.17.6](docker.elastic.co / elasticsearch / elasticsearch:7.17.6) Kibana: [docker.elastic.co / kibana / kibana:7.17.6](docker.elastic.co / kibana / kibana:7.17.6) ElastAlert2:jertel / elastalert2:2.12.0 2. System Configuration Details (1) Container orchestration configuration All container services are defined using docker-compose.yml, with core configurations including: ElastiFlowLogstash: Maps port 6343 / UDP and sets the environment variable LS_JAVA_OPTS=-Xms4g-Xmx4g Elasticsearch: Enable security authentication, mount the / data / elasticsearch data volume, and set it to single-node mode. Kibana: Map port 5601, configure Elasticsearch connection address and authentication information. ElastAlert2: Mount the . / rules directory and the . / scripts directory, and configure Elasticsearch connection parameters. (2) Network equipment configuration Enable sFlow functionality on the data center egress core switch Sampling rate: 1:100000 (optimized for 100Gbps egress bandwidth) Sampling ports: All uplink ports Data collection target: UDP port 6343 of the primary and backup servers. (3) Alarm rule configuration Create the high_pps_rule.yaml file, core configuration: yamlname: High PPS DDoS Attack Detectiontype: metric_aggregationindex: elastiflow-*buffer_time: minutes: 5metric_agg_key:network.packetsmetric_agg_type: sumquery_key: destination.ipmax_threshold:80000000filter: - must_not: terms: destination.ip: - 10.0.0.0 / 8 # Management network segment - 172.16.0.0 / 12 # Core business network segment - 192.168.0.0 / 16 # Internal network segment realert: minutes:1alert: - commandcommand: ["python3", " / scripts / send_detailed_alert.py", "%(destination.ip)s", "%(metric_agg_value)s"] (4) Alarm script configuration Modify the SMTP parameters in send_detailed_alert.py: Set the enterprise email server address to smtp.isp.com, port 587, and enable TLS encryption. Configure script-level whitelist: Keep it consistent with the rule-level whitelist, and add temporary business IP ranges. Configure recipients: the operations team's email address netops@isp.com and the security team's email address security@isp.com. 3. Operational Results and Attack Handling Cases (1) Daily operation effect The system has been running stably for 6 months, processing an average of 120,000 sFlow streams per second. Elasticsearch disk utilization: Daily increase of 15GB, retaining 30 days of historical data. A total of 17 real alerts were triggered, and 2 false alarms were triggered (both were temporary business IPs that were not added to the whitelist in time), with a false alarm rate of 1.1%. (2) Typical attack handling cases Attack time: March 15, 2026, 14:23 Alarm message: The system detected that the cumulative number of data packets destined for IP 203.0.113.45 reached 120 million in 5 minutes (far exceeding the 80 million threshold). Alert email details: Attack source: 3276 IP addresses Protocol type: ICMP (accounting for 98%) Traffic characteristics: Average bandwidth 3.6Gbps, average PPS approximately 400,000 AS numbers: mainly from AS12345 (a certain overseas data center) and AS67890 (a certain anonymous network). Data Acquisition Equipment: Egress Core Switch Handling Process: Upon receiving the alarm, the operations and maintenance personnel immediately configured ACL rules on the egress switch to block the destination IP address. Outcome: The attack traffic was completely suppressed within 2 minutes, without affecting other services. The entire process took 7 minutes. Comparison results: Before deploying this system, the average handling time for similar attacks was 75 minutes, which resulted in two business interruptions.

[0023] Example 2

[0024] 1. System Deployment Environment (1) Hardware environment Server configuration: 3 servers with 16 cores and 32GB RAM (cluster mode) Operating System: Ubuntu 22.04 LTS Storage: Each server is configured with a 1TB data volume. Network: 10 Gigabit Ethernet interface card, connecting to the cloud platform's core switching network. (2) Software environment Docker version: 24.0.6-ce DockerCompose version: 2.23.3 Container Image: Similar to Example 1, Elasticsearch uses a three-node cluster mode. 2. System Configuration Details (1) Container orchestration configuration Elasticsearch: Configure a three-node cluster, enable sharding and replication mechanisms to ensure high data availability. ElastiFlow Logstash: Deploy 3 instances to achieve traffic load balancing. ElastAlert2: Deploy two instances in a master-slave mode to avoid single points of failure. Added DingTalk notification module: Extends Python scripts to support sending emails and DingTalk alerts simultaneously. (2) Network equipment configuration Enable sFlow functionality on the VPC egress router in the cloud platform. Sampling rate: 1:50000 (optimized for a total outbound bandwidth of 500Gbps) Configure a separate sampling instance for each tenant's VPC egress. Data collection target: Port 6343 / UDP port of 3 Logstash servers (3) Multi-tenant alarm rule configuration Configure differentiated thresholds for different tenants: Regular tenant: 5-minute cumulative data packet count threshold of 40 million Large clients: 5-minute cumulative data packet count threshold of 160 million Whitelist configuration: Each tenant maintains its own business IP whitelist, which is automatically synchronized to the system via API. Alarm routing: Alarms from different tenants are sent to the corresponding operations and maintenance personnel's email address and DingTalk group. (4) DingTalk notification configuration Add a DingTalk robot Webhook call to the Python script, with the following alert content: Attack level (high / medium / low) Attacked IPs and their tenants Attack traffic and PPS value One-click link blocking (integration with cloud platform firewall API) 3. Operational Results and Attack Handling Cases (1) Daily operation effect The system supports traffic detection for a total egress bandwidth of 500Gbps on the cloud platform, covering 2000+ tenants. On average, it processes 500,000 sFlow streams per second, and the Elasticsearch cluster CPU utilization remains consistently below 30%. A total of 89 real alarms were triggered, with 3 false alarms, resulting in a false alarm rate of 3.3% (mainly due to sudden surges in tenant business traffic). (2) Typical attack handling cases Attack time: May 20, 2026, 09:17 Alarm message: The system detected that the cumulative number of data packets of tenant A's cloud server IP 198.51.100.78 reached 92 million in 5 minutes (the threshold for ordinary tenants is 40 million). Alarm notification: Simultaneously sent to tenant A's operations and maintenance email and DingTalk group. The DingTalk message includes a one-click ban button. Alert email details: Attack source: 12,000 IP addresses Protocol type: UDP (99%), destination port random Traffic characteristics: Average bandwidth 2.8Gbps, average PPS approximately 310,000 Attack type: UDP flood attack Handling Process: The tenant's operations and maintenance personnel clicked the one-click blocking button in the DingTalk message. The system automatically called the cloud platform firewall API and completed the IP blocking within 10 seconds. Outcome: The attack traffic was immediately blocked, and the tenant's business was not affected in any way. The entire process took 1 minute and 30 seconds. Comparison of results: Before deploying this system, tenants were required to discover attacks and submit support tickets themselves, with an average response time of 45 minutes, which led to multiple business interruptions for tenants. The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A high PPS DDoS attack detection and alerting system based on containerized flow analysis, characterized in that, include: Traffic acquisition and processing components, data storage and visualization components, alarm engine components, alarm execution modules, and dual whitelist filtering modules: The traffic acquisition and processing component is containerized and orchestrated using Docker Compose, employs the ElastiFlowLogstash container, opens port 6343 / UDP to receive sFlow stream data sent by network devices, decodes and maps the stream data into a standard Elasticsearch document structure, and sets the JVM heap memory to 4G through environment variables. The data storage and visualization components include an Elasticsearch container and a Kibana container. The Elasticsearch container enables security authentication and mounts a host data volume to achieve persistent data storage, while the Kibana container provides a visual query interface. The alarm engine component uses the ElastAlert2 container, which mounts a custom rule directory and a script directory. The core rule uses the metric_aggregation type, which is used to aggregate the total number of network packets to the destination IP within a 5-minute time window and trigger an alarm when the cumulative number of packets exceeds the threshold. The alarm execution module is a Python alarm script that is called after an alarm is triggered by ElastAlert2. It receives two key variables: the destination IP and the total number of aggregated data packets. It performs a secondary query to Elasticsearch to complete the attack context information and generates a detailed alarm email to be sent to the email server. The dual whitelist filtering module is deployed in the alarm engine component and the alarm execution module, respectively. The alarm engine component excludes whitelisted IPs at the Elasticsearch query level using the must_not statement, and the alarm execution module verifies the whitelisted IPs again at the script entry point to block the sending of false alarm emails.

2. The high PPS DDoS attack detection and alarm system based on containerized flow analysis according to claim 1, characterized in that: The core rule configuration of ElastAlert2 includes: Index matching rule: Match elastiflow-* indexes; Aggregate window configuration: buffer_time.minutes is set to 5, i.e., 5 minutes; Aggregate key configuration: destination.ip is the destination IP address; Aggregate metric configuration: the sum value of network.packets, i.e., the total number of packets; Threshold configuration: max_threshold is set to 80,000,000, which means 80 million packets / 5 minutes; Whitelist filtering: Exclude specific destination IPs at the Elasticsearch query level using must_not; Repeat alarm suppression configuration: set realert.minutes to 1, meaning no repeat alarms will occur within 1 minute.

3. The high PPS DDoS attack detection and alarm system based on containerized flow analysis according to claim 1, characterized in that: The attack context information completed by the Python alarm script includes: source IP address list, source port range, destination port, protocol type, cumulative bytes, average Mbps bandwidth, geographical location information, AS number, and data collection device information.

4. The high PPS DDoS attack detection and alarm system based on containerized flow analysis according to claim 3, characterized in that: The Python alarm script automatically converts the cumulative bytes count over 5 minutes into the average Mbps bandwidth. The conversion formula is: average Mbps = (cumulative bytes count × 8) / (5 × 60 × 1000000).

5. The high PPS DDoS attack detection and alarm system based on containerized flow analysis according to claim 1, characterized in that: The system can be deployed with one click using DockerCompose. Operations personnel only need to modify the Elasticsearch security password, email SMTP configuration, and whitelist of IP addresses to complete the deployment.

6. A high PPS DDoS attack detection and alerting method based on containerized flow analysis, characterized in that: This method is implemented based on the high PPS DDoS attack detection and alerting system based on containerized flow analysis as described in any one of claims 1-5, and includes the following steps: S1. Containerized Deployment: Start four containers—ElastiFlow Logstash, Elasticsearch, Kibana, and ElastAlert2—using Docker Compose orchestration and complete basic configuration. S2. Traffic Acquisition and Transmission: The network device generates sFlow stream data at a specified sampling rate and sends it to port 6343 / UDP of the ElastiFlowLogstash container. Logstash decodes the stream data into a standard Elasticsearch document and writes it to Elasticsearch. S3. Data storage and visualization: Elasticsearch performs distributed storage for received streaming data, while Kibana provides a visualization interface for operations and maintenance personnel to query and analyze. S4. Aggregated Alarm Detection: ElastAlert2 aggregates and calculates the total number of network packets for each destination IP according to a preset 5-minute aggregation window. When the cumulative number of packets for a destination IP in 5 minutes exceeds the threshold of 80 million, an alarm is triggered and a Python alarm script is called. S5. Double whitelist filtering: First, ElastAlert2 excludes whitelisted IPs during the query phase, and then the Python alarm script verifies the whitelisted IPs again during the execution phase. If a whitelist is found, the process terminates. S6. Attack Details Completion: The Python alert script queries Elasticsearch for all flow records of the target IP within a 5-minute window, extracts and organizes the attack context information; S7 Alarm Notification: The Python alarm script generates alarm emails containing complete attack information and sends them to operations and maintenance personnel via the email server.

7. The high PPS DDoS attack detection and alerting method based on containerized flow analysis according to claim 6, characterized in that: In step S1, the basic configuration includes: setting the Elasticsearch security authentication password, configuring the custom rule directory and script directory for ElastAlert2, and configuring the SMTP email parameters and whitelist IP list for the Python alert script.

8. The high PPS DDoS attack detection and alerting method based on containerized flow analysis according to claim 6, characterized in that: In step S2, the network device sFlow sampling rate is 1:100000.

9. The high PPS DDoS attack detection and alerting method based on containerized flow analysis according to claim 6, characterized in that: In step S6, the attack context information includes: a list of source IP addresses, a range of source ports, a destination port, a protocol type, a cumulative number of bytes, an average bandwidth per Mbps, geographical location information, an AS number, and information about the data collection device.

10. The high PPS DDoS attack detection and alerting method based on containerized flow analysis according to claim 9, characterized in that: In step S6, there is also an automatic traffic trend conversion step: the Python alarm script automatically calculates the average Mbps bandwidth based on the cumulative number of bytes. The conversion formula is: average Mbps = (cumulative number of bytes × 8) / (5 × 60 × 1000000).

Images