Real-time synchronization pipelines can fail silently — nodes stop processing data while appearing to run, Kafka consumers fall behind without warning, and DDL changes at the source break downstream schemas. Configure alert rules in Operation Center to detect these conditions before they affect your data.
This topic covers the seven available alert metrics, supported notification channels, and a step-by-step guide to sending alerts to a DingTalk group.
Alert metrics
DataWorks provides seven metrics for alerting on real-time synchronization nodes. These metrics apply to standalone nodes in Data Integration and nodes created by full and incremental data synchronization solutions.
The metrics fall into two categories based on how urgently they require action:
| Category | Metric | Impact |
|---|---|---|
| Blocking | Status | Node is not processing data |
| Blocking | Business delay | Node is falling behind the source |
| Blocking | Accumulated Messages | Kafka consumer lag is growing |
| Investigative | Failover | Frequent restarts may indicate instability |
| Investigative | DDL Notification | Schema changes at the source need review |
| Investigative | Dirty Data | Failed writes are being discarded |
| Deprecated | Not Supported by DDL Statements | Scheduled for removal — use DDL Notification instead |
Core metrics (recommended for all nodes)
These metrics detect conditions that directly block data flow. Add them to every important real-time synchronization node.
Status
Monitors node health using the heartbeat of the synchronization process. When the heartbeat stops, the node is no longer processing data.
Set the threshold to 3 minutes or more. Lower thresholds trigger false positives during network jitter or transient exceptions, which resolve automatically without intervention.
Business delay
Measures the gap between the data processing rate of a synchronization node and the data production rate of the source. When this gap grows, the node is falling behind.
Set the threshold at minute granularity to avoid false positives from network jitter or short-lived data spikes at the source. Set the threshold based on the maximum acceptable delay for your pipeline.
For nodes that synchronize data from Kafka sources, use Accumulated Messages instead of Business delay.
Accumulated Messages (Kafka sources only)
Available only for real-time synchronization nodes with Kafka data sources. Measures the number of accumulated messages based on the offset difference between the Kafka source and a consumer.
Use this metric as the primary delay indicator for all Kafka-source synchronization nodes.
Investigative metrics
These metrics track specific events that may require investigation but do not always indicate a blocking failure.
Failover
Monitors the restart behavior of a synchronization process. Data Integration's control service automatically restarts a process when it exits due to an exception.
Use this metric to detect frequent failovers, which may indicate an underlying stability issue worth investigating.
DDL Notification
Checks whether a specified DDL event type has occurred. An alert fires whenever a matching DDL event is detected, independent of how the synchronization node is configured to process that event.
Use this metric for all scenarios where you need to monitor DDL events, including warning-level and critical-level events.
Dirty data
Identifies data records that fail to be written to the destination during real-time synchronization.
By default, real-time synchronization nodes do not support dirty data, so this metric is not needed under default settings. Enable it only if the dirty data processing policy for the node has been changed to tolerating.
Changing the dirty data policy to tolerating causes failed writes to be discarded, creating data inconsistency between the source and destination. Avoid changing this policy unless necessary.
Deprecated metric
Not Supported by DDL Statements
This metric is scheduled for removal. Use DDL Notification instead — it covers the same warning-level and critical-level DDL event scenarios without depending on DDL processing policies.
Alert notification methods
The following notification methods are supported: email, text message, DingTalk, and webhook URL.
DataWorks sends alert notifications to the email address configured for each alert recipient on the Alert Contacts page in the DataWorks console. If no email address is configured, the notification goes to the email address of the associated Alibaba Cloud account.
Check your spam or junk folder if alert notification emails are not arriving.
Text message
DataWorks sends alert notifications to the phone number configured for each alert recipient on the Alert Contacts page in the DataWorks console. If no phone number is configured, the notification goes to the phone number of the associated Alibaba Cloud account.
DingTalk
DataWorks sends alert notifications to a DingTalk group using a custom chatbot. Enter the chatbot token in the DingTalk Robot Token field. Separate multiple tokens with commas (,).
To prevent alert notifications from being lost in a high-volume group, select the Enable checkbox for DingTalk Group Notification.
After adding a custom chatbot to a DingTalk group, configure custom keywords for the chatbot. Keywords are the only filter condition for messages. The keyword list must include DataWorks (case-sensitive). If the case is incorrect, alert notifications will not be sent.
For end-to-end setup instructions, see Send alert notifications to a DingTalk group.
Webhook URL
DataWorks sends alert notifications in text format to a webhook URL. Enter the URL in the Webhook URL field. Separate multiple URLs with commas (,).
Webhook URL alerting is available in DataWorks Enterprise Edition only.
Supported targets: WeCom and Lark.
Send alert notifications to a DingTalk group
Prerequisites
Before you begin, ensure that you have a DingTalk group where you want to receive alert notifications.
Step 1: Add a DingTalk chatbot and get a token
The steps below are based on a representative version of DingTalk and may vary slightly depending on your version.
Open the DingTalk group and click the Group Settings icon in the upper-right corner.
In the Group Settings panel, click Bot.
In the Robot Management panel, click Add Robot.
In the Robot dialog box, click Add Robot.
In the Please choose which robot to add section, click Custom.
In the Robot dialog box, click Add.
In the Add Robot dialog box, configure the following parameters.
Parameter Description Chatbot name A display name for the custom chatbot. Add to Group The DingTalk group that receives the notifications. This cannot be changed after setup. Custom Keywords Keywords used to filter messages. At least one keyword per message must match for the message to be delivered. Add DataWorks as a keyword (case-sensitive). Maximum 10 keywords. Read the terms of service, select I have read and accepted \<\<DingTalk Custom Robot Service Terms of Service\>\>, and click Finished.
After completing the security settings, copy the webhook URL of the chatbot, then click Finished.
ImportantKeep the webhook URL confidential. Exposing it puts your business at risk.
Step 2: Create an alert rule
Go to the Alarm settings page of the synchronization node. Log on to the DataWorks console. In Operation Center, go to the Real Time DI page, find the node, and click Alarm settings in the Operation column. The Alarm settings page has two tabs:
Alarm event: shows alert events that have occurred.
Alarm rules: shows existing alert rules and lets you create new ones.
On the Alarm rules tab, click New rule.
In the New rule dialog box, set the rule name and description.
For DingTalk notifications, configure the following:
Set WARNING and CRITICAL to DingTalk.
Enter the chatbot token in the DingTalk Robot Token field.
Select the Enable checkbox for DingTalk Group Notification.
For metrics, add at minimum:
Status — to monitor whether the node is running.
Business delay or Accumulated Messages — to monitor whether data transmission keeps pace with source production.
Set thresholds based on your business requirements. Alert rule settings take effect immediately after saving.
Step 3: Verify the alert rule
On the Alarm rules tab, click Test in the Operation column of the rule to confirm that alert notifications are delivered as expected.