---
title: Infrastructure List Host Information
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > OpenTelemetry in Datadog > Semantic Mapping > Infrastructure List Host
  Information
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Infrastructure List Host Information

{% alert level="info" %}
This feature is in Preview. If you have any feedback, contact [Datadog support](https://docs.datadoghq.com/help/).
{% /alert %}

## Overview{% #overview %}

The Datadog Exporter collects host metadata and sends it to Datadog by default, where you can see it in the [Infrastructure List](https://docs.datadoghq.com/infrastructure/list.md). For most deployments, such as running the Collector as an agent on each host, host information is populated automatically and you do not need to follow the configuration on this page.

{% alert level="info" %}
The manual configuration described on this page is primarily for [gateway deployments](https://opentelemetry.io/docs/collector/deployment/gateway/), where the Collector that exports to Datadog runs separately from the hosts it reports on. In these setups, explicitly tag your resources so that the correct host metadata reaches Datadog. If you run the Collector as an agent on each host, host metadata is collected by default and you can skip this configuration.
{% /alert %}

The Datadog Exporter supports sending system information about your hosts to Datadog. You can send this information in OTLP through the ['Resource' field](https://opentelemetry.io/docs/concepts/glossary/#resource) as part of any of the existing signals. This is supported under any [deployment pattern](https://opentelemetry.io/docs/collector/deployment/) including gateway deploys.

{% alert level="danger" %}
Only metadata sent through the Datadog Exporter populates the Infrastructure Host List. Metadata sent using the direct OTLP ingest endpoint does not support this feature.
{% /alert %}

Datadog uses [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/) to recognize system information about your hosts. Follow the instructions for [setting up for host metrics](https://docs.datadoghq.com/opentelemetry/collector_exporter/host_metrics.md) to send the necessary metrics and resource attributes to Datadog. Alternatively, you can manually send this information in the way that best fits your infrastructure.

## Opting in to the feature{% #opting-in-to-the-feature %}

For gateway deployments, or to manually control which resources are used for host metadata, set the `datadog.host.use_as_metadata` resource attribute to `true` in all OTLP payloads that contain information about hosts.

Resources populate the infrastructure list information if they have a [host-identifying attribute](https://docs.datadoghq.com/opentelemetry/schema_semantics/hostname.md) and the `datadog.host.use_as_metadata` attribute set to `true`.

To explicitly declare what resources to use for metadata, add the Boolean resource attribute `datadog.host.use_as_metadata` to all resources that have relevant host information.

For example, to set this for all resources in metrics, traces, and logs, use the [transform processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor#transform-processor) with the following configuration:

```yaml
processors:
  transform:
    metric_statements:
      - context: resource
        statements:
          - set(attributes["datadog.host.use_as_metadata"], true)
    trace_statements:
      - context: resource
        statements:
          - set(attributes["datadog.host.use_as_metadata"], true)
    log_statements:
      - context: resource
        statements:
          - set(attributes["datadog.host.use_as_metadata"], true)
```

Add this processor to the `processors` list of all your pipelines.

You must explicitly tag all your resources with a host-identifying attribute. This is done by default by the [recommended setup for host metrics](https://docs.datadoghq.com/opentelemetry/collector_exporter/host_metrics.md).

## Supported conventions{% #supported-conventions %}

The Datadog exporter supports both resource attribute-level semantic conventions and system metrics-level semantic conventions. Supported resource attribute semantic conventions are mainly under [the `host.` namespace](https://opentelemetry.io/docs/specs/semconv/resource/host/) and [the `os.` namespace](https://opentelemetry.io/docs/specs/semconv/resource/os/). All supported system metrics-level semantic conventions are under [the `system.` namespace](https://opentelemetry.io/docs/specs/semconv/system/system-metrics/).

### General system conventions{% #general-system-conventions %}

| Semantic convention                                                                                            | Type               | In-app field |
| -------------------------------------------------------------------------------------------------------------- | ------------------ | ------------ |
| [*Various host-identifying attributes*](https://docs.datadoghq.com/opentelemetry/schema_semantics/hostname.md) | Resource attribute | Hostname     |
| `os.description`                                                                                               | Resource attribute | OS           |

### CPU conventions{% #cpu-conventions %}

| Semantic convention         | Type               | In-app field       |
| --------------------------- | ------------------ | ------------------ |
| `host.cpu.vendor.id`        | Resource attribute | Vendor ID          |
| `host.cpu.model.name`       | Resource attribute | Model Name         |
| `host.cpu.cache.l2.size`    | Resource attribute | Cache Size         |
| `host.cpu.family`           | Resource attribute | Family             |
| `host.cpu.model.id`         | Resource attribute | Model              |
| `host.cpu.stepping`         | Resource attribute | Stepping           |
| `system.cpu.logical.count`  | System metric      | Logical Processors |
| `system.cpu.physical.count` | System metric      | Cores              |
| `system.cpu.frequency`      | System metric      | MHz                |

### Network conventions{% #network-conventions %}

| Semantic convention | Type               | In-app field              |
| ------------------- | ------------------ | ------------------------- |
| `host.ip`           | Resource attribute | IP Address & IPv6 Address |
| `host.mac`          | Resource attribute | Mac Address               |

### Collecting these conventions with the OpenTelemetry Collector{% #collecting-these-conventions-with-the-opentelemetry-collector %}

To collect these conventions with the OpenTelemetry Collector, set up the [recommended setup for host metrics](https://docs.datadoghq.com/opentelemetry/collector_exporter/host_metrics.md). The host metrics receiver collects all the relevant metrics, while the resource detection processor collects all relevant resource attributes.

**Note:** You need to add these processors and receivers in the Collector running on the host that you want to monitor. A gateway host does not collect this information from remote hosts.

## Canonical cloud resource IDs{% #canonical-cloud-resource-ids %}

Canonical cloud resource IDs (CCRIDs) are cloud provider-assigned resource IDs that uniquely identify a cloud resource. After adding CCRIDs across your different observability types, you can use them to consistently link different types of data for a given cloud resource. You can add CCRIDs in the same format across all cloud resource types. Widespread addition and adoption of CCRIDs gives you access to a variety of use cases across customers and internal teams.

Enable CCRIDs to jump between resources and their associated metrics, traces, and logs for all resource types, eliminating context switching and giving you an end-to-end view of your resources within the same workflow.

To use this feature, set the `datadog.ccrid` resource attribute to the value of the CCRID in all OTLP payloads.

See below for the list of identifier formats per-cloud:

| Cloud | Identifier Type   | Example                                                                                                                               |
| ----- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| AWS   | ARN               | `arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi`                                                                             |
| Azure | Resource ID       | `/subscriptions/12345678-1234-5678-1234-567891234567/resourcegroups/exampleResourceGroup/Microsoft.Compute/virtualMachines/exampleVM` |
| GCP   | CAI Resource Name | `//compute.googleapis.com/projects/example-project/locations/us-central1/instances/my-instance`                                       |
| OCI   | OCID              | `ocid1.instance.oc1.eu-frankfurt-1.exampleuniqueid`                                                                                   |

How to form a CCRID:

- [AWS (EC2 Instance)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html#policy-syntax): `arn:aws:ec2:{region}:{accountId}:instance/{instanceId}`. Use this command to retrieve the `instanceId`:
  ```shell
  ec2metadata --instance-id
  ```
- [Azure](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-resource-group-and-subscription?tabs=azure-cli): `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
- GCP: `//compute.googleapis.com/projects/{projectID}/zones/{zoneName}/instances/{instanceName}"`
- OCI/Oracle: The CCRID can be obtained by [sending a request](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/gettingmetadata.htm) at: `http://169.254.169.254/opc/v2/instance/id`

For example, to set an AWS CCRID for all resources in metrics, traces, and logs, use the [transform processor](https://opentelemetry.io/docs/concepts/semantic-conventions/) with the following configuration:

```yaml
processors:
  transform:
    metric_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")
    trace_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")
    log_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:ec2:us-east-1:123456789012:instance/i-abcdefghi")
```

The OpenTelemetry semantic conventions also define the [cloud.resource_id](https://opentelemetry.io/docs/specs/semconv/registry/attributes/cloud/#cloud-resource-id) attribute, which can be mapped in the configuration using the [attributes processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/attributesprocessor).

Example:

```yaml
processors:
  attributes/example:
    actions:
      - key: datadog.ccrid
        from_attribute: cloud.resource_id
        action: upsert
```

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

- [OpenTelemetry Support in Datadog](https://docs.datadoghq.com/opentelemetry.md)