Datadog Source Code Integration

Overview

Datadog’s source code integration allows you to connect your telemetry with your Git repositories. It allows debugging stack traces, slow profiles, and other issues by accessing the relevant lines of your source code.

Inline code snippet of a Java RuntimeException with a button to view the code in GitHub

Setup

Datadog Agent v7.35.0 or later is required.

If you have APM set up already, navigate to Integrations > Link Source Code and configure the source code integration for your backend services.

Tag your telemetry with Git information

Your telemetry must be tagged with Git information that ties the running application version with a particular repository and commit.

For supported languages, Datadog recommends embedding Git information in the deployed artifacts, which is then extracted by the Datadog Tracing Libraries automatically.

For other languages and configurations, you can configure telemetry tagging yourself.

Embed Git information in your build artifacts

You can embed the repository URL and commit hash in your build artifact. The Datadog Tracing Libraries use this information to automatically add the right tags to your APM service telemetry.

Select one of the following languages that supports embedding git information:

The Go client library version 1.48.0 or later is required.

Containers

If you are using Docker containers, you have three options: using Docker, using the Datadog tracing library, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: Datadog Tracing Library

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Option 2: Datadog Tracing Library

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, you have two options.

Option 1: Datadog Tracing Library

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

The Python client library version 1.12.0 or later is required.

Containers

If you are using Docker containers, you have three options: using Docker, using the Datadog tracing library, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: Setuptools or Unified Python Project Settings File

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Option 2: Setuptools or Unified Python Project Settings File

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, you have two options.

Option 1: Setuptools or Unified Python Project Settings File

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

The .NET client library version 2.24.1 or later is required.

As a first step, ensure that your .pdb files are deployed alongside your .NET assemblies (.dll or .exe) in the same folder. Then, follow the rest of the instructions based on your specific deployment model:

Containers

If you are using Docker containers, you have three options: using Docker, using Microsoft SourceLink, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 3: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, you have two options: using Microsoft SourceLink or configuring your application with DD_GIT_* environment variables.

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

The NodeJS client library version 3.21.0 or later is required.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, configure your application with DD_GIT_* environment variables.

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

The Ruby client library version 1.6.0 or later is required.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with the DD_TAGS environment variable.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_TAGS="git.repository_url:${DD_GIT_REPOSITORY_URL},git.commit.sha:${DD_GIT_COMMIT_SHA}"
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_TAGS Environment Variable

Configure your application with the DD_TAGS environment variable:

export DD_TAGS="git.commit.sha:<commitSha>,git.repository_url:<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Option 2: DD_TAGS Environment Variable

Configure your application with the DD_TAGS environment variable:

export DD_TAGS="git.commit.sha:<commitSha>,git.repository_url:<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, configure your application with the DD_TAGS environment variable.

Configure your application with the DD_TAGS environment variable:

export DD_TAGS="git.commit.sha:<commitSha>,git.repository_url:<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

The Java client library version 1.12.0 or later is required.

If you are using Docker containers, you have two options: using Docker or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Add the following arguments to your Docker build command:

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Datadog CLI tool
Use the datadog-ci client version 2.4.1 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.18.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Option 2: DD_GIT_* Environment Variables

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Host

If you are using a host, configure your application with DD_GIT_* environment variables.

Configure your application with the DD_GIT_* environment variables:

export DD_GIT_COMMIT_SHA="<commitSha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Build inside a Docker container

If your build process is executed in CI within a Docker container, perform the following steps to ensure that the build can access Git information:

  1. Add the following text to your .dockerignore file. This ensures that the build process is able to access a subset of the .git folder, enabling it to determine the git commit hash and repository URL.

    !.git/HEAD
    !.git/config
    !.git/refs
    
  2. Add the following line of code to your Dockerfile. Ensure that it is placed before the actual build is ran.

    COPY .git ./.git
    

Configure telemetry tagging

For unsupported languages, use the git.commit.sha and git.repository_url tags to link data to a specific commit. Ensure that the git.repository_url tag does not contain protocols. For example, if your repository URL is https://github.com/example/repo, the value for the git.repository_url tag should be github.com/example/repo.

Synchronize your repository metadata

To link your telemetry with source code, your repository metadata must be synchronized to Datadog. Datadog doesn’t store the actual content of files in your repository, only the Git commit and tree objects.

Git providers

The source code integration supports the following Git providers:

ProviderContext Links SupportCode Snippets Support
GitHub SaaS (github.com)YesYes
GitHub Enterprise ServerYesYes
GitLab SaaS (gitlab.com)YesYes
GitLab self-managedYesNo
BitbucketYesNo
Azure DevOps ServicesYesNo
Azure DevOps ServerYesNo

Install Datadog’s GitHub integration on the GitHub integration tile to allow Datadog to synchronize your repository metadata automatically. When specifying permissions on the integration tile, select at least Read permissions for Contents.

Setting up the GitHub integration also allows you to see inline code snippets in Error Tracking, Continuous Profiler, Serverless Monitoring, CI Visibility, and Application Security Monitoring.

Repositories from self-managed GitLab instances are not supported out-of-the-box by the source code integration. To enable this feature, contact Support.

To link telemetry with your source code, upload your repository metadata with the datadog-ci git-metadata upload command.

When you run datadog-ci git-metadata upload within a Git repository, Datadog receives the repository URL, the commit SHA of the current branch, and a list of tracked file paths.

Run this command for every commit that you need to be synchronized with Datadog.

If you are using gitlab.com, this also allows you to see inline code snippets in Error Tracking, Continuous Profiler, Serverless Monitoring, CI Visibility, and Application Security Monitoring.

Validation

To ensure the data is being collected, run datadog-ci git-metadata upload in your CI pipeline.

You can expect to see the following output:

Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@my-git-server.com:my-org/my-repository.git.
180 tracked file paths will be reported.
✅  Handled in 0.077 seconds.
Repositories on self-hosted instances or private URLs are not supported out-of-the-box by the source code integration. To enable this feature, contact Support.

To link telemetry with your source code, upload your repository metadata with the datadog-ci git-metadata upload command.

When you run datadog-ci git-metadata upload within a Git repository, Datadog receives the repository URL, the commit SHA of the current branch, and a list of tracked file paths.

Run this command for every commit that you need to be synchronized with Datadog.

Validation

To ensure the data is being collected, run datadog-ci git-metadata upload in your CI pipeline.

You can expect to see the following output:

Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@my-git-server.com:my-org/my-repository.git.
180 tracked file paths will be reported.
✅  Handled in 0.077 seconds.

Usage

You can see links from stack frames to their source repository in Error Tracking.

  1. Navigate to APM > Error Tracking.
  2. Click on an issue. The Issue Details panel appears on the right.
  3. Under Latest Event, click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.
A view repository button with three options (view file, view blame, and view commit) available on the right side of an error stack trace in Error Tracking, along with inline code snippets in the stack trace

If you’re using the GitHub integration, or if you’re hosting your repositories on the GitLab SaaS instance (gitlab.com), click Connect to preview on stack frames. You can see inline code snippets directly in the stack trace.

You can see a source code preview for profile frames in the Continuous Profiler.

  1. Navigate to APM > Profile Search.
  2. Hover your cursor over a method in the flame graph.
  3. If needed, press Opt or Alt to enable the preview.
Source code preview in the Continuous Profiler

You can also see links from profile frames to their source repository. This is supported for profiles broken down by line, method, or file.

  1. Navigate to APM > Profile Search.
  2. Hover your cursor over a method in the flame graph. A kebab icon with the More actions label appears on the right.
  3. Click More actions > View in repo to open the trace in its source code repository.
Link to GitHub from the Continuous Profiler

You can see links from errors in your Lambda functions’ associated stack traces to their source repository in Serverless Monitoring.

  1. Navigate to Infrastructure > Serverless and click on the AWS tab.
  2. Click on a Lambda function and click the Open Trace button for an invocation with an associated stack trace.
  3. Click View Code to open the error in its source code repository.

If you’re using the GitHub integration, click Connect to preview on error frames. You can see inline code snippets directly in the Lambda function’s stack trace.

You can see links from failed test runs to their source repository in Test Visibility.

  1. Navigate to Software Delivery > Test Visibility > Test Runs and select a failed test run.
  2. Click the View on GitHub button to open the test in its source code repository.
Link to GitHub from the CI Visibility Explorer

For more information, see Enhancing Developer Workflows with Datadog.

You can see links from failed Static Analysis and Software Composition Analysis scans to their source repository in Code Analysis.

  1. Navigate to Software Delivery > Code Analysis and select a repository.
  2. In the Code Vulnerabilities or Code Quality view, click on a code vulnerability or violation. In the Details section, click the View Code button to open the flagged code in its source code repository.
Link to GitHub from the Code Analysis Code Vulnerabilities view

For more information, see the Code Analysis documentation.

You can see links from errors in your security signals’ associated stack traces to their source repository in Application Security Monitoring.

  1. Navigate to Security > Application Security and select a security signal.
  2. Scroll down to the Traces section on the Related Signals tab and click on an associated stack trace.
  3. Click View Code to open the error in its source code repository.

If you’re using the GitHub integration, click Connect to preview on error frames. You can see inline code snippets directly in the security signal’s stack trace.

Link to GitHub from Application Security Monitoring

Further Reading