OpenTelemetry Host Monitoring is a Dynatrace feature that transforms raw telemetry data from OTel Collectors into actionable insights. Rather than simply ingesting metrics, logs, and traces, Dynatrace automatically builds meaningful context around your infrastructure. It creates host and process entities, establishes topology relationships, and presents data through purpose-built analysis screens.
With the extension, you can:
Explore the metrics of your OpenTelemetry-monitored hosts and processes in Data Explorer, split by the dt.entity.otel:host and dt.entity.otel:process dimensions.
Use auto-generated entities (based on extracted metadata) to correlate metrics and spans and provide unified context across your monitoring environment.
This use case and its reference configuration are designed primarily for VMs and bare-metal hosts with a Linux OS.
journald from the pipeline–journald is only available for Linux OS.This use case assumes that you have:
hostmetrics, journald, and otlp receivers, and the resource_detection, filter, and transform processors.
A reference configuration is available in the Dynatrace OTel Collector's GitHub repo, see host-metrics.yaml.
You can use this configuration as-is, or modify it to meet your specific needs. However, if you make significant changes to the configuration, the visualizations may not work as intended. For entity extraction to work, you need to keep the existing host and process attributes.
For our configuration, we configured the following components that are specific to this extension.
Under receivers, we specify the following receivers:
The hostmetrics receiver collects host-level metrics.
It is configured with three collection intervals: 10 seconds, 5 minutes, and 1 hour.
The journald receiver collects systemd journal logs from the host and ingests them into the logs pipeline alongside your metrics.
It is configured to read from /run/log/journal and applies move operators to rename journal fields to OpenTelemetry semantic conventions.
body._PID is renamed to body.pidbody._EXE is renamed to attributes["process.executable.name"]body.MESSAGE is renamed to body.messageHost logs are ingested with these attributes, but they aren't linked to the OpenTelemetry host or process entities. For details, see Topology.
The journald receiver is supported on Linux OS only, and requires the journalctl binary on the host.
The Collector process must have permission to read the systemd journal.
On Linux hosts, add the user running the Collector to the systemd-journal group.
For full details, see Use journald to ingest systemd journal logs with the OTel Collector (Dynatrace Classic).
The otlp receiver accepts OTLP over gRPC on port 4317 and over HTTP on port 4318.
In this configuration it is wired into the logs pipeline only, so that application logs sent to the local host Collector are enriched with the host attributes before they are ingested. Application metrics and spans are not part of this use case.
Under processors, we specify the following processors.
All of them are required, and the order in which they are listed in a pipeline is significant—see Service pipelines.
resource_detection detects resource information from the host in a format that conforms to the OpenTelemetry resource semantic conventions, and appends it to the telemetry data.
This is what adds host.id, host.name, and the other host attributes that entity extraction depends on.
Without it, no host or process entity is created.filter is used twice: once to clean up unnecessary metrics dimensions, and secondly to (optionally) filter out unneeded process metrics.transform reshapes the scraped metrics.
Among other things, it converts host.ip from an array to a single value, which the attributes added by resource_detection are needed for.cumulative_to_delta converts the cumulative counters emitted by hostmetrics into delta temporality.
Dynatrace does not ingest cumulative counters, so without this processor every counter metric in this configuration is discarded.Under exporters, we specify the otlp_http exporter and configure it with our Dynatrace API URL and the required authentication token.
For this purpose, we set the following two environment variables and reference them in the configuration values for endpoint and Authorization.
DT_ENDPOINT contains the base URL of the Dynatrace API endpoint (for example, https://{your-environment-id}.live.dynatrace.com/api/v2/otlp).Authorization: Api-Token ${env:DT_API_TOKEN} in the exporter headers and assign the Ingest logs (logs.ingest) and Ingest metrics (metrics.ingest) scopes.Under service, we assemble the receivers, processors, and exporter into two pipelines.
service:pipelines:metrics:receivers: [hostmetrics/10s, hostmetrics/5m, hostmetrics/1h]processors: [filter, resource_detection, transform, filter/delete-metrics, cumulative_to_delta]exporters: [otlp_http]logs:receivers: [otlp, journald]processors: [resource_detection]exporters: [otlp_http]
The metrics pipeline carries host and process metrics from the three hostmetrics receivers.
The logs pipeline carries host logs from journald and application logs received over OTLP.
There is no traces pipeline.
Processors run in the order in which they are listed, and each step in the metrics pipeline depends on the one before it.
filter runs first, so that the CPU datapoints it discards are gone before transform aggregates the remainder.resource_detection runs before transform, because transform reads the host attributes that resource_detection adds.transform runs before filter/delete-metrics, because it sets the marker attribute that filter/delete-metrics selects on.cumulative_to_delta runs last, once the set of metrics to be exported is final.Reordering these processors does not produce a configuration error: it produces incorrect or missing data. So, keep the order as given.
resource_detection is what attaches the host attributes, and it only applies to the pipelines that list it.
Telemetry that reaches the Collector through a pipeline without resource_detection is exported without host attributes and is not attached to the OpenTelemetry host entity.
Once you've set up your Collectors and the Host Monitoring extension, use Data Explorer to analyze the ingested host and process metrics.
Split the metrics by the dt.entity.otel:host or dt.entity.otel:process dimension to see them per entity.
This extension automatically generates topology for infrastructure monitored via the Collector. Specifically, it creates the entity types based on metadata extracted from metrics and spans.
| Entity type | Entity ID |
|---|---|
OpenTelemetry host |
|
OpenTelemetry process |
|
These entities enable Dynatrace to correlate your metrics and spans and provide unified context across your monitored environment.
Logs aren't used for entity extraction and aren't linked to the OpenTelemetry host or process entities. Logs that pass through the reference configuration are still ingested with the host attributes.
In order for Dynatrace to extract host and process entities, the following resource attributes must be present on your metrics and spans. If you use the reference configuration, these are automatically included by default. If you use a custom Collector configuration that differs from the reference configuration, make sure these attributes are included.
| Signal | otel:host | otel:process |
|---|---|---|
Metrics |
|
|
Spans |
|
|
If you send your application logs to your local host Collector, the reference configuration enriches them with the host attributes.
The logs aren't attached to the OpenTelemetry host entity, though; see Topology.
The reference configuration doesn't accept application metrics or spans over OTLP.
If you extend it with additional service pipelines for metrics or spans, add resource_detection to those pipelines as well, so that they're attached to the OpenTelemetry host entity.
See Service pipelines.
To enrich application metrics and spans with the corresponding process entity, they need to have the process.executable.name resource attribute.
For spans to have this attribute, you need to initialize your OTel SDK with the process resource detector.
If this is not implemented for your technology's OTel SDK, you can always set the process.executable.name attribute through the OTEL_RESOURCE_ATTRIBUTES environment variable.
The OpenTelemetry Host Monitoring extension doesn't include alerts for Dynatrace Classic. Its alert templates are anomaly detection templates, which aren't available in Dynatrace Classic.
To alert on host and process metrics, create your own metric events in Settings > Anomaly detection > Metric events. For details, see Metric events.
By default, all process metrics are sent to Dynatrace.
You can also exclude certain process metrics to control the amount of OTel process entities and improve cardinality. For example, you might want to filter out insignificant processes that use less than 1 MiB of memory.
To do this, you can filter via the process memory usage or an allow list.
To filter via process memory usage, use the following transform and filter processor configurations in your host monitoring configuration YAML.
Adjust the datapoint.value_int value (in bytes) according to your use case.
If the memory usage of the process fluctuates around the configured limit, metrics could be ingested and dropped intermittently. These data gaps would affect cumulative data like counts or sums.
transform:error_mode: ignoremetric_statements:- set(resource.attributes["low-memory-process"], "true") where metric.name == "process.memory.usage" and datapoint.value_int < 1048576 and resource.attributes["process.executable.name"] != nilfilter/delete-metrics:metric_conditions:- resource.attributes["low-memory-process"] != nil
To create an allowlist, use the following transform and filter processors in your host monitoring configuration YAML.
Adjust the ContainsValue() and resource.attributes[] variable names according to your use case.
transform:error_mode: ignoremetric_statements:- delete_key(resource.attributes, "low-memory-process") where ContainsValue(["my-process", "another-process"], resource.attributes["process.executable.name"])filter/delete-metrics:metric_conditions:- resource.attributes["low-memory-process"] != nil
The reference configuration and this use case are optimized for VMs and bare-metal hosts. You can run OTel host monitoring on Kubernetes nodes, but there are additional deployment requirements and important caveats to consider.
To collect host-level metrics from every node in your cluster, deploy the Collector as a DaemonSet. This ensures one Collector pod runs on each node and reports that node's metrics.
The hostmetrics receiver works without any additional configuration on Kubernetes.
The same receiver configuration you use on VMs applies to containerized deployments.
To collect journald logs on Kubernetes nodes, the Collector must run as root (runAsUser: 0) because container isolation prevents group-based journal access.
You also need to mount the journal directory from the host and adjust the directory setting to the mounted path.
On Kubernetes, the in-memory journal path is typically /run/log/journal rather than the persistent /var/log/journal used on VMs.
See Use journald to ingest systemd journal logs with the OTel Collector (Dynatrace Classic) for the full Kubernetes deployment configuration, including the required security context and host volume mounts.
If you run both OTel host monitoring and Kubernetes cluster monitoring on the same nodes, be aware that some metrics overlap: the same measurements may be ingested as two separate metric keys. This is because they have different metric names that follow different semantic conventions, so Dynatrace ingests them as separate metric keys.
The following table shows common overlapping metrics:
hostmetrics receiver | kubelet_stats receiver | What they measure |
|---|---|---|
|
| Node CPU usage |
|
| Node memory usage |
|
| Node filesystem usage |
|
| Node network I/O |
This overlapp occurs because the Kubernetes monitoring use case uses the kubelet_stats receiver, which reports node-level resource metrics that represent the same underlying data as the hostmetrics receiver.
To avoid unnecessary duplication on Kubernetes, use only Kubernetes monitoring or only OTel host monitoring, if possible:
kubelet_stats receiver. Adding hostmetrics on top duplicates the node-level resource metrics.filter processor to drop overlapping node-level metrics from one of the two pipelines.
For example, filter out system.cpu.*, system.memory.*, system.filesystem.*, and system.network.* from the host monitoring pipeline if the Kubernetes monitoring pipeline already covers them.system.processes.created metric is only available on Linux.process.disk.io metric requires running the Collector with privileged access.
Without privileged access, the metric is not captured.journald receiver is only supported on Linux. Attempting to use the journald receiver on a different operating system will cause the Collector to return an error and exit on startup.