feat(spans): Ingest standalone spans

[phacops]

This PR aims to add support for ingesting standalone spans. This will support 3 ways to ingest spans:

• an HTTP endpoint accepting OpenTelemetry spans, encoded as JSON
• an Item of type OtelSpan accepting an OpenTelemetry span, encoded as JSON
• an Item of type Span accepting a span matching the span protocol, encoded as JSON

After we accept those spans, they are converted to a span as the protocol describes it and they each go through the span processor which will:

• normalize
• validate
• extract metrics

They will then be sent to Kafka for storage.

In the end, we're aiming for this except our common format is the span protocol:

[mydea]

Here some OTLP spans I generated from a node-experimental project:

{
   "traceId": "89143b0763095bd9c9955e8175d1fb23",
   "spanId": "e342abb1214ca181",
   "parentSpanId": "0c7a7dea069bf5a6",
   "name": "middleware - fastify -> @fastify/multipart",
   "kind": 1,
   "startTimeUnixNano": 1697620454980000000,
   "endTimeUnixNano": 1697620454980078800,
   "attributes": [
     {
       "key": "fastify.type",
       "value": {
         "stringValue": "middleware"
       }
     },
     {
       "key": "plugin.name",
       "value": {
         "stringValue": "fastify -> @fastify/multipart"
       }
     },
     {
       "key": "hook.name",
       "value": {
         "stringValue": "onResponse"
       }
     },
     {
       "key": "sentry.sample_rate",
       "value": {
         "intValue": 1
       }
     },
     {
       "key": "sentry.parentSampled",
       "value": {
         "boolValue": true
       }
     }
   ],
   "droppedAttributesCount": 0,
   "events": [],
   "droppedEventsCount": 0,
   "status": {
     "code": 0
   },
   "links": [],
   "droppedLinksCount": 0
 }

{
  "traceId": "89143b0763095bd9c9955e8175d1fb23",
  "spanId": "0c7a7dea069bf5a6",
  "name": "GET /bottles",
  "kind": 2,
  "startTimeUnixNano": 1697620454925000000,
  "endTimeUnixNano": 1697620454979637200,
  "attributes": [
    {
      "key": "http.url",
      "value": {
        "stringValue": "http://localhost:4000/bottles"
      }
    },
    {
      "key": "http.host",
      "value": {
        "stringValue": "localhost:4000"
      }
    },
    {
      "key": "net.host.name",
      "value": {
        "stringValue": "localhost"
      }
    },
    {
      "key": "http.method",
      "value": {
        "stringValue": "GET"
      }
    },
    {
      "key": "http.scheme",
      "value": {
        "stringValue": "http"
      }
    },
    {
      "key": "http.target",
      "value": {
        "stringValue": "/bottles"
      }
    },
    {
      "key": "http.user_agent",
      "value": {
        "stringValue": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
      }
    },
    {
      "key": "http.flavor",
      "value": {
        "stringValue": "1.1"
      }
    },
    {
      "key": "net.transport",
      "value": {
        "stringValue": "ip_tcp"
      }
    },
    {
      "key": "sentry.sample_rate",
      "value": {
        "intValue": 1
      }
    },
    {
      "key": "sentry.origin",
      "value": {
        "stringValue": "auto.http.otel.http"
      }
    },
    {
      "key": "net.host.ip",
      "value": {
        "stringValue": "::1"
      }
    },
    {
      "key": "net.host.port",
      "value": {
        "intValue": 4000
      }
    },
    {
      "key": "net.peer.ip",
      "value": {
        "stringValue": "::1"
      }
    },
    {
      "key": "net.peer.port",
      "value": {
        "intValue": 60502
      }
    },
    {
      "key": "http.status_code",
      "value": {
        "intValue": 500
      }
    },
    {
      "key": "http.status_text",
      "value": {
        "stringValue": "INTERNAL SERVER ERROR"
      }
    },
    {
      "key": "http.route",
      "value": {
        "stringValue": "/bottles"
      }
    }
  ],
  "droppedAttributesCount": 0,
  "events": [],
  "droppedEventsCount": 0,
  "status": {
    "code": 2
  },
  "links": [],
  "droppedLinksCount": 0
 }

[jjbayer]

Good stuff! Long-term we'll need a rate limiting and dynamic sampling strategy for these spans, but as long as the ingestion's feature-flagged we can ship without it IMO.

[jjbayer]

Almost there!

[jjbayer]

This check means that we only accept spans for which the SDK sets exclusive_time. So only from a Sentry SDK, not any other client.

[phacops]

I changed it so the fallback is to calculate the duration of the span using start and end timestamps. Like this, the validation still works as intended.

[jjbayer]

See other comment:

This is ultimately a product decision, but I don't think we should assume that a span has zero child spans just because the sentry-specific "exclusive time" attribute is missing. I'd rather drop these spans for now than ingest incorrect data for them.

[jjbayer]

TODO: Why is there a mapping for this?

[phacops]

I thought it might be a good idea to have it but thinking about it more, it's useless, so I removed it.

[jjbayer]

Is .contains really what we want here? Don't we want to check for a specific key (or a set of keys)?

[phacops]

We can check for 2 specific keys indeed, I thought that'd be fine to just use contains instead of repeating nearly exact key names.

[jjbayer]

This is ultimately a product decision, but I don't think we should assume that a span has zero child spans just because the sentry-specific "exclusive time" attribute is missing. I'd rather drop these spans for now than ingest incorrect data for them.

Suggested change

	if exclusive_time_ms == 0f64 {
	exclusive_time_ms =
	(from.end_time_unix_nano - from.start_time_unix_nano) as f64 / 1e6f64;
	}

[phacops]

I think I'd rather keep them for now. Obviously, this is something that will change as we understand how to use this better from an OTLP point of view but I wouldn't reject them right now.

This is not meant to be used right away by customers and what we do with this field has to change before we release it but it's important to let us ingest some data, maybe a bit wrong at first, to continue testing.

[jjbayer]

See other comment:

This is ultimately a product decision, but I don't think we should assume that a span has zero child spans just because the sentry-specific "exclusive time" attribute is missing. I'd rather drop these spans for now than ingest incorrect data for them.

[jjbayer]

I still have some reservations around the handling of "exclusive time", but other than that, this looks good to me!

[phacops]

I understand your reservations, I don't think we'll stick with this but it's important to get us started by not rejecting those spans until we have a solution. We'll likely have to talk to a few people to see what we'll need to do here.