When we started our endeavor into modeling the data we collect as OpenTelemetry primitives, we were excited to see a Span.Kind field. Initially, we thought we could use this field to provide type annotations to our telemetry in order to help our backend ingest data and apply specific behavior. Unfortunately for us, that is not Span.Kind’s intended purpose.
Span.Kind is specifically used to hint at the relationships within a distributed trace. Its primary goal is to reflect whether the Span is a “logical” child or parent when a trace crosses process boundaries.
We were looking for a way to model any data that has a duration as a Span. When this data arrived at our backend, having an explicit structure for the kinds of spans we expect would let us perform specific analysis and aggregation.
For example, if we encounter a span that represents a network request, we want to make sure we can pull out the URL path and response status code attributes to analyze how many 404s the client receives for each route it hits. Mobile apps are generally used in predictable ways, as prescribed by both the app developer and the app ecosystem, so it’s easy to create a relatively short list that covers the majority of mobile use cases.