[OPIK-1005] OpenTelemetry Traces ingestion endpoint

[ldaugusto]

Details

Creates a new ingestion way for Opik, using OpenTelemetry API (for now, just /traces). This way libraries like pydantic.ai and smolagent can send spans to Opik by setting some environmental variables like

(for local)

export OPENAI_API_KEY='xxx'
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:5173/api/v1/private/otel
export OTEL_EXPORTER_OTLP_HEADERS='projectName=Demo Project'

(for cloud environments)

export OPENAI_API_KEY='xxx'
export OTEL_EXPORTER_OTLP_ENDPOINT=https://${COMET_SERVER}/opik/api/v1/private/otel
export OTEL_EXPORTER_OTLP_HEADERS='Authorization=xxx,projectName=xxx;Comet-Workspace=xxx'

Unlike Opik, OpenTelemetry (otel) has no concept of a formal Trace: their trace_id is only a single column that all spans have in common for a single fetch operation. To make it opik-able, we're cloning the root span into a (opik) Trace, very much like python sdk. The whole span payload for now is inserted as 'input' as the parsing is library-dependable. We will bit a parser mapping in a future PR.

The ids where a problem, as otel uses 128-bit random ints for trace_id and 64-bit random ints for span_id. The batchs are sent out of order: the root span is sent last (as it needs and 'end_time'), so we can't tell what's going to be the UUIDv7 for the trace by the first batch, so we truncate span time by the day as a 'prediction' for what the opik trace id would be.

In a future PR we will look for a better way to translate otel ids into opik ids.

Issues

Resolves #

Testing

Documentation

[Lothiraldan]

@ldaugusto I tested the endpoint locally with smolagents and it is working good, good job!

[thiagohora]

LGTM!