Overview

OpenTelemetry provides a broad set of semantic conventions for telemetry data, but it lacks a consistent and unified way to represent operations across different telemetry types. This inconsistency can lead to high-cardinality span names and fragmented observability data, making it difficult to analyze and troubleshoot issues effectively.

Dash0 fills this gap through the concept of operation. Whether dealing with HTTP requests, messaging systems, databases, or cloud services, Dash0 assigns meaningful operation names to spans and derived metrics. Operation names help you detect performance issues, set alerts, and improve observability by reducing high-cardinality attributes like span names, into more generalized, consistent values.

Key Takeaways

Standardized naming: Dash0 automatically assigns dash0.operation.name and dash0.operation.type attributes to spans, logs and metric data points through rules defined on the basis of OpenTelemetry semantic conventions.
Support for operation name override: Users can override operation names by setting the desired value to the dash0.operation.name attribute on spans, logs and metric data points, before the data is sent to Dash0. The dash0.operation.type attributes cannot currently be overwritten.
Reduced cardinality issues: By grouping spans into meaningful operations, Dash0 avoids excessive cardinality that can make analysis more difficult.
Cross-service consistency: The same operation names are set on telemetry with comparable attributes, ensuring consistency across your data.

Operation rules

During telemetry ingestion, Dash0 automatically assigns operation names following a structured set of rules. These attributes are added only if dash0.operation.name attribute is not already present in the incoming telemetry, ensuring users can override them when necessary.

If you specify the dash0.operation.name attribute, Dash0 will still try to calculate a value for dash0.operation.type.

Unlike dash0.operation.name, the dash0.operation.type attribute that you send along with your telemetry will be ignored, as Dash0 needs the value to be one of a few supported values.

The operation rules are split into three groups, depending on some matching conditions for span.kind and if the spans are root or not:

Span categories based on OpenTelemetry conventions: span.kind is SERVER, CONSUMER, and it is not a root span.
Root Spans (Spans with no parent): Any root span, regardless of its span.kind.
Fallback Mechanism: Where none of the rules above apply.

If telemetry meets the conditions of a group above, the operation rules within the group are evaluated to define the dash0.operation.type and dash0.operation.name. Find below the exact ruleset.

1. Span categories based on OpenTelemetry conventions:
Spans are categorized using predefined rules, evaluated from top to bottom. The first matching rule determines the operation name. The categorization only applies to non-root spans of span kind SERVER or CONSUMER.

Each rule defines a pattern that constructs the dash0.operation.name using span attributes (e.g., ${http.request.method} ${http.route}). If all required attributes exist, the pattern applies.

The table below outlines these rules based on OpenTelemetry conventions.

Type	Pattern
GraphQL	`${graphql.operation.type} ${graphql.operation.name}`
Object Storage (AWS S3)	`${rpc.method} ${aws.s3.bucket}`
FaaS: Database Trigger	`${faas.document.collection} ${faas.document.operation} ${faas.document.name}`
FaaS: Timer Trigger	`Cron ${faas.cron}`
FaaS: FaaS Name	`${faas.name}`
Databases: AWS DynamoDB	`${rpc.method} ${aws.dynamodb.table_names}`
Database: Name and Statement	`${db.name} ${db.query.text \| db.statement}`
Database: Statement	`${db.query.text \| db.statement}`
Database: Name, Operation, and Table	`${db.name} ${db.operation \| db.operation.name} ${db.collection.name \| db.cassandra.table \| db.sql.table}`
Database: Operation and Table	`${db.operation \| db.operation.name} ${db.collection.name \| db.cassandra.table \| db.sql.table}`
Messaging: Operation Type, Operation Name, and Destination	`${messaging.operation.type} ${messaging.operation.name \| messaging.operation} ${messaging.destination.template \| messaging.destination.name \| messaging.destination_publish.name}`
Messaging: Operation Type and Destination	`${messaging.operation.type} ${messaging.destination.template \| messaging.destination.name \| messaging.destination_publish.name}`
Messaging: Operation and Destination	`${messaging.operation.name \| messaging.operation} ${messaging.destination.template \| messaging.destination.name \| messaging.destination_publish.name}`
Messaging: Type and Name	`${messaging.operation.type} ${messaging.operation.name \| messaging.operation}`
RPC: Service and Method	`${rpc.service} ${rpc.method}`
RPC: System	`${rpc.system}`
HTTP: Route	`${http.request.method \| http.method} ${http.route}`
HTTP: Url	`${http.request.method \| http.method} ${url.path \| http.target \| http.url \| url.full}`

2. Root spans (Spans with no parent)

If none of the rules above apply and span.kind is SERVER, CONSUMER, or INTERNAL, the operation is categorized as HEADLESS.
If span.kind is CLIENT or PRODUCER, its dash0.operation.type is set to UNKNOWN and dash0.operation.name is set to Unknown operation because these outgoing operations lack parent context explaining what triggered them.

3. Fallback Mechanism:

If none of the rules above apply, the span name or metric name itself is used as dash0.operation.name.

FAQs

Can I override operation names?

Yes. If an incoming span already has dash0.operation.name, Dash0 does not override it. This allows users to define their own operation naming schemes when necessary.

Can I override operation types?

Dash0 automatically determines dash0.operation.type based on structured processing rules. Users can override dash0.operation.name, but operation types remain fixed to maintain OpenTelemetry alignment.

Why does my operation have the type Unknown?

An Unknown Operation occurs when a root span has span.kind CLIENT or PRODUCER. These span kinds cannot represent an API invoked on the system; instead, they indicate the trace is malformed and missing the parent span that should describe what API was actually called. This typically happens with scheduled tasks or background workers that lack proper instrumentation, or when trace context propagation fails between services.