Overview

Dynamic instrumentation allows you to add instrumentation into your running production systems without any restarts and at any location in your application’s code, including third-party libraries. You can add or modify telemetry for logs, metrics, spans, and corresponding tagging, from the Datadog UI. Dynamic Instrumentation has low overhead and has no side effects on your system.

If you are interested in trying out the latest user experience improvements for Dynamic Instrumentation, consider opting into the autocomplete and search public beta.

Getting started

Prerequisites

Dynamic Instrumentation requires the following:

• Datadog Agent 7.45.0 or higher is installed alongside your service.
• Remote Configuration is enabled in that Agent.
• For Java applications, tracing library dd-trace-java 1.34.0 or higher.
• For Python applications, tracing library dd-trace-py 2.2.0 or higher.
• For .NET applications, tracing library dd-trace-dotnet 2.54.0 or higher.
• For PHP applications, tracing library dd-trace-php 1.4.0 or higher.
• Unified Service Tagging tags service, env, and version are applied to your deployment.
• Recommended, autocomplete and search (open beta) is enabled.
• Recommended, Source Code Integration is set up for your service.
• The Dynamic Instrumentation Read Configuration (debugger_read) permission is required to access the Dynamic Instrumentation page
• The Dynamic Instrumentation Write Configuration (debugger_write) permission is required to create or modify instrumentations.
• The Dynamic Instrumentation Capture Variables (debugger_capture_variables) permission is required to use the Capture method parameters and local variables option.

For more information about roles and on how to assign roles to users, see Role Based Access Control.

Create a logs index

Dynamic Instrumentation creates “dynamic logs” that are sent to Datadog and appear alongside your regular application logs.

If you use Exclusion filters, ensure Dynamic Instrumentation logs are not filtered:

1. Create a logs index and configure it to the desired retention with no sampling.
2. Set the filter to match on the source:dd_debugger tag. All Dynamic Instrumentation logs have this source.
3. Ensure that the new index takes precedence over any other with filters that match that tag, because the first match wins.

Enable Dynamic Instrumentation

To enable Dynamic Instrumentation on a service, go to the in-app setup page.

For more detailed instructions, select your runtime below:

Limitations

• Dynamic Instrumentation is not yet compatible with Azure App Services or serverless environments.
• Support is limited to applications built with Python, Java, .NET and PHP.

Explore Dynamic Instrumentation

Dynamic Instrumentation can help you understand what your application is doing at runtime. By adding a Dynamic Instrumentation probe you are exporting additional data from your application, without the need to change code or redeploy it.

Using probes

A probe allows you to collect data from specific points in your code without halting the execution of the program.

Think of using probes as enhancing your observability by adding dynamic logs, metrics, and spans to a running application without needing to change code, deploy it, or restart a service. You can gather data immediately without disturbing the user experience or requiring lengthy deployments.

As a developer, you can also think of a probe as a “non-breaking breakpoint”. In traditional debugging, a breakpoint is a point in the program where the execution stops, allowing the developer to inspect the state of the program at that point. However, in real-world production environments, it’s not practical or even possible to stop the execution of the program. Probes fill in this gap by allowing you to inspect variable state in production environments in a non-intrusive way.

Creating a probe

All probe types require the same initial setup:

1. Go to the Dynamic Instrumentation page.
2. Click Create Probe in the top right, or click the three-dot menu on a service and select Add a probe for this service.
3. If they are not prefilled, choose service, runtime, environment, and version.
4. In the source code, specify where to set the probe by selecting either a class and method or a source file and line. If you opted into the autocomplete and search public beta, autocomplete shows suggestions for selecting a class or method.

See the individual probe types below for specific creation steps for each probe type.

Alternatively, you can create a probe from these other contexts:

Profiling

On a profiler flame graph, you can create a probe for a method by selecting Instrument this frame with a probe from the frame’s context menu.

Error Tracking

On a stack trace, mouse over a stack frame and click Instrument. This prefills the probe creation form with the Issue context.

Creating log probes

A log probe emits a log when it executes.

To create a log probe:

1. Select Log as the probe type.
2. Complete the generic probe setup (choose service, environment, version, and probe location).
3. Define a log message template. You can use the Dynamic Instrumentation expression language to reference values from the execution context.
4. Optionally enable extra data capturing from the probe. (Beta)
5. Optionally define a condition using the Dynamic Instrumentation expression language. The log is emitted when the expression evaluates to true.

Log probes are enabled by default on all service instances that match the specified environment and version. They are rate-limited to execute at most 5000 times per second, on each instance of your service.

You must set a log message template on every log probe. The template supports embedding expressions inside curly brackets. For example: User {user.id} purchased {count(products)} products.

You can also set a condition on a log probe using the expression language. The expression must evaluate to a Boolean. The probe executes if the expression is true, and does not capture or emit any data if the expression is false.

Beta: If you enable Capture method parameters and local variables on the log probe, all execution context is added the log event:

• Method arguments, local variables, and fields, with the following default limits:
  • Follow references three levels deep (configurable in the UI).
  • The first 100 items inside collections.
  • The first 255 characters for string values.
  • 20 fields inside objects. Static fields are not collected.
• Call stack trace.
• Caught and uncaught exceptions.

Probes with this setting enabled are rate-limited to one hit per second.

Creating metric probes

A metric probe emits a metric when it executes.

To create a metric probe:

1. Select Metric as the probe type.
2. Complete the generic probe setup (choose service, environment, version, and probe location).
3. Specify a name for the metric, which will be prefixed with dynamic.instrumentation.metric.probe..
4. Select a metric type (count, gauge, or histogram).
5. Choose the value of the metric using the Dynamic Instrumentation expression language. You can use any numeric value you’d like from the execution context, such as a method parameter, local variable, a class field, or an expression that yields a numeric value. For count metrics this is optional, and if you omit it, every invocation increments the count by one.

Metric probes are automatically enabled on all service instances that match the configured environment and version. Metric probes are not rate limited and execute every time the method or line is invoked.

Dynamic Instrumentation metric probes support the following metric types:

• Count: Counts how many times a given method or line is executed. Can be combined with metric expressions to use the value of a variable to increment the count.
• Gauge: Generates a gauge based on the last value of a variable. This metric requires a metric expression.
• Histogram: Generates a statistical distribution of a variable. This metric requires a metric expression.

Creating span probes

A span probe emits a span when a method is executed.

To create a span probe:

1. Select Span as the probe type.
2. Complete the generic probe setup (choose service, environment, version, and probe location).

You can use a span probe as an alternative to creating new spans with Custom Instrumentation. If the method throws an exception, the details of the exception are associated with the newly created span’s error tag.

Creating span tag probes

A span tag probe adds a tag value to an existing span. You can add a tag either to the active span or to the service entry span. Keep in mind that internal spans are not indexed by default and so might not be searchable in APM.

To create a span tag probe:

1. Select Span Tag as the probe type.
2. Complete the generic probe setup (choose service, environment, version, and probe location).
3. Specify a name for the tag.
4. Specify the value of the tag using the Dynamic Instrumentation expression language.
5. Optionally define a condition using the Dynamic Instrumentation expression language. The tag will only be added when the expression evaluates to true.
6. Optionally add additional tags, each with their own name, expression, and optional condition.

You can use a span tag probe as an alternative to using Custom Instrumentation to add tags in code.

Further Reading

Additional helpful documentation, links, and articles:

Learn more about the Dynamic Instrumentation Expression LanguageDOCUMENTATION Removing sensitive information from your Dynamic Instrumentation dataDOCUMENTATION Learn more about how to instrument your applicationDOCUMENTATION Unified Service TaggingDOCUMENTATION Discover and catalog the services reporting to DatadogDOCUMENTATION Learn more about MetricsDOCUMENTATION Use Datadog Dynamic Instrumentation to add application logs without redeployingBLOG