--- 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 --- # 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 supports sending system information about your hosts to Datadog, which you can see in the [Infrastructure List](https://docs.datadoghq.com/infrastructure/list.md). 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 will populate 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 %} To use this feature, 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)