Distributed Traces Classic provides you with a combination of analysis tools to gain insight into your environment's transactions. It combines code-level visibility, topology information, and metadata with the highest level of data granularity and fidelity. In this article, you'll explore the Distributed Traces Classic functionalities and how to leverage them to analyze requests in your environment.
To get started with a distributed trace analysis
The chart uses trace and request data, which has different data retention periods. For timeframes containing data older than 10 days, you can turn on the Show data retention toggle to better understand which data is available for which period directly from the chart.
To configure a view of the distributed traces in your environment
Go to Distributed Traces or Distributed Traces Classic (latest Dynatrace).
Configure a view by setting filters. To filter the distributed traces by
Ingestion method
Service
Go to Filter requests > Service name and enter the service name. Note that you can access this view also by going to Services > More (…) > Distributed traces for the service.
You can export the distributed traces overview table data in a comma-separated values (CSV) file.
Go to Distributed Traces or Distributed Traces Classic (latest Dynatrace).
optional Narrow down the table results by reconfiguring your view or via the search input field above the table.
The table lists up to the 3,000 most recent traces that are captured during the selected timeframe and within the selected management zone. Depending on the timeframe and the configured view, the list highlights the most important node for the trace.
To find a specific node of a trace
In the lower-right corner of the page, select the Show export menu.
Select one of the following options.
Option | Exported data | Fields | Number of entries |
---|---|---|---|
Export visible data | The currently displayed area of the table, taking into account applied filters | Only visible fields | Up to 50 traces |
Export table data | All table data, including traces that are not displayed on the current table page | All the available fields related to distributed traces | All 3,000 most recent traces |
The distributed trace analysis view provides an end-to-end waterfall visualization of the requests in a single trace.
To access the single trace view
Go to Distributed Traces or Distributed Traces Classic (latest Dynatrace).
From the table, select the distributed trace name.
optional Go to the Execution breakdown to learn the trace time distribution.
Go to the waterfall chart to learn which services are traversed by the trace and in which order.
Select a request to visualize subsequent interactions.
Use the colors and positions of the horizontal bars in the chart to see which requests were executed synchronously (in parallel). They indicate both the sequence and response time of each of the requests.
Select a time segment to access in-depth trace analytics in detail tabs, down to code-level information.
Choose a detail tab to continue your analysis.
Availability | default |
Content | Includes details on metadata, request headers, request parameters, and information about the proxy through which the request was sent. |
Values obscured with five asterisks (*****
) imply hidden confidential data, which can be unmasked by users with sufficient permissions. Three or fewer asterisks (***
) are used for data aggregation purposes and can't be unmasked.
Availability | default |
Content | Timing-specific details of services. Select View method hotspots for more details on timing contributions (for example, CPU, wait, sync, lock, and execution time). |
Example | The example above shows timing details for the |
Availability | OneAgent required depends on data input 1 |
Content | Comprehensive code execution of each and every request, including the code-level method executions and their timings, in the exact sequence of events. |
Example | In the example above, Dynatrace tells you exactly which method in the |
The volume of code-level information varies depending on importance, timing, and estimated overhead. Typically, slower parts of a request contain more details.
Availability | Log enrichment required depends on data input1 |
Content | Log records in the full context of the transaction. All available span IDs are included by default.
|
Example |
To get started, see Log enrichment.
Availability | depends on data input |
Content | Occurring exceptions for failed requests. |
Example |
Availability | OneAgent required depends on service type |
Availability | depends on service type |