Operation Names
In Dash0, "operation names" provide a structured way to categorize and analyze application behaviors across various APIs and services.
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.nameanddash0.operation.typeattributes 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.nameattribute on spans, logs and metric data points, before the data is sent to Dash0. Thedash0.operation.typeattributes 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, dash0.operation.type that you send along with your telemetry will be ignored, as Dash0 needs the value to be one of a few supported values.
1. Root spans (Spans with no parent)
- If
span.kindis SERVER, CONSUMER, or INTERNAL, the operation is categorized as a Headless Operation. - If
span.kindis CLIENT or PRODUCER, it is labeled as Unknown Operation.
2. 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.
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} |
3. Fallback Mechanism:
- If no specific rule applies, the span name or metric name itself is used as
dash0.operation.name. dash0.operation.typeis left unset unless explicitly determined.
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 is my operation “Unknown”?
If a span is a root span but does not match a defined pattern, it is classified as an “Unknown Operation.” This typically occurs for client or producer spans that do not have enough contextual information to determine a clear operation name.
Last updated: March 19, 2025