Preview
Dynatrace non-breaking breakpoints
let the OneAgent deployed in your app know what data it needs to fetch, where to fetch it from, and what to do with it.
You set the breakpoints within the Live Debugger application by 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). You can view more information about the status by right clicking the breakpoint and selecting Status.
For more information, you can select the Breakpoint status indicator or read more about it on this page.
The following provides a summary of the breakpoint statuses:
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 fail to see any snapshots arriving, this may be due to any of the following reasons:
Incorrect Application
You are not invoking the correct line of code in the correct application instance.
Output to Integration
You are using a custom Breakpoint that sends the message to another target. (JVM) Long Running FunctionYou are using a pre-forking framework. The Dynatrace One Agent must only be loaded after forking.
(Python/JVM) 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.
(Node) Running with a Debugger
You are using the Live Debugger side-by-side with another debugger such as the WebStorm Debugger.
(Node) No Source Maps
You are using a transpiled application. Try using a minimal transpile level, or set it to a recent version of Node.js. Check out the source code section for more information
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 could not be applied as no application instance matches the current filter. This could mean one of the following:
Wrong Source File
The source file you used the set the breakpoint is not loaded in any of the applications in the current filter.
(JVM) 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. Check out the Rookout source map support section.
(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 (e.g. time limit / hit limit).
To see more information on the reason why the breakpoint was disabled, right click on the breakpoint and select status.
You can re-enable the breakpoint (by resetting the limit counter) through right clicking on the breakpoint and selecting Enable.
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 clearly documented within the IDE, but here are some of the common ones:
Warning
indicates some problems have occurred with the breakpoint, and Dynatrace is trying it's best to deliver the data you've requested.
Warning
messages are clearly documented within the IDE, but here are some of the common ones:
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 the rate limit has been hit and the breakpoint has been rate-limited for the offending application instance. Collection is sampled in order to prevent performance impact on your application. Read more about configuring rate-limiting here.
(JVM/.Net) 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.
The next time the code you set the breakpoint on is invoked, Dynatrace will collect parts of the application state and send it to the Live Debugger application or the IDE.
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. You can re-enable the breakpoint by right-clicking on it and selecting Enable.
The limits can be set based on:
Conditional breakpoints allow you to limit the data collected. 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. Setting a condition is done by right-clicking on a breakpoint and selecting the Edit option.
Condition types:
&&
for AND statement, ||
for OR statement, (
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, then the condition becomes true.
!=
a!=1
, b!='bbb'
, x!=y
If values of two operands are not equal, then condition becomes true.
-->
a>1
, x>y
If the value of left operand is greater than the value of right operand, then condition becomes true.
=-->
a>=1
, x>=y
If the value of left operand is greater than or equal to the value of right operand, then condition becomes 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 left operand is less than or equal to the value of right operand, then condition becomes true.
in
'bbb' in a
If the value of the left operand is included in the right operand, then the condition becomes true.
&&
a<=1 && b!='bbb'
If both the operands are true then condition becomes true.
||
a<=1 || b=='bbb'
If any of the two operands are non-zero then condition becomes true.
()
(a<=1``||``b=='bbb') && (x<y)
Parentheses could be used for changing the precedence when evaluating the conditio
[]
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