Enabling the Full-Host Profiler

Docs > Continuous 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 (Experimental)

For compiled languages (C/C++/Rust/Go), the profiler can upload local symbols to Datadog for symbolication when unstripped binaries are available.

To enable local symbol upload:

Set the DD_HOST_PROFILING_EXPERIMENTAL_UPLOAD_SYMBOLS=true.
Provide a Datadog API key through the DD_API_KEY environment variable.
Provide a Datadog application key through the DD_APP_KEY environment variable.
Set the DD_SITE environment variable to your Datadog site. Your site is:

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.

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.