Create Alert Rules
Last update：2025-08-15 15:55:27
Users can choose to enable System-defined alert rules or configure custom alert rules according to their own business characteristics. This article introduces the basic concepts of rules and guides you to create a new rule.
Go to Alert Management：
- Log in to the CDNetworks Console, find the security product in use under Subscribed Products.
- Go to Analysis & Logs > Alert Management.
Basic Concepts
System-Defined Rules and Custom Rules
System-defined rules are created by security operation experts, continuously detect all hostnames that have been accessed and protected and record alert history. Users can choose whether to accept notifications, but cannot edit or delete rules. The three types of system-defined rules currently supported are as follows:
| Rule Type | Rule Name |
|---|---|
| Attack Awareness Notification | Website is suffering from L4 DDoS attack |
| Emergency Response Notification | L7 DDoS attack reduces website availability |
| Service Switching Notification | CPS IP is blackholed |
By default, each customer can customize up to 20 alert rules.
An Alert Cycle
A complete alert cycle includes a trigger phase (conditions satisfied → alert generated), a duration phase (conditions maintained → alert notification), and a recovery phase (conditions removed → alert recovery).
Alert Trigger Phases
Alert trigger conditions depend on two core configurations: Statistical Period and Custom Statistical Metrics. Detailed explanations are as follows:
Statistical Period
| Description | Configuration Items | Configurable Options |
|---|---|---|
| A statistical period includes: statistical granularity and the number of continuous statistical points. Statistics granularity: Defines the metric detection interval The number of continuous statistics points: Defines the detection duration For example, if you select 1-minute granularity and 3 continuous statistics points, the system will perform metric detection every minute. If the configured threshold for the metric is reached for all 3 checks, an alert will be triggered. |
N-minute statistics granularity | 1-min granularity 2-min granularity 5-min granularity 10-min granularity |
| Continuous N statistics points | Continue for 1 statistical point Continue for 2 statistical points Continue for 3 statistical points Continue for 4 statistical points Continue for 5 statistical points |
Statistical Metrics
| Description | Monitoring Object | Configuration Item | Configurable Options | Example of Metric Calculation Logic |
|---|---|---|---|---|
| Statistical metric sets the monitoring expression to be calculated. A statistical metric includes: basic metrics and filters, which are combined to filter out metrics that meet the filter conditions for statistics. | L7 Protection | Basic Metrics | Requests QPS Back-to-Origin Requests OBack-to-Origin QPS |
Configuration: Basic Metrics: Number of Requests Filter Fields: 1. WAF - Rule Type = XSS, SQL; 2. Action = Deny That is, count: The number of requests where Action is Deny and WAF - Rule Type is triggered as XSS or SQL Please select filter fields for enabled protection services to ensure the system can monitor relevant data and send alerts. |
| Filters | Policy: Policy Type, Action Request: Path, Request Method, Response Code DDoS Protection: Policy Name WAF: Rule Type |
|||
| L4 Protection | Basic Metrics | Peak Attack Bandwidth CPS Blackhole |
Basic Metric: DDoS Attack Bandwidth Peak Value Filter Field: DDoS Attack Type = SYN, ACK That is, count: The sum of the peak bandwidth of SYN Flood and ACK Flood attacks The logic of CPS black hole is: if any CPS IP in the resource group is black-holed, the alert will be triggered; when the black hole is released, the alert will be eliminated. |
|
| Filters | DDoS Attack Type |
Threshold Operator
| Operator Type | Operator | Example |
|---|---|---|
| Numeric Comparison | > , >= | Example: Requests > 100th |
| <, <= | Example: Requests < 100th | |
| =, != | Example: Requests = 100th | |
| Cross-period Fluctuation | Up from yesterday, Down from yesterday | Example: Back-to-Origin Requests Up from yesterday 30% Comparison calculation rule handling Note: Currently, comparison calculations do not support adding filter conditions. |
| Ratio Calculation | Proportion >=, Proportion < | Example: Back-to-origin 5xx error request Proportion >= 20% Basic Metric: Back-to-Origin Requests Proportion >= 20%Filters: Response Code equals 5xx Note: To calculate the proportion, a filter condition must be added in order to compute the valid percentage. |
Alert Duration Phase
During the alert duration phase, users can customize the frequency of alert notifications. The frequency is determined by Repeat alert every N minutes(hours), and whether or not a notification is required. Details are as follows:
| Configuration Item | Configurable Options | Example |
|---|---|---|
| Alert notification every N minutes | Only alert at first time Repeat alert every 5 mins Repeat alert every 10 minutes Repeat alert every 15 minutes Repeat alert every 30 minutes Repeat alert every 1 hour Repeat alert every 2 hours Repeat alert every 6 hours Repeat alert every 12 hours Repeat alert every 24 hours |
Scenario: The alert duration is 12 minutes, configured to repeat alert every 5 minutes, and elimination notification is required. It means that after the alert is triggered, the frequency is: push the first notification immediately when triggered, push the second notification at an interval of 5 minutes, push the third notification at an interval of 10 minutes, and push the recovery notification when the alert is eliminated at the 12th minute. |
| Is a recovery notification required | Yes: Receive notification No: Do not receive notification |
Alert Delay Description:
- The first notification is an instant push after the alert is triggered, and the delay from the alert generation to the push to the terminal is as follows:
Application layer protection alarm latency: approximately 2 minutes
Network layer protection alarm latency: approximately 4 to 5 minutes
CPS service route switch notification alarm: approximately 2 minutes- Notifications during the alert duration phase are executed every 30 seconds. For example, monitoring data at 05:50 will start the process flow at 05:30, the actual notifications may have a second-level time fluctuations (±30 seconds).
Alert Recovery Phase
If the metric data that triggered the alert does not reach the threshold Continue for N statistical periods, the system will release the alert. Its execution logic is as follows:
- The system starts timing from the point when the metric is first detected below the threshold.
- Continuously check the status of the metrics at the interval of the statistical period.
- If the recovery conditions are met for N consecutive detection, the alert will be released.
For example,
The statistical period is 2 minutes (statistical granularity is 1 minute, continue for 2 statistical points), and lasting 2 statistical periods recovery. The system will detect the metric every minute starting from the minute when the number of requests does not exceed the threshold, and if it does not exceed the threshold for 4 consecutive times, the alert will be released.
Configure Alert Rules
On the Alarm Management page, click Add Alert Rule to configure a new rule. The configuration options and relevant descriptions are as follows:
| Configuration Items | Description | |
|---|---|---|
| Basic Information | Rule Name | Custom rule name, up to 50 characters. |
| Rule Description | Custom rule description, up to 200 characters. | |
| Alert Rules | Alert Level | Set the alert level when triggered. You can determine the handling priority based on this level. Available levels: Emergency、Critical、Warning |
| Monitoring Object | Specify the object to be monitored by this alert rule. Available monitoring objects include: L7 Protection: Monitor Hostname. L4 Protection: Monitor Resource Group. Note: The monitoring hostnames that can be selected in L7 Protection are the hostnames that have been accessed to Security Protection. |
|
| Statistics Method | Set the statistics method for the monitored objects of this rule. The optional statistical methods are: Separate: Monitor the data of each object in the monitoring object. Aggregate: Monitor the aggregate data in the monitoring object. A maximum of 1000 objects are supported, and the first 1000 for aggregated statistics if the upper limit is exceeded. |
|
| Statistical Metric | Set the alert trigger logic for this alert rule. For details, see the 'Alert Trigger Phase' section at the top of the documentation. | |
| Alert Frequency | Set the notification frequency for this alert rule. For details, see the 'Alert Duration Phase' section at the top of the documentation. | |
| Alert Notification | Alert Elimination Notification | Select whether to accept the alert elimination notification when it is recovered. For details, see the 'Alert Duration Phase' described above in the documentation. |
| Notification Period | Set the time period for receiving notifications. if that alert is trigger outside the time period, only alert history is recorded. The configuration items are as follows: Set time range: Start time and end time. Confirm time zone Select effective days of the week: Monday to Sunday Note: The start time of the notification time can be greater than the end time, and the notification will be sent at the start time of the period until the end time of the current day or across days. For example, if you configure 23:00-02:00, the time period for receiving notifications is from 23:00 on the same day to 2:00 a.m. the next day. |
|
| Notification Language | Set the language for alert notifications. The following language options are supported: Chinese、English. |
|
| Notification Method | Set the method to receive notifications. The following method are supported: Email: You need to add contacts or contact groups under Account Management > Contact Management. For detailed steps, see: Contact Management. Robots: You need to add a bot under Message Center > Robot Management. The currently supported bot options are: WeCom, DingTalk, Telegram, Feishu, Lark, and Slack. |
|
After a new rule is created, the alert status is Enabled by default, and the Data Analysis Center will start alert monitoring. To edit or delete custom alert rules, you must first set the rule status to Disabled.
Scenario Example
Scenario 1: Detect whether Adaptive Protection issues rules to block traffic when a CC attack occurs
Scenario Description
When a new CC attack occurs, Adaptive Protection locates the attack and issues corresponding AI rules based on the specific attack characteristics. At this time, through the alert, user can quickly perceive the issuance of rules and the processing actions for traffic, and timely access and analyze whether there is a risk such as false interception.
Steps
- On the Alert Management page, click Add Alert Rule to enter the alert rule configuration page.
- Configure Basic information: Rule name and rule description (optional).
- Configure rule details:
- Select the alert level.
- Select the monitoring object: L7 protection - All hostnames
- Select the statistical method: Separate
- Configure statistical metrics: Set the statistical cycle, for example, 1 minute granularity, continuous for 3 statistical points. The alert is triggered when All of the following conditions are met; choose the base metric expression, such as Requests > 100; add filter such as Action equals Block, and DDoS Protection – Policy Name equals Adaptive Protection.
- Configure the alert frequency: For example, Repeat alert every 5 minutes. because AI intelligent protection rules will be automatically deleted 15 minutes after the attack stops, you can configure when Continue for 3 statistical period does not meet the trigger condition(s), the alert will be cleared.
- Configure alert notifications: Alert Elimination select Yes, configure the notification period to remain the default (full-time), notification language, and notification method.