Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

Compatibility requirements

The Go Tracer requires Go 1.18+ and Datadog Agent >= 5.21.1. For a full list of Datadog’s Go version and framework support (including legacy and maintenance versions), see the Compatibility Requirements page.

Getting started

Before you begin, make sure you’ve already installed and configured the Agent.

There are two ways to instrument your Go application:

  1. Compile-time instrumentation:

    • Ensures maximum coverage of your tracing instrumentation.
    • Does not require source code modifications, making ideal for integrating at the CI/CD level.
  2. Manual instrumentation:

    Use dd-trace-go in conjunction with our integration packages to automatically generate spans about libraries of your choosing. This option:

    • Gives you complete control over which parts of your application are traced.
    • Requires modifying the application’s source code.

Refer to the instructions in the section corresponding to your preference below:

Overview

Orchestrion automatically adds instrumentation to Go applications during compilation, eliminating the need for code changes. It provides comprehensive tracing coverage and enables exclusive security features:

  • Comprehensive tracing coverage:
    • Instruments your code and all dependencies, including the Go standard library
    • Instruments your code during compilation, preventing gaps in tracing coverage due to overlooked manual instrumentation
  • Exclusive Application Security Management Exploit Prevention feature. Exploit Prevention is a Runtime Application Self-Protection (RASP) implementation and includes RASP methods such as Local File Inclusion (LFI).

Requirements

Install Orchestrion

To install and set up Orchestrion:

  1. Install Orchestrion:

    go install github.com/DataDog/orchestrion@latest
    
    Note: Ensure that $(go env GOBIN) or $(go env GOPATH)/bin is in your $PATH.
  2. Register Orchestrion in your project’s go.mod:

    orchestrion pin
    

    Refer to the output of orchestrion pin -help for more information about available customization options.

  3. Commit changes to your version control system (unless you are integrating orchestrion directly in your CI/CD pipeline):

    git add go.mod go.sum orchestrion.tool.go
    git commit -m "chore: enable orchestrion"
    

    Now you can manage your dependency on orchestrion like any other dependency using the go.mod file.

Usage

Use one of these methods to enable Orchestrion in your build process:

Prepend orchestrion to your usual go commands:

orchestrion go build .
orchestrion go run .
orchestrion go test ./...

Add the -toolexec="orchestrion toolexec" argument to your go commands:

go build -toolexec="orchestrion toolexec" .
go run -toolexec="orchestrion toolexec" .
go test -toolexec="orchestrion toolexec" ./...

Modify the $GOFLAGS environment variable to inject Orchestrion, and use go commands normally:

# Make sure to include the quotes as shown below, as these are required for
# the Go toolchain to parse GOFLAGS properly!
export GOFLAGS="${GOFLAGS} '-toolexec=orchestrion toolexec'"
go build .
go run .
go test ./...

Trace Customization

Setting up Unified Service Tagging

Applications instrumented by orchestrion support Unified Service Tagging (UST). You can set UST tags for your traces by setting the corresponding environment variable in your application’s runtime environment:

Unified TagEnvironment
envDD_ENV
serviceDD_SERVICE
versionDD_VERSION

For more information, refer to the Unified Service Tagging documentation.

Tracer configuration

Refer to Library Configuration for configuration instructions.

Create custom trace spans

Custom trace spans can be automatically created for any function annotated with the //dd:span directive comment:

example.go

//dd:span custom_tag:tag_value
func CriticalPathFunction() {
  // ... implementation details ...
}

This also works with function literal expressions:

example.go

//dd:span custom_tag:tag_value
handler := func(w http.ResponseWriter, r *http.Request) {
  // ... implementation details ...
}

Operation Name

The name of the operation (span.name) is determined automatically using the following precedence:

  1. An explicit span.name:customOperationName tag specified as a directive argument
  2. The function’s declared name (this does not apply to function literal expressions, which are anonymous)
  3. The value of the very first tag provided to the directive arguments list

example.go

//dd:span tag-name:spanName other-tag:bar span.name:operationName
func tracedFunction() {
  // This function will be represented as a span named "operationName"
}

//dd:span tag-name:spanName other-tag:bar
func otherTracedFunction() {
  // This function will be represented as a span named "otherTracedFunction"
}

//dd:span tag-name:spanName other-tag:bar
tracedFunction := func() {
  // This function will be represented as a span named "spanName"
}

Error Results

If the annotated function returns an error result, any error returned by the function will be automatically attached to the corresponding trace span:

example.go

//dd:span
func failableFunction() (any, error) {
  // This span will have error information attached automatically.
  return nil, errors.ErrUnsupported
}

Prevent instrumentation of some code

You can use the //orchestrion:ignore directive to prevent orchestrion from performing any modification on the annotated code.

This can be used to prevent caller-side instrumentation from being applied to specific locations:

example.go

import "database/sql"

// Caller-side instrumentation normally happens within this function...
func normal() {
  // The following assignment will NOT be modified to add any caller-side
  // instrumentation as it is opted out by the orchestrion:ignore directive:
  //orchestrion:ignore
  db, err := sql.Open("driver-name", "database=example")
  // ...
}

// Caller-side instrumentation will NOT happen in the following function
// as it is annotated with orchestrion:ignore.
//orchestrion:ignore
func excluded() {
  // The following assignment will NOT be modified to add any caller-side
  // instrumentation as the surrounding context is excluded by an
  // orchestrion:ignore directive:
  db, err := sql.Open("driver-name", "database=example")
  // ...
}

Some of the instrumentation performed by orchestrion is done callee-side (or library-side), meaning the integration is added directly within the dependency itself. In such cases, it is not possible to locally opt out of such integrations.

Use the tracing library

You can use the tracing library in your Orchestrion-built application. This is useful for instrumenting frameworks not yet supported by Orchestrion. However, be aware that this may result in duplicated trace spans in the future as Orchestrion support expands. Review the release notes when updating your orchestrion dependency to stay informed about new features and adjust your manual instrumentation as necessary.

Use the continuous profiler

Your Orchestrion-built application includes continuous profiler instrumentation. To enable the profiler, set the environment variable DD_PROFILING_ENABLED=true at runtime.

Troubleshooting

To troubleshoot builds that orchestrion manages, see Troubleshooting Go Compile-Time Instrumentation.

Add the tracer library to your application

First, import and start the tracer in your code following the Library Configuration documentation. Refer to the API documentation for configuration instructions and details about using the API.

Activate Go integrations to create spans

Activate Go integrations to generate spans. Datadog has a series of pluggable packages which provide out-of-the-box support for instrumenting a series of libraries and frameworks. A list of these packages can be found in the Compatibility Requirements page. Import these packages into your application and follow the configuration instructions listed alongside each integration.

Further reading