Enable Developer Observability

Preview

Requirements

OneAgent comes with a big set of features that are activated by default. Nevertheless, you always need to explicitly activate features added by newer versions of OneAgent and opt-in features. For details see, OneAgent Features and API Configuration.

To enable Developer Observability (Live Debugger), ensure that your One Agent is up to date and deployed correctly.

Enable Developer Observability

In order to enable the Live Debugger (as part of the Developer Observability product), the environment admin needs to enable the Live Debugger feature application through:

Now you can enter the Live Debugger and select the services you would like to debug.

Additional Settings

Labels

IAM service reference

All supported values for each IAM permission and condition are listed below. Use them to define access policies based on a fine-grained set of permissions and conditions that can be enforced per service. For more information, see Working with policies.

dev-obs:breakpoints:set

Grants permission to set user-level Live Debugging breakpoints.

Conditions:

Example policies:

dev-obs:breakpoints:manage

Grants permission to manage environment-level Live Debugging breakpoints.

Example policy:

Allow managing breakpoints across the environment:

ALLOW dev-obs:breakpoints:manage;

Agent Setup

Node

Transpiled code

If your application's code is being transpiled or bundled, you must include the source maps, either in-line or as separate files.

Uglification/minification

The Live Debugger works with uglified/minified code if it's provided with source maps, however, mangling (changing of variable names) should not be applied. Webpack may automatically mangle variable names when used in production. To disable mangling in webpack, add the following to webpack.config.js:

const TerserPlugin = require("terser-webpack-plugin");
module.exports = {
    // ...
    optimization: {
        minimizer: \[new TerserPlugin({
            terserOptions: {
                mangle: false,
            },
        })],
    },
};

Integrate with your version control

When debugging within a remote environment, knowing exactly what source code it is executing is imperative.

The Live Debugger integrates with your source-control provider to fetch the correct source code for every environment (see our source code security page for more info).

Configure the following environment variables to enable automatic source code fetching:

For multiple sources, use the environment variable DT_LIVEDEBUGGER_SOURCES to initialize the SDK with information about the sources used in your application.

DT_LIVEDEBUGGER _SOURCES is a semicolon-separated list with either a source control repository and revision information, or a path on the local filesystem to a JAR file.

Applying Data Masking Rules

Dynatrace Live Debugger offers data masking rules to let you control sensitive data, giving you the ability to specify which data it should not collect and display to users.

You can set the data masking rules through the Live Debugger Settings page:

Defined rules can be reordered, and they are executed in the order in which they appear on the Sensitive data masking page.

The redacted data is replaced, by default, with the string \*\*\*.

You can choose a custom string for the rule, or replace it with a SHA-256 hash. For example, adding a rule for the variable name secretKey with a custom replacement of REDACTED replaces the output secretKey:12345 with secretKey:REDACTED.

Enable Live Debugging ActiveGate Module

To use the Live Debugger module, enable the Live Debugger ActiveGate module by setting debugging_enabled to true in the custom.properties file and then restarting ActiveGate.

If you are using a proxy, configure it within the Environment ActiveGate as described in Proxy for ActiveGate.