duxing / dd-trace-go Goto Github PK

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/profiler

Additionally there are many contrib packages that can be installed as needed like this:

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.

• API
• Tracing Go Applications
• Continuous Go Profiler.
• 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.

• 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.*

Then after Go 1.19 is released there will be a new dd-trace-go version 1.38.0 with support:

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.