Access to this feature depends on your subscription level.
Trace details page functions
View the Trace details page by selecting a transaction trace. For more on how to find a transaction trace, see Transaction traces in UI.
The Trace details page displays a table with the timing data for the segments in a transaction.
Here are the major features and functions of the Trace details page and table:
|Primary trace data, functions||
At the top of all transaction trace UI pages are several primary pieces of data, including the trace time, response time, and, if available, CPU info.
Available functions include:
There may sometimes be a note that the trace is a partial trace. For more info, see Partial traces.
The duration of each segment and subsegment is shown as both the number of milliseconds and a percentage of the total transaction time. Especially slow segments are color-coded.
The Segment column displays segment names and counts. Fast and repeat calls may be automatically grouped together. To expand segments, use either of the following:
You may sometimes see Application code as the name of a segment or subsegment. See Application code for more information.
The Drilldown column may contain icons that link to additional transaction data, if available. See Drilldown options for more information.
The Timestamp column displays the start time of a segment or subsegment, relative to the start of the transaction. For example, a value of
In the Drilldown column, various icons indicate that additional data is available:
|Database queries||The database [database icon] icon links to the raw database query for that query segment. Depending on your transaction trace settings, this query can either show as raw data or obfuscated data. If the total time for the segment exceeds the query plan threshold in your settings, the query analysis also will appear, along with a stack trace showing the exact location of the call in your code.|
|Stack traces||The magnifying glass [magnifying glass icon] links to stack trace details.|
|Cross app traces||This icon links to cross application trace details. If your agent supports the cross application tracing map feature, you can select the transaction trace Map page in the UI.|
|Aggregate transaction details||This icon indicates that cross application tracing details are not available. However, you can select this icon to view aggregated transaction information across multiple invocations of the transaction.|
Color coding of segment duration data
The Duration column of the Trace details table is color-coded:
- Red: More than 25% of the total transaction time was spent in this segment.
- Yellow: More than 5% of the total transaction time was spent in this segment.
Color-coded durations do not necessarily indicate a problem. Whether the timing is actually a problem depends on what you consider normal and acceptable for your application.
Application code in traces
If a segment is listed as Application code in the table, it indicates that that section of code was not instrumented. You can use custom instrumentation to get more detail on that part of the code. Segments will often be listed as Application code for partial traces.
You may sometimes see a note at the top of the Details page that says:
This is a partial trace. For performance reasons, New Relic APM only captures the first 2000 segments of a transaction trace (900 for Node.js). If a transaction trace exceeds that number of segments, the agent truncates the transaction trace and displays this message.
The New Relic agents have differing rules for when to truncate segments. Here are a few important differences:
- Java, .NET, and Ruby: These agents truncate traces chronologically.
- Node.js: See Node.js agent configuration.
- PHP: This agent truncates traces based on priority, with database and memcache calls having highest priority. After those have all been captured, the agent records the slowest functions or methods.
Segment grouping rules
Transaction traces that have a lot of segments can be hard to interpret. New Relic helps you by automatically grouping fast and/or repeated method calls into a single segment grouping.
For example, you might see a segment titled
7 fast method calls. This means that, because of their fast completion, New Relic assumed these calls were unlikely to be a problem and grouped them together. You can expand that grouping to see the individual segments.
Rules underlying segment grouping include:
- Fast calls: When New Relic detects four or more consecutive segments with a duration of 7.5 ms or less, these are grouped into a single collapsed header.
- Identical calls: When New Relic detects four or more consecutive identical calls, this usually indicates an N+1 problem. These segments are collapsed. Expanding the collapsed node displays only the first three calls, not all calls.