OpenTelemetry Semantic Conventions and Datadog Conventions

Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

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 conventionDatadog convention
deployment.environment 1env
deployment.environment.name 2env
service.nameservice
service.versionversion

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 conventionDatadog convention
container.idcontainer_id
container.namecontainer_name
container.image.nameimage_name
container.image.tagimage_tag

Read more about Containers semantic conventions in the OpenTelemetry documentation.

Additional cloud provider-specific attributes are also mapped.

Cloud

OpenTelemetry conventionDatadog convention
cloud.providercloud_provider
cloud.regionregion
cloud.availability_zonezone

ECS

OpenTelemetry conventionDatadog convention
aws.ecs.task.familytask_family
aws.ecs.task.arntask_arn
aws.ecs.cluster.arnecs_cluster_name
aws.ecs.task.revisiontask_version
aws.ecs.container.arnecs_container_name

Kubernetes

OpenTelemetry conventionDatadog convention
k8s.container.namekube_container_name
k8s.cluster.namekube_cluster_name
k8s.deployment.namekube_deployment
k8s.replicaset.namekube_replica_set
k8s.statefulset.namekube_stateful_set
k8s.daemonset.namekube_daemon_set
k8s.job.namekube_job
k8s.cronjob.namekube_cronjob
k8s.namespace.namekube_namespace
k8s.pod.namepod_name

Kubernetes labels

Kubernetes conventionDatadog convention
app.kubernetes.io/namekube_app_name
app.kubernetes.io/instancekube_app_instance
app.kubernetes.io/versionkube_app_version
app.kuberenetes.io/componentkube_app_component
app.kubernetes.io/part-ofkube_app_part_of
app.kubernetes.io/managed-bykube_app_managed_by

HTTP

OpenTelemetry conventionDatadog convention
client.addresshttp.client_ip
http.response.body.sizehttp.response.content_length
http.response.header.<header-name>http.response.headers.<header-name>
http.response.status_codehttp.status_code
http.request.body.sizehttp.request.content_length
http.request.header.referrerhttp.referrer
http.request.header.<header-name>http.request.headers.<header-name>
http.request.methodhttp.method
http.routehttp.route
network.protocol.versionhttp.version
server.addresshttp.server_name
url.fullhttp.url
user_agent.originalhttp.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 AttributeDatadog span.type
1span.typespan.type attribute value
2Span kind serverweb
3Span kind clientsee 3a/b
3aClient span kind, db.system attribute not foundhttp
3bClient span kind, db.system attribute foundSee the table below Mapping OpenTelemetry database system type to Datadog span type
4None of above conditions were fulfilledcustom

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.systemDatadog span.type
SQL Type DBMS (listed below)sql
adabassql
cachesql
clickhousesql
cloudscapesql
cockroachdbsql
coldfusionsql
db2sql
derbysql
edbsql
firebirdsql
firstsqlsql
filemakersql
hanadbsql
h2sql
hsqldbsql
informixsql
ingressql
instantdbsql
interbasesql
mariadbsql
maxdbsql
mssqlsql
mysqlsql
netezzasql
oraclesql
other_sqlsql
pervasivesql
pointbasesql
postgresqlsql
progresssql
redshiftsql
sqlitesql
sybasesql
teradatasql
verticasql
Other DB typessee below
cassandracassandra
couchbasedb
couchdbdb
cosmosdbdb
dynamodbdb
elasticsearchelasticsearch
geodedb
hivedb
memcachedmemcached
mongodbmongodb
opensearchopensearch
redisredis
any db.system value not listed abovedb

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.

Further reading