OpenTelemetry Semantic Conventions and Datadog Conventions

Docs > OpenTelemetry in Datadog > Semantic Mapping > OpenTelemetry Semantic Conventions and Datadog Conventions

OpenTelemetry makes use of a number of semantic conventions that specify names for different types of data. This page lists mappings for OpenTelemetry semantic conventions to Datadog’s semantic conventions.

Unified service tagging

OpenTelemetry convention	Datadog convention
`deployment.environment` ¹	`env`
`deployment.environment.name` ²	`env`
`service.name`	`service`
`service.version`	`version`

For more information, see Unified Service Tagging.

1: deployment.environment has been deprecated in favor of deployment.environment.name in OpenTelemetry semantic conventions v1.27.0
2: deployment.environment.name is supported in Datadog Agent 7.58.0+ and Datadog Exporter v0.110.0+

Containers

OpenTelemetry convention	Datadog convention
`container.id`	`container_id`
`container.name`	`container_name`
`container.image.name`	`image_name`
`container.image.tag`	`image_tag`

Additional cloud provider-specific attributes are also mapped.

Cloud

OpenTelemetry convention	Datadog convention
`cloud.provider`	`cloud_provider`
`cloud.region`	`region`
`cloud.availability_zone`	`zone`

ECS

OpenTelemetry convention	Datadog convention
`aws.ecs.task.family`	`task_family`
`aws.ecs.task.arn`	`task_arn`
`aws.ecs.cluster.arn`	`ecs_cluster_name`
`aws.ecs.task.revision`	`task_version`
`aws.ecs.container.arn`	`ecs_container_name`

Kubernetes

OpenTelemetry convention	Datadog convention
`k8s.container.name`	`kube_container_name`
`k8s.cluster.name`	`kube_cluster_name`
`k8s.deployment.name`	`kube_deployment`
`k8s.replicaset.name`	`kube_replica_set`
`k8s.statefulset.name`	`kube_stateful_set`
`k8s.daemonset.name`	`kube_daemon_set`
`k8s.job.name`	`kube_job`
`k8s.cronjob.name`	`kube_cronjob`
`k8s.namespace.name`	`kube_namespace`
`k8s.pod.name`	`pod_name`

Kubernetes labels

Kubernetes convention	Datadog convention
`app.kubernetes.io/name`	`kube_app_name`
`app.kubernetes.io/instance`	`kube_app_instance`
`app.kubernetes.io/version`	`kube_app_version`
`app.kuberenetes.io/component`	`kube_app_component`
`app.kubernetes.io/part-of`	`kube_app_part_of`
`app.kubernetes.io/managed-by`	`kube_app_managed_by`

HTTP

OpenTelemetry convention	Datadog convention
`client.address`	`http.client_ip`
`http.response.body.size`	`http.response.content_length`
`http.response.header.<header-name>`	`http.response.headers.<header-name>`
`http.response.status_code`	`http.status_code`
`http.request.body.size`	`http.request.content_length`
`http.request.header.referrer`	`http.referrer`
`http.request.header.<header-name>`	`http.request.headers.<header-name>`
`http.request.method`	`http.method`
`http.route`	`http.route`
`network.protocol.version`	`http.version`
`server.address`	`http.server_name`
`url.full`	`http.url`
`user_agent.original`	`http.useragent`

Span type mapping

Datadog has a vendor-specific convention of “span type” represented by the span.type attribute.

Based on the attributes included in your span, the Datadog Agent and Datadog OpenTelemetry components attempt to infer the appropriate span type for better compatibility with other Datadog services. You may also explicitly set the span.type attribute on any given span to override this logic using an attributes or a transform processor, as well as by setting appropriate configuration values in OpenTelemetry SDKs.

Map OpenTelemetry span attribute to Datadog span type

The following table shows the span type mapping logic that is used if the feature flag enable_receive_resource_spans_v2 is set in the Datadog Agent or both the Datadog Exporter and Connector, if using the OpenTelemetry Collector. The chart lists mappings in order of precedence.

#	Span Attribute	Datadog span.type
1	`span.type`	`span.type` attribute value
2	Span kind server	`web`
3	Span kind client	see 3a/b
3a	Client span kind, `db.system` attribute not found	`http`
3b	Client span kind, `db.system` attribute found	See the table below Mapping OpenTelemetry database system type to Datadog span type
4	None of above conditions were fulfilled	`custom`

Mapping OpenTelemetry database system type to Datadog span type

In the table above, if a span is a “client” kind and contains db.system attribute, the following mapping applies for the span type in Datadog. Setting a span.type attribute on your span overrides this logic.

`db.system`	Datadog span.type
SQL Type DBMS (listed below)	`sql`
`adabas`	`sql`
`cache`	`sql`
`clickhouse`	`sql`
`cloudscape`	`sql`
`cockroachdb`	`sql`
`coldfusion`	`sql`
`db2`	`sql`
`derby`	`sql`
`edb`	`sql`
`firebird`	`sql`
`firstsql`	`sql`
`filemaker`	`sql`
`hanadb`	`sql`
`h2`	`sql`
`hsqldb`	`sql`
`informix`	`sql`
`ingres`	`sql`
`instantdb`	`sql`
`interbase`	`sql`
`mariadb`	`sql`
`maxdb`	`sql`
`mssql`	`sql`
`mysql`	`sql`
`netezza`	`sql`
`oracle`	`sql`
`other_sql`	`sql`
`pervasive`	`sql`
`pointbase`	`sql`
`postgresql`	`sql`
`progress`	`sql`
`redshift`	`sql`
`sqlite`	`sql`
`sybase`	`sql`
`teradata`	`sql`
`vertica`	`sql`
Other DB types	see below
`cassandra`	`cassandra`
`couchbase`	`db`
`couchdb`	`db`
`cosmosdb`	`db`
`dynamodb`	`db`
`elasticsearch`	`elasticsearch`
`geode`	`db`
`hive`	`db`
`memcached`	`memcached`
`mongodb`	`mongodb`
`opensearch`	`opensearch`
`redis`	`redis`
any `db.system` value not listed above	`db`

Metrics attribute mapping

For metrics, by default, Datadog only maps the OpenTelemetry resource attributes listed in the previous sections to Datadog metric tags. To map all resource attributes to tags, enable the metrics::resource_attributes_as_tags setting:

exporters:
  datadog:
    # Other configuration goes here...
    metrics:
      # Add all resource attributes as tags for metrics
      resource_attributes_as_tags: true

otlp_config:
  # Other configuration goes here...
  metrics:
    # Add all resource attributes as tags for metrics
    resource_attributes_as_tags: true

Enabling this option adds both the OpenTelemetry resource attributes and the Datadog semantic conventions to the metric tags.