Enterprise Distributed Application Service (EDAS) provides automatic fault diagnostics for your applications. On the Application Overview page, you can customize a time range for a diagnostics test. The diagnostics model analyzes application metrics within the specified time range, identifies root causes, and generates reports with supporting evidence.
When the diagnostics model detects an anomaly within the specified time range, a red shield icon 
appears on the Application Overview page. Click the icon to open the diagnostics report.
How automatic diagnostics works
The EDAS diagnostics model evaluates application health by monitoring response time, error rates, host resource usage, and network connectivity. When it detects a deviation from normal behavior, it:
Identifies the fault symptom (for example, a sudden response time spike or elevated error rate).
Traces causal dependencies across services, nodes, and infrastructure.
Infers the root cause by correlating symptoms with recent changes, downstream dependencies, and resource metrics.
Generates a diagnostics report that links the symptom to the root cause with supporting data.
This approach surfaces not just *what* went wrong, but *why* it happened, so you can act on the root cause rather than the symptom.
Detected fault scenarios
The diagnostics model covers four categories of anomalies.
Sudden response time (RT) increase
The diagnostics model identifies what caused the RT spike and traces it to the source:
| Cause | What the report shows | Recommended action |
|---|---|---|
| Downstream dependency | The specific downstream service that is responding slowly | Contact the downstream service owner |
| Recent application change | The application change that introduced the latency | Review the specific changes |
| Service-level issue | The degraded service within the application | Check whether the service has active exceptions, whether a downstream service has elevated RT, or whether an upstream caller has high latency |
| Single-node infrastructure problem | The affected node and resource metrics | Check the thread pool (a thread count time series chart is included), full garbage collection (GC), disk read and write errors, or out-of-memory (OOM) events on the node |
High error rate
| Cause | What happens | Recommended action |
|---|---|---|
| Service error spike | Error requests for a specific service suddenly increase, raising the overall error rate | Investigate the failing service and its recent changes |
| Serialization overhead | A large number of requests and responses that occur in a specific period account for a high proportion, causing serialization and deserialization to consume a long time | Review the request and response payload sizes during the affected period |
Host overload
Excessive load on a host degrades the container's ability to serve traffic. Check the resource utilization on the affected host and determine whether to scale out or redistribute workloads.
Network failure
A network failure within the data center causes an application exception at runtime. Investigate network connectivity in the affected data center.
View a diagnostics report
Log on to the EDAS console.
In the left-side navigation pane, choose Application Management > Applications.
In the top navigation bar, select a region. In the upper part of the page, select a namespace.
From the Cluster Type drop-down list, select Container Service or Serverless Kubernetes Cluster.
Find the target application and click its name.
On the Overview tab of the Application Overview page, specify a time range in the upper-right corner.
ImportantIf the diagnostics model detects an anomaly within the specified time range, a red shield icon
appears to the right of the application name. The absence of this icon means no anomalies were detected in the selected time range -- it does not guarantee that the application has no issues.Click the red shield icon
to the right of the application name.Review the fault symptom and root cause analysis in the diagnostics report.
Interpret the diagnostics report
Each diagnostics report progresses from summary to evidence across four sections:
| Section | Contents | How to use it |
|---|---|---|
| Diagnostics details | The diagnosed application, diagnostics timestamp, and fault symptom | Confirm the scope: which application and time window the report covers |
| Fault definition | The shallow causes of application failures inferred by the diagnostics model. In most cases, the following three causes are included | Identify what directly triggered the failure. Typical definitions: an instance error causes an overall failure, an API or service error causes an overall failure, or a downstream application failure causes a failure of the application |
| Root cause analysis | The deep causes inferred by the diagnostics model | Pinpoint the deeper trigger behind the fault definition. Root causes vary by scenario, such as a recent change, a resource bottleneck, or a downstream degradation |
| Data support | Metrics, charts, and logs that substantiate the inference | Validate the analysis. Supporting data varies by fault type: thread count charts for thread pool issues, error rate trends for service errors, or resource graphs for host overload |
Read the report as a causal chain
The four sections form a causal chain: Diagnostics details (what happened) -> Fault definition (shallow cause) -> Root cause analysis (deep cause) -> Data support (evidence). Start from the symptom, then follow the chain to the root cause and verify it with the data.
Figure 1. Sample fault diagnostic report: RT diagnosis
Take action after diagnosis
After reviewing a diagnostics report, take action based on the identified root cause:
| Fault scenario | Recommended action |
|---|---|
| Downstream service degradation | Contact the downstream service owner for troubleshooting |
| Recent application change | Review the specific changes that caused the performance regression |
| Service-level exception | Check for exceptions in the affected service, and verify RT of its upstream and downstream services |
| Single-node issue (full GC, OOM, disk error) | Check the thread pool, GC activity, disk status, and memory usage on the affected node |
| Host overload | Investigate the resource load on the host and scale out or redistribute traffic |
| Network failure | Investigate the network connectivity in the data center that caused the exception |