Latest Dynatrace
Dynatrace non-breaking breakpoints
allow the OneAgent deployed in your application to fetch data from any place in your code, allowing you to observe the current state of your application to quickly find bugs in production without stopping your application.
To breakpoints within the Live Debugger application, left-clicking on the gutter, just like in your own IDE.
Once you set a non-breaking breakpoint, it will have a status associated with it (Active, Pending, Disabled, Error, or Warning). To view more information about the status, right-click the breakpoint and select Status.
For more information, you can select the Breakpoint status indicator or read more about it on this page.
Expand any of the following for a summary of a breakpoint status:
Active
status occurs when one of or more of your applications has applied the breakpoint and no errors have been reported.
In most cases, once the breakpoint has transitioned to active, you will see snapshots collected the next time the line is executed.
If you don't see any snapshots arriving, this may be due to any of the following reasons:
Incorrect Application
You aren't invoking the correct line of code in the correct application instance.
Long Running Function
You have placed a breakpoint on a long-running function. In this runtime, breakpoints are only applied for function calls performed after the breakpoint was created.
Pending
status indicates that the breakpoint has not been applied to any of your applications. This could mean one of the following:
No Application instances
The breakpoint couldn't be applied because no application instance matches the current filter. This could mean one of the following:
Wrong Source File
The source file you used to set the breakpoint isn't loaded in any of the applications in the current filter.
No Code
You have set the breakpoint on a line that has no executable code associated with it.
(JVM) No Debug Information
You have compiled your classes without debug information. Select here for more information.
(Node) No Source Maps
You are using a transpiled application without including source maps. Try using a minimal transpilation level, or make sure to add source maps to your deployed application. Check out the source code section for more information.
(Node) Code is in a Dependency
You are debugging a package deployed as a dependency. This requires setting up your source repository accordingly.
(Node) Different File Layout
File paths are changed between source repository and deployment. This requires setting up your source repository accordingly.
Disabled
status occurs when the breakpoint was disabled due to limits. These include limits applied by the user for that specific breakpoint (for example, time limit, hit limit).
Error
status occurs when one of or more of your applications has reported an error in processing, applying, or executing the breakpoint.
Error
messages are documented within the Live Debugger application or IDE, but examples include:
Warning
indicates some problems have occurred with the breakpoint, and Dynatrace is trying its best to deliver the data you've requested.
Warning
messages are documented within the Live Debugger application or IDE, but examples include:
Breakpoint collection is sampled due to rate-limiting
Dynatrace employs a built-in rate-limiting mechanism to prevent breakpoints set in hot code paths from impacting application performance. This error indicates that the rate limit has been hit and the breakpoint has been rate-limited for the offending application instance. Collection is sampled to prevent performance impact on your application.
(JVM) Source file not found
Dynatrace relies on source file hashing to ensure you are debugging the correct version of the files you are trying to debug. In most JVM based languages, include your source within your Jar/War/Ear archives.
The next time the code on which you set the breakpoint is invoked, Dynatrace will collect parts of the application state and send it to the Live Debugger application or the IDE.
There are several collection levels that you can set to a breakpoint. The collection levels set three different values:
Three collection levels are available:
Level\Language
JVM
Node.js
Low
Collection depth: 2
String width: 128
Collection width: 10
Collection depth: 2
String width: 128
Collection width: 5
Medium
Collection depth: 5
String width: 512
Collection width: 15
Collection depth: 3
String width: 512
Collection width: 10
High
Collection depth: 8
String width: 4096
Collection width: 25
Collection depth: 5
String width: 4096
Collection width: 20
For example, if an object has a deeply nested field, we will stop when we reach the maximum collection depth (as in the following example). Note that l5
has more fields, but they weren’t collected because they were too deep.
You can set limits on individual breakpoints to limit the amount of data that will be collected. When limits are reached, the breakpoint will be automatically disabled. Once disabled, it will not collect additional data. To re-enable a breakpoint, right-click it and select Enable.
The limits can be set based on:
Breakpoint default limit values:
Conditional breakpoints allow you to limit the data collected by the agent. You will only collect data when the defined expression evaluates as true. This makes it possible to debug specific scenarios and limit the number of messages you receive. To set a condition, right-click a breakpoint and select Edit.
Condition types:
&&
for an AND statement, ||
for an OR statement, and (
and )
for encapsulation.Advanced conditions support the following operators and functions:
Operator
Example
Description
==
a==1
, b=='bbb'
, x==y
If the values of two operands are equal, the condition is true.
!=
a!=1
, b!='bbb'
, x!=y
If values of two operands are not equal, the condition is true.
>
a>1
, x>y
If the value of the left operand is greater than the value of the right operand, the condition is true.
>=
a>=1
, x>=y
If the value of the left operand is greater than or equal to the value of the right operand, the condition is true.
<
a<1
, x<y
If the value of left operand is less than the value of right operand, then condition becomes true.
<=
a<=1
, x<=y
If the value of the left operand is less than or equal to the value of the right operand, the condition is true.
in
'bbb' in a
If the value of the left operand is included in the right operand, the condition is true.
&&
a<=1 && b!='bbb'
If both operands are true, the condition is true.
||
a<=1 || b=='bbb'
If any of the two operands are non-zero, the condition is true.
()
(a<=1``||``b=='bbb') && (x<y)
You can use parentheses to change the precedence when evaluating the condition.
[]
arr[4]!=4
, dict['a']!=4
Set conditions regarding to a specific sequence’s element - list, dict, etc.
size
arr.size() >= 32
Use size instead of len or length on any platform.