Spans in Splunk Observability Cloud 🔗
Spans represent specific operations in and between systems, such as calls that use well-known protocols like HTTP, or database calls.
Spans generated by OpenTelemetry can be annotated with attributes specific to the represented operation. Depending on the protocol and the type of operation, you might need additional information to represent and analyze a span correctly.
It’s also important to unify how attribution works in different languages. This way, you don’t need to learn specifics of a language, and telemetry collected from multilanguage, micro-service environments can still be correlated and cross-analyzed.
Semantic conventions 🔗
The following semantic conventions apply for spans:
General : General semantic attributes that might be used in describing different kinds of operations.
HTTP : For HTTP client and server spans.
Database : For SQL and NoSQL client call spans.
RPC/RMI : For remote procedure call (for example, gRPC) spans.
Messaging : For messaging system spans (queues, publish/subscribe, and so on).
FaaS : For Function as a Service (for example, AWS Lambda) spans.
Exceptions : For recording exceptions associated with a span.
Compatibility : For spans generated by compatibility components. For example, OpenTracing Shim layer.
Learn more about OpenTelemetry in the OpenTelemetry official documentation, such as library-specific semantic conventions for AWS Lambda, AWS SDK, or GraphQL.
Event naming guidelines 🔗
Don’t add a new event with the same name as an event that existed in the past, even if that event has been renamed.
When introducing a new event, check names in all existing schema files to make sure it doesn’t appear as a key of any rename_events section. Keys show old event names in rename operations.