Tracer Debug Logs

Automated debug log collection

Automated debug logs are supported for Node.js and .NET only. For other languages, use manual debug log collection instead.

A flare allows you to send necessary troubleshooting information to the Datadog support team, including tracer logs, with sensitive data removed. Flares are useful for troubleshooting issues like high CPU usage, high memory usage, and missing spans.

Prerequisites

  • Remote Configuration must be enabled.
  • Your API key must be configured for Remote Configuration.
  • You must have a supported tracer version:
    • Java: 1.26.0 or greater
    • Python: 2.11.0 or greater
    • Node.js: 5.15.0 or greater, or 4.39.0 or greater
    • .NET: 2.46.0 or greater

Send a flare

To send a flare from the Datadog site, make sure you’ve enabled Fleet Automation and Remote Configuration on the Agent. To send a remote flare:

  1. From the Fleet Automation page, select an Agent that requires support.
  2. Click Support.
  3. Click Send Support Ticket.
  4. Provide an existing Zendesk support ticket number. If you don’t provide a ticket number, one is created on your behalf.
  5. Enable Debug mode to allow Datadog support staff to troubleshoot your issue faster. The log level is reset to its previous configuration after you send the flare.
  6. If you are troubleshooting your application, enable application tracer level logs to be included in the flare.
  7. Click Send Ticket.

For example:

The Send Ticket button launches a form to send a flare for an existing or new support ticket

Enable debug mode

Use Datadog debug settings to diagnose issues or audit trace data. Datadog does not recommend that you enable debug mode in production systems because it increases the number of events that are sent to your loggers. Use debug mode for debugging purposes only.

Debug mode is disabled by default. To enable it, follow the corresponding language tracer instructions:

To enable debug mode for the Datadog .NET Tracer, set the DD_TRACE_DEBUG configuration setting to true. This setting can be set as an environment variable, in the web.config or app.config file (.NET Framework only), or in a datadog.json file. Alternatively, you can enable debug mode by calling GlobalSettings.SetDebugEnabled(true):

using Datadog.Trace;

// enable debug mode
GlobalSettings.SetDebugEnabled(true);

Logs files are saved in the following directories by default. Use the DD_TRACE_LOG_DIRECTORY setting to change these paths.

PlatformPath
Windows%ProgramData%\Datadog .NET Tracer\logs\
Linux/var/log/datadog/dotnet/
Linux (when using Kubernetes library injection)/datadog-lib/logs
Azure App Service%AzureAppServiceHomeDirectory%\LogFiles\datadog

Note:: On Linux, you must create the logs directory before you enabled debug mode.

Since version 2.19.0, you can use the DD_TRACE_LOGFILE_RETENTION_DAYS setting to configure the tracer to delete log files from the current logging directory on startup. The tracer deletes log files the same age and older than the given number of days, with a default value of 31.

For more details on how to configure the .NET Tracer, see the Configuration section.

There are two types of logs that are created in these paths:

  1. Logs from native code: In 1.26.0 and higher, these logs are saved as dotnet-tracer-native-<processname>-<processid>.log. From version 1.21.0 to 1.25.x, these logs were saved as dotnet-tracer-native.log. In 1.20.x and older versions, this was stored as dotnet-profiler.log.
  2. Logs from managed code: In 1.21.0 and higher, these logs are saved dotnet-tracer-managed-<processname>-<date>.log. In 1.20.x and older versions, this was stored as dotnet-tracer-<processname>-<date>.log.

Review debug logs

When debug mode for your tracer is enabled, tracer-specific log messages report how the tracer was initialized and whether traces were sent to the Agent. Debug logs are stored in a separate path depending on your logging configuration. If you enable application-level tracer information, debug logs are also sent in the flare for supported languages. The following log examples show what might appear in your log file.

If there are errors that you don’t understand, or if traces are reported as flushed to Datadog but you cannot see them in the Datadog UI, contact Datadog support and provide the relevant log entries with a flare.

Logs from native code:

[dotnet] 19861: [debug] JITCompilationStarted: function_id=<function id> token=<token id> name=System.Net.Http.Headers.HttpHeaders.RemoveParsedValue()

Logs from managed code showing spans were generated:

{ MachineName: ".", ProcessName: "dotnet", PID: <process id>, AppDomainName: "test-webapi" }
YYYY-MM-DD HH:MM:SS.<integer> +00:00 [DBG] Span started: [s_id: <span id>, p_id: <parent span id>, t_id: <trace id>]
{ MachineName: ".", ProcessName: "dotnet", PID: <process id>, AppDomainName: "test-webapi" }
YYYY-MM-DD HH:MM:SS.<integer> +00:00 [DBG] Span closed: [s_id: <span id>, p_id: <parent span id>, t_id: <trace id>] for (Service: test-webapi, Resource: custom, Operation: custom.function, Tags: [<span tags>])

Logs from managed code showing traces couldn’t be sent to the Datadog Agent:

YYYY-MM-DD HH:MM:SS.<integer> +00:00 [ERR] An error occurred while sending traces to the agent at System.Net.Http.HttpRequestException: Connection refused ---> System.Net.Sockets.SocketException: Connection refused
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---

Further Reading

Additional helpful documentation, links, and articles:

PREVIEWING: hannahkm/clarify-v2-docs