Docs » Instrument back-end applications to send spans to Splunk APM » Spans in Splunk Observability Cloud

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.

In OpenTelemetry spans can be created freely, and it’s up to the user to annotate them with attributes specific to the represented operation. Depending on the protocol and the type of operation, you’ll need additional information to represent and analyze a span correctly in monitoring systems.

It’s also important to unify how this attribution is made in different languages. This way, you won’t need to learn specifics of a language, and telemetry collected from multi-language, micro-service environments can still be easily correlated and cross-analyzed.

Semantic conventions 🔗

The following semantic conventions for spans are defined:

  • General: General semantic attributes that may 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 (queues, publish/subscribe, etc.) spans.

  • 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 https://github.com/open-telemetry, such as library-specific semantic conventions for AWS Lambda, AWS SDK, or GraphQL.

Event naming guidelines 🔗

Never 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.