When you deploy, start, scale out, or scale in an application in Enterprise Distributed Application Service (EDAS), the Change Records page tracks each step of the change process. If a change fails, use the Change Details page to identify the failed step and its root cause.
Locate the failed step
On the application details page, click Change Records in the left-side navigation pane.
A failed change shows Execution failed in the Change Status column.
Find the failed change record and click View in the Actions column.
On the Change Details page, click the failed step (for example, Deploy) in the Batch 1 Change tab. If you configured multi-batch deployment, the page displays separate tabs such as Batch 1 Change and Batch 2 Change. Click the tab for the batch that failed.
Review the log on the right side of the tab to identify the root cause.
If the log does not reveal a clear cause, check the following common failure scenarios.
Port health check failure
Symptoms
The change process fails at the health check step. Port 65000, which EDAS uses to verify that the application started, is unreachable.
Causes
Port conflict: Another process already occupies port 65000 when the application starts.
Tomcat startup failure: The Tomcat container fails to start due to a configuration or dependency error.
Solution
Check the application startup logs for exceptions. Look for errors such as
java.net.BindException: Address already in useor missing dependency errors.If a port conflict exists, stop the process that occupies port 65000 or reconfigure it to use a different port.
Fix the underlying startup error and redeploy the application.
URL health check failure
Symptoms
The change process fails at the health check step. When you configure a health check URL, EDAS sends an HTTP request to that URL after the application starts. The check passes only when it receives HTTP status code 200. If any other status code is returned within the three-minute timeout, the check fails and the deployment stops.
Causes
The application fails to start, so the health check URL is never available.
The configured health check URL is incorrect or points to a non-existent path.
A request filter, firewall rule, or security group blocks HTTP requests to the health check URL.
Solutions
Check the application startup log to confirm the application started without errors.
Verify that the health check URL path is correct and that the application serves a 200 response at that path. You can test this by running a request from the application host:
curl -I http://localhost:<port>/<health-check-path>Confirm that no request filter, firewall rule, or security group blocks inbound HTTP requests to the health check URL.
After you resolve the issue, deploy the application again.
Disk full error
Symptoms
The application remains stuck at a step in the change process for an extended period. The change log contains one of the following error messages:
The [EDAS-10000] disk has no space available.No space left on device. Free space (for /home/admin) in bytes: 0exit 1.Cause
In most cases, application business logs consume all available disk space.
Solutions
| Deployment type | Action |
|---|---|
| ECS cluster | Log on to the Elastic Compute Service (ECS) console and clear unnecessary log files from the disk. |
| Docker application in a Swarm cluster | Reset the application. This stops, deletes, and rebuilds the container, which releases the occupied disk space. |
To prevent recurrence, configure log rotation or set a retention policy for your application logs.
Missing AliyunServiceRoleForAutoScaling role
Symptoms
The change process fails because EDAS cannot call Auto Scaling to manage resources.
Cause
The service-linked role AliyunServiceRoleForAutoScaling is not assigned to your Alibaba Cloud account. This role grants Auto Scaling permissions to access Elastic Compute Service (ECS), Virtual Private Cloud (VPC), and other required services.
Solution
Assign the AliyunServiceRoleForAutoScaling role to your account in the Auto Scaling console, then retry the change.