Enabling the Full-Host Profiler

Docs > Continuous Profiler > Enabling the Profiler > Enabling the Full-Host Profiler

Join the Preview!

Full Host is in Preview.

The Full-Host Profiler is an eBPF-based profiling solution built on OpenTelemetry that sends profiling data to Datadog using the Datadog Agent. It supports symbolication for compiled languages and is optimized for containerized environments such as Docker and Kubernetes.

Use cases

The Full-Host Profiler is particularly valuable for:

Profiling open source software components that aren’t instrumented with Datadog’s tracing libraries.
Analyzing performance across multi-language processes and runtimes.
Identifying resource bottlenecks at the host level, including detection of noisy neighbor processes.

Requirements

For a summary of the minimum and recommended runtime and tracer versions across all languages, read Supported Language and Tracer Versions.

Supported operating systems: Linux
Supported architecture: amd64 or arm64 processors
Serverless: full host is not supported on serverless platforms, such as AWS Lambda.
Debugging information: Symbols should be available locally or can be uploaded in CI with datadog-ci

Installation

Always set DD_SERVICE for each service you want to profile and identify separately. This ensures accurate attribution and more actionable profiling data. To learn more, see Service naming.

The Full-Host Profiler is distributed as a standalone executable.

Container environments

For hosts running containerized workloads, Datadog recommends running the profiler inside a container:

Kubernetes: Follow the running in Kubernetes instructions.
Docker: Follow the running in Docker instructions.
Container image: Available from the container registry.

Non-container environments

For hosts without container runtimes, follow the instructions for running directly on the host.

Configuration

Local symbol upload

For compiled languages (C/C++/Rust/Go), the profiler can upload local symbols to Datadog for symbolication when unstripped binaries are available. The Full-Host Profiler handles this automatically.

To upload symbols using datadog-ci, see Symbol upload.

Build

To build the Full-Host Profiler directly on your machine, run:

make

Service naming

When using full-host profiling, Datadog captures profiles from all processes running on the host. The service name for each process depends on the DD_SERVICE environment variable.

If DD_SERVICE is set, the profiler uses the value of DD_SERVICE as the service name. This is the recommended and most reliable approach.

If DD_SERVICE is not set, Datadog infers a service name from the binary name. For interpreted languages, this is the name of the interpreter. For example, for a service written in Java, the full-host profiler sets the service name to service:java.

Example of an inferred services within Profiling

If multiple services are running under the same interpreter (for example, two separate Java applications on the same host), and neither sets DD_SERVICE, Datadog groups them together under the same service name. Datadog cannot distinguish between them unless you provide a unique service name.

Symbol upload using datadog-ci

Git clone the datadog-ci command line tool
Install datadog-ci, run:
```
npm install -g @datadog/datadog-ci
```
Provide a Datadog API key through the DD_API_KEY environment variable.
Set the DD_SITE environment variable to your Datadog site. Your site is:
Set variables in an encrypted datadog-ci.json file at the root of your project:
```
{
   "apiKey": "<API_KEY>",
   "datadogSite": "<SITE>"
}
```
Install binutils
Run:

DD_BETA_COMMANDS_ENABLED=1 datadog-ci elf-symbols upload ~/your/build/bin/

What’s next?

After installing the Full-Host Profiler, see the Getting Started with Profiler to learn how to use Continuous Profiler to identify and fix performance problems.