Developer Observability breakpoints

Temporary table of contents for Developer Observability

Preview

Non-breaking Breakpoints

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.

Setting Breakpoints

You set the breakpoints within the Live Debugger application by left clicking on the gutter, just like in your own IDE.

Breakpoint Status

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:

    • The Dynatrace One Agent has not been installed.
    • The Dynatrace One Agent has been installed, but the application cannot connect to the Dynatrace service.
    • The application can connect to the Dynatrace service, but is excluded by the current filter definition.
    • The application is a serverless application, that only spins up on demand.

  • 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:

  • Source file has changed
    Dynatrace verifies that the source file you are seeing in our IDE is the file you are deploying in your application. If the file version is wrong (detected using a Hash calculation) the breakpoint will not be set. If you use source commit detection you will see the correct git commit to use on the App instances page.

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.

    • In most JVM based languages, please include your source within your Jar/War/Ear archives. Read more about it on our setup page.
    • In most .Net based languages, please embedded sources into your pdb. Read more about it on our setup page.
    • (Node) Original Source Files are Missing
      Dynatrace relies on source file hashing to ensure you are debugging the correct version of the files you are trying to debug. For transpiled JS/TS/CS, please deploy your original sources side-by-side with the transpiled ones or include sources within the source map. Read more about it on our setup page.
    • Attribute Not Found
      There is an invalid key in the breakpoint condition or collection configuration. For more information select here.
    • Method Not Found
      Your are trying to use an unsupported method in condition configuration. Please check the supported methods.
    • Key Not Found
      There is an invalid key in the breakpoint condition or collection configuration. For more information select here.

Data Collection

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.

Breakpoint Limits

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:

  • Time (for example, 1 Hour, 24 hours, a week)
  • Hit count (the number of times the breakpoint gets triggered)

Breakpoint Conditions

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:

  • Simple Conditions
    Using a simple condition, we can compare a variable with some value (or another variable).
  • Advanced Conditions
    Using an advanced condition, we can define a more complex condition using logical parameters. Use && 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