Open lmolkova opened 7 months ago
With regards to representing multiple words, can a product's branding provide a guide? For example, use dynamodb
, couchdb
, and cosmos_db
because they are respectively branded DynamoDB, CouchDB, and Cosmos DB.
It would be nice if whatever the enum is, e.g. cosmosdb
, that is also the namespace, e.g. db.cosmosdb.*
, for product-specific attributes
do we think we need mssqlcompact
? that doesn't seem like something we'd necessarily know from the client side, and on the server side it could potentially be a resource attribute describing the "edition"
SQL Server Compact runs in-process rather than as a network service, so yes, the application should know it's using that. It's no longer supported by Microsoft, but https://github.com/open-telemetry/opentelemetry-specification/pull/3105 shows it's still used.
Based on the messaging SIG discussion on 6/13, none of the controversial systems are part of the initial stability (kafka + RabbitMQ), so removing the stability blocker label.
We should provide a guidance on product/project name being fully qualified (or not). We should keep the same pattern in different semconvs. Examples of inconsistencies:
db.cosmosdb
(Azure),db.dynamodb
(AWS),db.couchdb
(under Apache umbrella),db.spanner
(GCP),db2
(IBM),hanadb
(SAP HANA) etc and corresponding values in thedb.system
enumaws_sqs
,gcp_pubsub
,azure_servicebus
in themessaging.system
enumWe should provide a guidance on how to represent multiple words:
couchdb
) (##599)messaging.aws_sqs.destination.custom_attr
vsmessaging.aws.sqs.destination.custom_attr
)We should require consistency across signals:
db.system
andmessaging.system
Misc discrepancies:
mssqlcompact
(Microsoft SQL Server Compact) should probably becomemssql_compact
[Update] Other attributes that have the same problem: