---
isPrivate: true
title: Enabling the Full-Host Profiler
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Continuous Profiler > Enabling the Profiler > Enabling the Full-Host
  Profiler
---

# Enabling the Full-Host Profiler

{% callout %}
##### Join the Preview!

Full-Host is in Preview.

[Request Access](https://www.datadoghq.com/product-preview/full-host-profiler/)
{% /callout %}

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{% #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.

## Requirements{% #requirements %}

{% dl %}

{% dt %}
Supported operating systems
{% /dt %}

{% dd %}
Linux (5.4+ for amd64, 5.5+ for arm64)
{% /dd %}

{% dt %}
Supported architecture
{% /dt %}

{% dd %}
`amd64` or `arm64` processors
{% /dd %}

{% dt %}
Serverless
{% /dt %}

{% dd %}
`full-host` is not supported on serverless platforms, such as AWS Lambda.
{% /dd %}

{% dt %}
Debugging information
{% /dt %}

{% dd %}
Symbols should be available locally or can be uploaded in CI with `datadog-ci`
{% /dd %}

{% /dl %}

## Installation{% #installation %}

{% alert level="info" %}
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.
{% /alert %}

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

### Container environments{% #container-environments %}

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

- **Kubernetes**: Follow the [running in Kubernetes](https://github.com/DataDog/dd-otel-host-profiler/blob/main/doc/running-in-kubernetes.md) instructions.
- **Docker**: Follow the [running in Docker](https://github.com/DataDog/dd-otel-host-profiler/blob/main/doc/running-in-docker.md) instructions.
- **Container image**: Available from the [container registry](https://github.com/DataDog/dd-otel-host-profiler/pkgs/container/dd-otel-host-profiler/.).

### Non-container environments{% #non-container-environments %}

For hosts without container runtimes, follow the instructions for [running directly on the host](https://github.com/DataDog/dd-otel-host-profiler/blob/main/doc/running-on-host.md).

## Service naming{% #service-naming %}

When using full-host profiling, Datadog profiles all processes on the host. Each process's service name is derived from its `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`.

{% image
   source="https://datadog-docs.imgix.net/images/profiler/inferred_service_example.6b332194a449a452029bb4e33bb77214.png?auto=format"
   alt="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.

## Debug symbols{% #debug-symbols %}

For compiled languages (such as Rust, C, C++, Go, etc.), the profiler uploads local symbols to Datadog for symbolication, ensuring that function names are available in profiles. For Rust, C, and C++, symbols need to be available locally (unstripped binaries).

For binaries stripped of debug symbols, it's possible to upload symbols manually or in the CI:

1. Install the [datadog-ci](https://github.com/DataDog/datadog-ci?tab=readme-ov-file#how-to-install-the-cli) command line tool.
1. Provide a [Datadog API key](https://app.datadoghq.com/organization-settings/api-keys) through the `DD_API_KEY` environment variable.
1. Set the `DD_SITE` environment variable to your [Datadog site](https://docs.datadoghq.com/getting_started/site/).
1. Install the `binutils` package, which provides the `objcopy` CLI tool.
1. Run:
   ```gdscript3
   DD_BETA_COMMANDS_ENABLED=1 datadog-ci elf-symbols upload ~/your/build/symbols/
   ```

## What's next?{% #whats-next %}

After installing the Full-Host Profiler, see the [Getting Started with Profiler](https://docs.datadoghq.com/getting_started/profiler/) to learn how to use Continuous Profiler to identify and fix performance problems.

## Further reading{% #further-reading %}

- [Getting Started with Profiler](https://docs.datadoghq.com/getting_started/profiler)