In a microservices architecture, a single user request often passes through multiple services. When latency spikes or errors occur, you need to know which upstream caller is sending problematic requests and which downstream dependency is slow. For example, if your order service suddenly shows high latency, upstream and downstream analysis can reveal that a payment service dependency is responding slowly, or that a specific upstream caller is sending a surge of malformed requests.
The Upstream and downstream analysis page in Application Real-Time Monitoring Service (ARMS) visualizes these call relationships for any monitored application. It ranks the top 50 callers (upstream) and callees (downstream) by three RED metrics:
| Metric | Description |
|---|---|
| Request count | Total number of requests in the selected time range |
| Error count | Number of failed requests |
| Average duration | Mean response time per request |
Both upstream and downstream views break down data at two levels: by application and by interface.
Prerequisites
An ARMS agent is installed for the application. For more information, see Application Monitoring overview.
Python applications do not support upstream and downstream analysis.
Application Monitoring provides a new application details page for users who have enabled the new billing mode.
If you have not enabled the new billing mode, click Switch to New Version on the Application List page to access the new application details page.
Open the upstream and downstream analysis page
Log on to the ARMS console.
In the left-side navigation pane, choose .
Select a region in the top navigation bar, then click an application name.
NoteIcons in the Language column indicate the programming language:
: Java
: Go
: Python- (Hyphen): an application monitored in Managed Service for OpenTelemetry
In the top navigation bar of the application details page, choose .
Understand the upstream and downstream panels
Both the Upstream (Top 50) and Downstream (Top 50) sections use the same two-row layout:
| Row | Content | Purpose |
|---|---|---|
| First row | Applications ranked by RED metrics (request count, error count, and average duration) | Identify which upstream caller or downstream dependency has the highest traffic, error rate, or latency at the application level. |
| Second row | Interfaces of those applications, ranked by the same RED metrics | Drill down from the application level to the exact interface causing issues. |
Upstream panel
The upstream panel shows which applications call yours. Use it to identify callers that send the most traffic, produce the highest error rate, or trigger the longest response times. If a single upstream application shows a disproportionately high error count, it may indicate a bug in how that caller invokes your API.
Downstream panel
The downstream panel shows which applications your application calls. Use it to spot slow or failing dependencies. A downstream service with high average duration directly impacts your application's response time. The interface-level view (second row) reveals whether the issue is isolated to a specific query endpoint or affects the service broadly.