Semantic Conventions for Database Client Calls

Status: Experimental

Warning Existing Database instrumentations that are using v1.20.0 of this document (or prior):

  • SHOULD NOT change the version of the networking attributes that they emit until the HTTP semantic conventions are marked stable (HTTP stabilization will include stabilization of a core set of networking attributes which are also used in Database instrumentations).
  • SHOULD introduce an environment variable OTEL_SEMCONV_STABILITY_OPT_IN in the existing major version which is a comma-separated list of values. The only values defined so far are:
    • http - emit the new, stable networking attributes, and stop emitting the old experimental networking attributes that the instrumentation emitted previously.
    • http/dup - emit both the old and the stable networking attributes, allowing for a seamless transition.
    • The default behavior (in the absence of one of these values) is to continue emitting whatever version of the old experimental networking attributes the instrumentation was emitting previously.
  • SHOULD maintain (security patching at a minimum) the existing major version for at least six months after it starts emitting both sets of attributes.
  • SHOULD drop the environment variable in the next major version (stable next major version SHOULD NOT be released prior to October 1, 2023).

Span kind: MUST always be CLIENT.

The span name SHOULD be set to a low cardinality value representing the statement executed on the database. It MAY be a stored procedure name (without arguments), DB statement without variable arguments, operation name, etc. Since SQL statements may have very high cardinality even without arguments, SQL spans SHOULD be named the following way, unless the statement is known to be of low cardinality: <db.operation> <>.<db.sql.table>, provided that db.operation and db.sql.table are available. If db.sql.table is not available due to its semantics, the span SHOULD be named <db.operation> <>. It is not recommended to attempt any client-side parsing of db.statement just to get these properties, they should only be used if the library being instrumented already provides them. When it’s otherwise impossible to get any meaningful span name, or the tech-specific database name MAY be used.

Connection-level attributes

These attributes will usually be the same for all operations performed over the same database connection. Some database systems may allow a connection to switch to a different db.user, for example, and other database systems may not even have the concept of a connection at all.

AttributeTypeDescriptionExamplesRequirement Level
db.systemstringAn identifier for the database management system (DBMS) product being used. See below for a list of well-known identifiers.other_sqlRequired
db.connection_stringstringThe connection string used to connect to the database. It is recommended to remove embedded credentials.Server=(localdb)\v11.0;Integrated Security=true;Recommended
db.userstringUsername for accessing the database.readonly_user; reporting_userRecommended
network.transportstringOSI Transport Layer or Inter-process Communication method. The value SHOULD be normalized to lowercase.tcp; udpRecommended
network.typestringOSI Network Layer or non-OSI equivalent. The value SHOULD be normalized to lowercase.ipv4; ipv6Recommended
server.addressstringName of the database host.example.comConditionally Required: See alternative attributes below.
server.portintLogical server port number80; 8080; 443Conditionally Required: [1]
server.socket.addressstringPhysical server IP address or Unix socket address. If set from the client, should simply use the socket’s peer address, and not attempt to find any actual server IP (i.e., if set from client, this may represent some proxy server instead of the logical server). below
server.socket.portintPhysical server port.16456Recommended: If different than server.port.

[1]: If using a port other than the default port for this DBMS and if server.address is set.

Additional attribute requirements: At least one of the following sets of attributes is required:

db.system has the following list of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used.

other_sqlSome other SQL database. Fallback only. See notes.
mssqlMicrosoft SQL Server
mssqlcompactMicrosoft SQL Server Compact
oracleOracle Database
db2IBM Db2
redshiftAmazon Redshift
hiveApache Hive
hsqldbHyperSQL DataBase
progressProgress Database
maxdbSAP MaxDB
hanadbSAP HANA
cacheInterSystems Caché
adabasAdabas (Adaptable Database System)
derbyApache Derby
pervasivePervasive PSQL
coldfusionColdFusion IMQ
cassandraApache Cassandra
hbaseApache HBase
cosmosdbMicrosoft Azure Cosmos DB
dynamodbAmazon DynamoDB
geodeApache Geode
spannerCloud Spanner

Notes and well-known identifiers for db.system

The list above is a non-exhaustive list of well-known identifiers to be specified for db.system.

If a value defined in this list applies to the DBMS to which the request is sent, this value MUST be used. If no value defined in this list is suitable, a custom value MUST be provided. This custom value MUST be the name of the DBMS in lowercase and without a version number to stay consistent with existing identifiers.

It is encouraged to open a PR towards this specification to add missing values to the list, especially when instrumentations for those missing databases are written. This allows multiple instrumentations for the same database to be aligned and eases analyzing for backends.

The value other_sql is intended as a fallback and MUST only be used if the DBMS is known to be SQL-compliant but the concrete product is not known to the instrumentation. If the concrete DBMS is known to the instrumentation, its specific identifier MUST be used.

Back ends could, for example, use the provided identifier to determine the appropriate SQL dialect for parsing the db.statement.

When additional attributes are added that only apply to a specific DBMS, its identifier SHOULD be used as a namespace in the attribute key as for the attributes in the sections below.

Call-level attributes

These attributes may be different for each operation performed, even if the same connection is used for multiple operations. Usually only one will be used per connection though.

AttributeTypeDescriptionExamplesRequirement Level
db.namestringThis attribute is used to report the name of the database being accessed. For commands that switch the database, this should be set to the target database (even if the command fails). [1]customers; mainConditionally Required: If applicable.
db.statementstringThe database statement being executed.SELECT * FROM wuser_table; SET mykey "WuValue"Recommended: [2]
db.operationstringThe name of the operation being executed, e.g. the MongoDB command name such as findAndModify, or the SQL keyword. [3]findAndModify; HMSET; SELECTConditionally Required: If db.statement is not applicable.

[1]: In some SQL databases, the database name to be used is called “schema name”. In case there are multiple layers that could be considered for database name (e.g. Oracle instance name and schema name), the database name to be used is the more specific layer (e.g. Oracle schema name).

[2]: Should be collected by default only if there is sanitization that excludes sensitive information.

[3]: When setting this to an SQL keyword, it is not recommended to attempt any client-side parsing of db.statement just to get this property, but it should be set if the operation name is provided by the library being instrumented. If the SQL statement has an ambiguous operation, or performs more than one operation, this value may be omitted.

Semantic Conventions for specific database technologies

More specific Semantic Conventions are defined for the following database technologies:

  • AWS DynamoDB: Semantic Conventions for AWS DynamoDB.
  • Cassandra: Semantic Conventions for Cassandra.
  • Cosmos DB: Semantic Conventions for Microsoft Cosmos DB.
  • CouchDB: Semantic Conventions for CouchDB.
  • Elasticsearch: Semantic Conventions for Elasticsearch.
  • GraphQL: Semantic Conventions for GraphQL Server.
  • HBase: Semantic Conventions for HBase.
  • MongoDB: Semantic Conventions for MongoDB.
  • MSSQL: Semantic Conventions for MSSQL.
  • Redis: Semantic Conventions for Redis.
  • SQL: Semantic Conventions for SQL databases.