Conversational diagnostics require someone to start the conversation. The Task Center turns health checks and alert diagnostics into tasks that run on a schedule and sends the results to a DingTalk group. This topic describes the supported task types, how to configure a task, how to view execution history, and how to troubleshoot a failed run.
Scenarios
The Task Center is suitable for the following scenarios.
Routine health checks on production instances. For example, run a check at a fixed time every week to identify risks early.
Slow SQL governance. Generate a list of slow queries and optimization suggestions periodically to track your progress.
Alert response. After an alert is triggered, the assistant completes a diagnosis automatically so that the on-call engineer starts from a conclusion instead of raw metrics.
Pre-change and post-change verification. Run a health check manually before and after a change window, and then compare the instance status.
Supported task types
Tasks fall into two categories. Scheduled health checks run at the configured interval and are suitable for routine checks and governance. Alert diagnostics are triggered by a metric or an event and are suitable for incident response.
Task type | Description | Typical use |
Full instance health check | Runs a multi-dimensional check on an instance that covers resource usage, configurations, job status, and abnormal events. | Weekly checks, pre-change verification, and post-incident review. |
Running SQL check | Captures the SQL statements that are currently running and ranks them by resource consumption. | Quickly identify the SQL statements that are affecting your workload right now. |
Historical slow SQL check | Analyzes the slowest SQL statements in a past time window and suggests optimization directions. | Slow SQL governance and optimization review. |
Checkpoint alert | Monitors metadata issues on the frontend (FE). | Assess metadata risks and FE status. |
Compaction alert | Monitors compaction backlogs, failures, and abnormal version counts. | Identify risks in the write path and background tasks. |
Machine load alert | Monitors CPU, memory, and disk usage. | Identify resource bottlenecks and node risks. |
Routine Load alert | Monitors Routine Load ingestion jobs for errors. | Troubleshoot ingestion failures and latency. |
Materialized view alert | Monitors materialized views for refresh failures, refresh backlogs, and inactive states. | Protect query acceleration and data freshness. |
Query latency alert | Monitors abnormal query response times. | Identify latency risks that affect your workload. |
Configure a task
The Task Center contains two parts. Task Configuration defines when a task runs, which instances it checks, and where the results are sent. execution history shows the result of each run. Most of the tasks in the preceding table are built-in. In most cases, you do not need to create a task. You only adjust the configuration and enable the task.
Operations on the Task Configuration page
Operation | Description | When to use |
View a task | View the list of built-in tasks together with their status, schedule, and notification settings. | Confirm which health checks and alerts are in effect. |
Edit a task | Change the task name, model, instance scope, schedule, and notification channel. | Adjust a check plan or change the receiving group. |
Run now | Trigger a task immediately instead of waiting for the schedule. | Pre-change and post-change checks, troubleshooting, and verifying a new configuration. |
View execution history | View past results, report content, and failure causes for the task. | Review and audit. |
Enable or pause a task | Control whether the task runs on schedule. | Temporarily stop a test task or reduce alert noise. |
Procedure
Log on to the EMR console.
In the left-side navigation pane, click EMR AI Assistant, and then click .
Find the task that you want to enable and click Edit.
Configure the following parameters as needed.
Parameter
Required
Description
Task name
Yes
Identifies the task in the task list, execution history, and notification messages. We recommend that you include the environment and instance, such as "Weekly check for core production instances".
Model
Yes
The large language model that generates the report and recommendations. For the available models, see the console.
Monitored instances
Yes
The instances that the task checks. You can select one or more instances. We recommend that you configure a separate task for each core production instance. Otherwise, a single report covers multiple instances and issues are harder to locate.
Schedule
No
The interval and time at which the task runs automatically, such as 08:00 every Monday. If you leave this parameter empty, the task does not run automatically and must be triggered manually.
Notification channel
No
The instant messaging (IM) group that receives the results. You must configure the channel in IM configuration first. For more information, see EMR AI Assistant IM channel guide. If you leave this parameter empty, the task still runs, but you must view the results in execution history.
Alert tasks also require a trigger threshold, an analysis window, a TopN value, and a cooldown period. The threshold determines alert sensitivity, and the cooldown period determines how long the same issue is suppressed before it triggers another alert. For the exact parameters, see the configuration page of each task type.
Click Save.
Click Run now to trigger the task once, and then confirm that the task completes and that the notification arrives.
A manual run does not affect the existing schedule. The two are independent.
Recommended schedules and notification channels
A schedule balances timeliness against alert noise. The following table lists recommendations for common scenarios.
Scenario | Recommended schedule | Recommended channel |
Core production instances | A fixed time every day or every week | On-call group |
Other production instances | A fixed time every week | Platform operations group |
Test instances | On demand or at a low frequency | A separate test group. Do not send results to a production group. |
Major event support | A manual run before the event, and a higher frequency during the event | Dedicated support group |
Change verification | A manual run before and after the change | Change group or the change owner |
Also consider the following points.
Schedule tasks outside of peak hours for your workload and batch jobs, unless the purpose of the check is to examine the peak period.
A threshold that is too low causes alert fatigue. A threshold that is too high hides early risks. We recommend that you keep the default values for a while and then adjust them based on the actual alert volume.
Set an appropriate cooldown period so that the same issue does not trigger repeated notifications in a short time.
Check your notification channels regularly. Update the configuration after a chatbot expires or the group membership changes.
View execution history
On the execution history page, you can filter by task name or time to view the result of each scheduled, manual, or alert-triggered run. The following table describes the fields.
Field | Description | How to use it |
Task name and task type | The task that the run belongs to and its type. | Locate a record quickly when you run multiple tasks. |
Trigger type | Scheduled, manual, or alert-triggered. | Confirm that scheduled tasks run as planned. |
Start time and end time | The time window of the run. | Determine whether the task timed out or was delayed. |
Status | Successful, failed, running, or partially successful. | If the run failed, check the cause. For more information, see Troubleshoot a failed run. |
Summary and full report | The conclusions generated by EMR AI Assistant and the full report. | Start with the high-risk items in the summary, and then open the full report as needed. |
Notification status | Whether the result was sent to the IM channel. | If the notification failed, check the IM channel configuration. |
Execution history is the main data source for incident reviews, weekly reports, and governance tracking. Review it regularly to track the health trend of your instances. Validate each conclusion against your monitoring data and business context before you use it as the basis for a change.
Troubleshoot a failed run
When a task fails, check the cause in the execution history first, and then follow the guidance in the following table.
Cause | Symptom | Solution |
The instance is unavailable | The task cannot read runtime data from the instance. | Check the instance status and trigger the task again after the instance recovers. |
Insufficient permissions | The task cannot read monitoring metrics, job records, or instance configurations. | Check the account permissions. For more information, see EMR AI Assistant quick start. |
The IM channel is invalid | The task completes but the notification fails. | Check the webhook URL, the signature key, and the status of the chatbot. |
Insufficient token quota | The task stops and cannot generate a complete report. | Check the remaining quota and the billing status. For more information, see EMR AI Assistant pay-as-you-go billing. |
Incomplete configuration | No instance is selected, or a required parameter is missing. | Return to the Task Configuration page, complete the required parameters, and save the task again. |
Throttling | Too many tasks were triggered in a short period of time. | Stagger the schedules of your tasks or reduce the frequency. |
Alert handling process
After an alert is triggered, EMR AI Assistant completes a diagnosis automatically, generates an execution record, and sends the conclusion to the associated IM group. We recommend that you handle the alert as follows.
In the IM group, confirm the instance, time, and risk level of the alert.
Open the execution history, review the full report, and confirm the scope of impact.
If the conclusion requires further verification, use the corresponding expert skill in the chat window for a deeper analysis. For more information, see EMR AI Assistant expert skills overview.
Apply the remediation. Follow your change management process for any change that affects a production environment.
Review the alert and decide whether the threshold and cooldown period need adjustment, so that similar issues neither flood your group nor go unnoticed.
FAQ
What is the difference between a scheduled task and an alert task?
A scheduled task runs at a fixed interval and is suitable for routine checks and daily reports. An alert task is triggered by a metric or an event and is suitable for incident response. The results of both types are recorded in the execution history.
Can one IM channel receive results from multiple tasks?
Yes. However, we recommend that you send production alerts, routine checks, and test runs to different groups so that important messages are not buried in noise.
Can I leave the schedule empty?
Yes. For one-time checks, leave the schedule empty and use Run now to trigger the task. For continuous operations, we recommend that you configure a schedule.
Can I disable a built-in alert task?
You can pause it. However, we do not recommend that you disable a critical alert task unless another monitoring mechanism already covers the same risk.
Does a manual run affect the schedule?
No. A manual run is an independent execution, and the existing schedule remains in effect.