This repository contains Go packages for the client-side components of the Datadog product suite for Application Performance Monitoring, Continuous Profiling and Application Security Monitoring of Go applications.
-
Datadog Application Performance Monitoring (APM): Trace requests as they flow across web servers, databases and microservices so that developers have great visiblity into bottlenecks and troublesome requests.
The packagegopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracerallows you to trace any piece of your Go code, and commonly used Go libraries can be automatically traced thanks to our out-of-the-box integrations which can be found in the packagegopkg.in/DataDog/dd-trace-go.v1/ddtrace/contrib. -
Datadog Go Continuous Profiler: Continuously profile your Go apps to find CPU, memory, and synchronization bottlenecks, broken down by function name, and line number, to significantly reduce end-user latency and infrastructure costs.
The packagegopkg.in/DataDog/dd-trace-go.v1/profilerallows you to periodically collect and send Go profiles to the Datadog API. -
Datadog Application Security Monitoring (ASM): Get observability into your Go apps attacks that aim to exploit code-level vulnerabilities, such as Server-Side-Request-Forgery (SSRF), SQL injection, Log4Shell, and Reflected Cross-Site-Scripting (XSS). ASM is not a standalone Go package and is transparently integrated into the APM tracer. Simply enable it to benefit from the security monitoring.
This module contains many packages, but most users should probably install the two packages below:
go get gopkg.in/DataDog/dd-trace-go.v1/ddtrace/tracer
go get gopkg.in/DataDog/dd-trace-go.v1/profilerAdditionally there are many contrib packages that can be installed to automatically instrument and trace commonly used Go libraries such as net/http, gorilla/mux or database/sql:
go get gopkg.in/DataDog/dd-trace-go.v1/contrib/gorilla/mux
If you installed more packages than you intended, you can use go mod tidy to remove any unused packages.
- APM Tracing API
- APM Tracing Go Applications
- Continuous Go Profiler
- Application Security Monitoring
- If you are migrating from an older version of the tracer (e.g. 0.6.x) you may also find the migration document we've put together helpful.
Datadog APM for Go is built upon dependencies defined in specific versions of the host operating system, Go releases, and the Datadog Agent/API. For Go the two latest releases are GA supported and the version before that is in Maintenance. We do make efforts to support older releases, but generally these releases are considered Legacy. This library only officially supports first class ports of Go.
| Level | Support provided |
|---|---|
| General Availability (GA) | Full implementation of all features. Full support for new features, bug & security fixes. |
| Maintenance | Full implementation of existing features. May receive new features. Support for bug & security fixes only. |
| Legacy | Legacy implementation. May have limited function, but no maintenance provided. Contact our customer support team for special requests. |
| Go Version | Support level |
|---|---|
| 1.19 | GA |
| 1.18 | GA |
| 1.17 | Maintenance |
| 1.16 | Legacy |
- Datadog's Trace Agent >= 5.21.1
A Minor version change will be released whenever a new version of Go is released. At that time the newest version of Go is added to GA, the second oldest supported version moved to Maintenance and the oldest previously supported version dropped to Legacy. For example: For a dd-trace-go version 1.37.*
| Go Version | Support |
|---|---|
| 1.18 | GA |
| 1.17 | GA |
| 1.16 | Maintenance |
Then after Go 1.19 is released there will be a new dd-trace-go version 1.38.0 with support:
| Go Version | Support |
|---|---|
| 1.19 | GA |
| 1.18 | GA |
| 1.17 | Maintenance |
| 1.16 | Legacy |
Before considering contributions to the project, please take a moment to read our brief contribution guidelines.
Tests can be run locally using the Go toolset. The grpc.v12 integration will fail (and this is normal), because it covers for deprecated methods. In the CI environment we vendor this version of the library inside the integration. Under normal circumstances this is not something that we want to do, because users using this integration might be running versions different from the vendored one, creating hard to debug conflicts.
To run integration tests locally, you should set the INTEGRATION environment variable. The dependencies of the integration tests are best run via Docker. To get an
idea about the versions and the set-up take a look at our CI config.
The best way to run the entire test suite is using the CircleCI CLI. In order to run
jobs locally, you'll first need to convert the Circle CI configuration to a format accepted by the circleci cli tool:
circleci config process .circleci/config.yml > process.yml(from the repository root)
Once you have a converted process.yml, simply run circleci local execute -c process.yml --job <job-name>.
Note that you might have to increase the resources dedicated to Docker to around 4GB.