You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/profiler/enabling/full_host.md
+22-51Lines changed: 22 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ further_reading:
8
8
---
9
9
10
10
{{< callout url="https://www.datadoghq.com/product-preview/full-host-profiler/" btn_hidden="false" header="Join the Preview!" >}}
11
-
FullHost is in Preview.
11
+
Full-Host is in Preview.
12
12
{{< /callout >}}
13
13
14
14
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.
@@ -19,21 +19,17 @@ The Full-Host Profiler is particularly valuable for:
19
19
20
20
- Profiling open source software components that aren't instrumented with Datadog's tracing libraries.
21
21
- Analyzing performance across multi-language processes and runtimes.
22
-
- Identifying resource bottlenecks at the host level, including detection of noisy neighbor processes.
23
-
24
22
25
23
## Requirements
26
24
27
-
For a summary of the minimum and recommended runtime and tracer versions across all languages, read [Supported Language and Tracer Versions][7].
28
-
29
25
Supported operating systems
30
-
: Linux
26
+
: Linux (5.4+ for amd64, 5.5+ for arm64)
31
27
32
28
Supported architecture
33
29
: `amd64` or `arm64` processors
34
30
35
31
Serverless
36
-
: `fullhost` is not supported on serverless platforms, such as AWS Lambda.
32
+
: `full-host` is not supported on serverless platforms, such as AWS Lambda.
37
33
38
34
Debugging information
39
35
: Symbols should be available locally or can be uploaded in CI with `datadog-ci`
@@ -47,31 +43,17 @@ The Full-Host Profiler is distributed as a standalone executable.
47
43
### Container environments
48
44
For hosts running containerized workloads, Datadog recommends running the profiler inside a container:
49
45
50
-
-**Kubernetes**: Follow the [running in Kubernetes][8] instructions.
51
-
-**Docker**: Follow the [running in Docker][9] instructions.
46
+
-**Kubernetes**: Follow the [running in Kubernetes][7] instructions.
47
+
-**Docker**: Follow the [running in Docker][8] instructions.
52
48
-**Container image**: Available from the [container registry][5].
53
49
54
50
55
51
### Non-container environments
56
52
57
-
For hosts without container runtimes, follow the instructions for [running directly on the host][10].
58
-
59
-
### Configuration
60
-
#### Local symbol upload
61
-
For compiled languages (C/C++/Rust/Go), the profiler can upload local symbols to Datadog for symbolication when unstripped binaries are available.
62
-
The Full-Host Profiler handles this automatically.
63
-
64
-
To upload symbols using datadog-ci, see <ahref="#symbol-upload-using-datadog-ci">Symbol upload</a>.
65
-
66
-
### Build
67
-
To build the Full-Host Profiler directly on your machine, run:
68
-
69
-
```shell
70
-
make
71
-
```
53
+
For hosts without container runtimes, follow the instructions for [running directly on the host][9].
72
54
73
55
## Service naming
74
-
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.
56
+
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.
75
57
76
58
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.
77
59
@@ -80,30 +62,20 @@ If `DD_SERVICE` is not set, Datadog infers a service name from the binary name.
80
62
81
63
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.
82
64
83
-
## Symbol upload using datadog-ci
65
+
## Debug symbols
84
66
85
-
1. Git clone the [datadog-ci][13] command line tool
86
-
2. Install `datadog-ci`, run:
67
+
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).
87
68
88
-
```shell
89
-
npm install -g @datadog/datadog-ci
90
-
```
91
-
3. Provide a [Datadog API key][11] through the `DD_API_KEY` environment variable.
92
-
4. Set the `DD_SITE` environment variable to your [Datadog site][12]. Your site is: {{< region-param key="dd_site" code="true" >}}
93
-
5. Set variables in an encrypted `datadog-ci.json` file at the root of your project:
69
+
For binaries stripped of debug symbols, it's possible to upload symbols manually or in the CI:
94
70
71
+
1. Install the [datadog-ci][12] command line tool.
72
+
2. Provide a [Datadog API key][10] through the `DD_API_KEY` environment variable.
73
+
3. Set the `DD_SITE` environment variable to your [Datadog site][11].
74
+
4. Install the `binutils` package, which provides the `objcopy` CLI tool.
0 commit comments