# DataDog/datadog-agent: the collector behind the Datadog platform

> One Go binary that ships metrics, traces, logs, profiling and security signals from a host or container to the Datadog backend, built across four languages.

**DataDog/datadog-agent** — Main repository for Datadog Agent

- Repository: https://github.com/DataDog/datadog-agent
- Website: https://docs.datadoghq.com/
- Stars: 3,771 · Forks: 1,518
- Language: Go
- License: Apache-2.0
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/datadog-datadog-agent

## A four-paragraph README that exists to point elsewhere

The README for this repository is unusually short, and that is a deliberate choice rather than an unfinished page. It states that the repository holds the source for Agent version 7 and version 6, links to the agent user documentation for the differences between v5, v6 and v7, and links to a page offering prepackaged binaries for an easy install. It then points at a developer docs site for building the agent itself, at the `docs` directory for the source of that content, and at `docs/dev` for contribution guidance.

One substantive detail does appear in the README, and it is the licensing split. The user space components are Apache License 2.0, while the BPF code under `pkg/ebpf/c/COPYING` is General Public License version 2. That split matters if you were considering the agent in a redistribution scenario, and it is the kind of thing a short README will mention precisely because it is unusual.

Everything else about how the agent is configured, installed or operated lives on docs.datadoghq.com, and a separate developer site exists at datadoghq.dev. The repository's job is to be the source, not the manual.

## Go at the core, with Rust, Python and eBPF alongside

The repository language is Go, and the module declaration is the clearest statement of the project's scope:

```go
module github.com/DataDog/datadog-agent
```

The pinned toolchain is worth noting because it tells you what a contributor needs installed:

```go
go 1.26.0
```

Beyond Go there is a genuine Rust workspace, declared with the 2024 edition and a minimum Rust version of 1.94:

```toml
[workspace]
resolver = "2"
```

The Rust members listed in `Cargo.toml` are revealing about where performance and safety pressure lives: `pkg/procmgr/rust` for process management, `pkg/discovery/module/rust` for service discovery, `pkg/collector/sharedlibrary/rustchecks/core` for shared library scanning, a `datasecurity` check module, `comp/core/log/rust`, and `pkg/privateactionrunner/par-control`. Several depend on `aws-lc-rs` and `rustls` with native roots, which is the FIPS-adjacent crypto stack rather than the system OpenSSL.

Python shows up in tooling rather than runtime. `pyproject.toml` configures Ruff for linting with a 120 character line length and a py312 target, and configures mypy for Python 3.12. A commented note at the top of that file explains that single-quoted TOML strings are needed for regular expressions, the equivalent of Python raw strings. The eBPF components in C are the fourth language, and they are the reason for the GPL licence on that subtree.

## Configuration examples that show which subsystems you are turning on

The `examples/` directory is the most useful thing in the repository for someone who has not deployed the agent before, because the file names map directly onto feature sets. There is `agent_minimal.yaml` for the smallest useful configuration, `agent_otel.yaml` for OpenTelemetry collector mode, and then paired files for the major signal types: `agent_logs.yaml` and `agent_apm_logs.yaml`, `agent_liveprocess.yaml` and `agent_apm_liveprocess.yaml`, and a combined `agent_apm.yaml`.

That pairing is the lesson. Turning on APM is not a flag, it is a change to which processes are instrumented, which is why there is a separate live process file for each case. If you copy the wrong one you get tracing on everything or on nothing, and the resulting bill or empty dashboard is the usual way people discover the difference.

The root tree also carries configuration-shaped files that describe the project's own conventions. `agents.toml`, `.golangci.yml`, `.mockery.yaml` and `.pre-commit-config.yaml` are the lint and mocking setup, `.bazelversion` and `MODULE.bazel` pin the build system, and `.go-version` and `.python-version` pin the toolchains. Several CHANGELOG files sit at the root, split by audience: `CHANGELOG.rst` for the agent, plus `CHANGELOG-AIX.md`, `CHANGELOG-DCA.rst` and `CHANGELOG-INSTALLSCRIPT.rst` for separate distributions.

## What version 7.83 actually changed

Three releases are tagged, and their notes describe a project in maintenance mode on new subsystems rather than churning on the old ones.

Version 7.83.2, released 2026-09-16, changes how GPU constant metrics are reported. Metrics named `gpu.device.total`, `gpu.memory.limit`, `gpu.core.limit` and `gpu.memory.bar1.total` are now emitted on the cadence set by a new `gpu.static_metrics_reporting_interval` setting, defaulting to 15 seconds, so that weighted sums stay accurate. The same release lets Single Step Instrumentation tracer config mechanisms accept `OTEL_` prefixed environment variable names alongside the existing `DD_` prefix, which means a tracer's native OpenTelemetry settings such as the traces exporter and the OTLP endpoint can be set through remote configuration policy or a Kubernetes pod annotation.

Version 7.83.1, from 2026-09-09, is mostly fixes. A bug that billed customers for the fast network path is fixed. The release also fixes a container image SBOM scan that leaked a containerd view snapshot when a scan was cancelled or timed out, because the release ran on the scan's own context and a lazy snapshotter then held a materialised layer. It also starts reporting the state of the bundled DDOT process, the Datadog Distribution of OpenTelemetry Collector, so that version and configuration updates are visible in `datadog-installer status`.

Version 7.83.0, from 2026-09-03, is the feature release: a Data Security provider that schedules one-off database scan checks through Remote Configuration, enabled when both `data_security.enabled` and `shared_library_check.enabled` are set and currently targeting PostgreSQL databases already monitored by the agent; Kubernetes cluster receiver, leader elector extension and count connector in the DDOT manifest; a Helm rollback action; and an Agent Data Plane preflight mode controlled by `data_plane.preflight_mode`.

## Where the checks actually live, and why the split matters

Every release note in this repository opens with the same sentence: refer to the matching tag on the integrations-core repository for the list of changes to the Core Checks. That single line tells you the most important architectural fact about the project. The agent here is the runtime that schedules, collects and ships, while the individual integrations are maintained in a separate repository.

For a reader, that has two consequences. First, searching this repository for a specific integration will often be fruitless, because the code is elsewhere. Second, the agent version and the integrations version are coupled by a tag reference, so an agent upgrade can pull in integration behaviour changes that are documented somewhere you were not looking.

The Go module file shows how seriously this coupling is handled. It declares retracted versions v0.8.0 and v0.9.0 deliberately, so that no tagged version appears on pkg.go.dev, and it pins several forks with explanatory comments: a patched `go-cmp` to keep dead code elimination enabled, a `cast` fork, and a viper downgrade to v1.20.1 because viper v1.21.0 calls functions that do not exist in that fork. It also pins the OpenTelemetry eBPF profiler to a Datadog branch commit, with a comment giving the exact line to change when you want latest.

Dependency maintenance at this scale is not incidental. When you hit a dependency problem in a Go project of this size, the answer is often a fork pinned in `go.mod`.

## What the repository root reveals about how the team works

The tree is mostly tooling directories, and they describe an organisation more than they describe a codebase. There are paired editor and agent configuration directories for several tools at once: `.claude/`, `.claude-plugins/`, `.cursor/`, `.codex/`, `.opencode/`, `.agents/`, `.zed/`, `.vscode/` and `.run/`. Alongside them sit `AGENTS.md`, `CLAUDE.md`, `AGENTS.md`-adjacent `.mcp.json`, and a `.ddqa/` directory. Whatever one thinks of the trend, an engineering team that maintains nine tool-specific configuration directories has made a decision about how broadly they want their assistants configured.

Continuous integration is spread across providers. There is a `.github/` directory, a `.gitlab-ci.yml` at the root, and a `.gitlab/` directory, so the project is built on both hosted and self-managed GitLab. `code-coverage.datadog.yml` suggests coverage reporting is a tracked metric rather than an afterthought.

The scale is worth stating plainly: 3739 stars, 1497 forks, 765 open issues, Apache 2.0, default branch `main`, and a last push on 2026-09-23. The issue count on a repository of this size is not a quality signal by itself, but combined with four separate changelogs and a separate integrations repository it is a fair picture of a large, actively maintained product codebase. The topics confirm the scope: apm-agent, distributed-tracing, logging, metrics, profiling, observability, otel and open-telemetry all appear, alongside the language tag.

## Conclusion

datadog-agent is best understood as the vendor side of the Datadog platform rather than as a general purpose observability agent, and the repository makes that plain in a few places. The user space code is Apache 2.0 while the eBPF components are GPL, the Go module name is the product name, and the release notes point at a separate integrations-core repository for the checks themselves. For a reader deciding what to install, the config examples under `examples/` are the fastest route, with `agent_minimal.yaml`, `agent_otel.yaml` and the APM, logs and live process variants telling you which subsystems you would be turning on. The active development areas in the 7.83.x line are GPU metric cadence, an Agent Data Plane preflight mode, and routing OpenTelemetry Collector configuration through the agent. Start from the docs site for user-facing configuration, since the README here is four short sections that deliberately point elsewhere.

## FAQ

### What is a Datadog agent?

It is a program that runs on your hosts and containers and collects metrics, distributed traces, logs, profiling data and security signals, then sends them to Datadog. The agent is the component that schedules collection and handles communication with the backend; the individual service integrations live in a separate integrations-core repository, which every release note points to.

### How do I remove the Datadog Agent?

The user-facing instructions are on the agent documentation site rather than in this repository's README, since the README only covers source layout and points at docs.datadoghq.com for everything operational. If you installed via the prepackaged binaries or an infrastructure provider integration, removal usually follows the same mechanism you used to install, and the agent's own installer has a status subcommand for confirming what is present.

### What languages is the Datadog Agent written in?

Mostly Go, with the module declared at `github.com/DataDog/datadog-agent` and requiring Go 1.26.0. There is a Rust workspace for process management, service discovery, log handling and shared library checks, C for the eBPF components, and Python used for tooling and linting configuration rather than at runtime.

### Can the Datadog Agent run in OpenTelemetry mode?

There is an `agent_otel.yaml` example in the examples directory, and the bundled DDOT component is the Datadog Distribution of the OpenTelemetry Collector. Recent releases added Kubernetes cluster receiver, leader elector and count connector pieces to its default manifest, and let tracer configuration accept OTEL prefixed environment variables alongside DD prefixed ones.

## Sources

- [DataDog/datadog-agent on GitHub](https://github.com/DataDog/datadog-agent)
- [License: Apache-2.0](https://github.com/DataDog/datadog-agent/blob/main/LICENSE)
- [Project website](https://docs.datadoghq.com/)
- [README](https://github.com/DataDog/datadog-agent/blob/main/README.md)
- [Releases](https://github.com/DataDog/datadog-agent/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/datadog-datadog-agent