Overview

The Datadog exporter supports sending system information about your hosts to Datadog, which you can see in the Infrastructure List. You can send this information in OTLP through the ‘Resource’ field as part of any of the existing signals. This is supported under any deployment pattern including gateway deploys.

Datadog uses OpenTelemetry semantic conventions to recognize system information about your hosts. Follow the instructions for setting up for host metrics 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

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 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 with the following configuration:

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.

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 and the os. namespace. All supported system metrics-level semantic conventions are under the system. namespace.

General system conventions

CPU conventions

Network conventions

Collecting these conventions with the OpenTelemetry Collector

To collect these conventions with the OpenTelemetry Collector, set up the recommended setup for host metrics. 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 (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:

How to form a CCRID:

• AWS (EC2 Instance): arn:aws:ec2:{region}:{accountId}:instance/{instanceId}. Use this command to retrieve the instanceId:

  ec2metadata --instance-id
  

• Azure: /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 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 with the following configuration:

processors:
  transform:
    metric_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:sns:us-east-1:123456789012:instance/example-sns-topic-name")
    trace_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:sns:us-east-1:123456789012:instance/example-sns-topic-name")
    log_statements:
      - context: resource
        statements:
          - set(attributes["datadog.ccrid"], "arn:aws:sns:us-east-1:123456789012:instance/example-sns-topic-name")

The OpenTelemetry semantic conventions also define the cloud.resource_id attribute, which can be mapped in the configuration using the attributes processor.

Example:

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

Further reading

Additional helpful documentation, links, and articles:

OpenTelemetry Support in DatadogDOCUMENTATION