feat(tools): consolidate OTLP routes to prioritize standard v1 endpoints

[MichaelDoyle]

I tried to hook up gemini-cli (which has migrated to Otel) to our telemetry server and it immediately blew up due to allocation of "large" strings. The culprit was that the /api/otlp/:parentTraceId/:parentSpanId endpoint matched all of the standard Otlp endpoints by accident, creating one giant trace with the traceId v1.

Speaking with SamB, we don't actually need this endpoint.

• Remove experimental /api/otlp/:parentTraceId/:parentSpanId endpoint, because:

  • It conflicts with the standard OTel endpoints
  • It results in very very large traces that break

• Support the standard OTel endpoints. We must add these, or we'll not be able to accept standard Otel traffic.

  • v1/traces
  • v1/logs
  • v1/metrics

For now, the same route handles everything, just as before. But ideally, we'd want to break it out in the very near future.

Checklist (if applicable):

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (manually, unit tested, etc.)
• Docs updated (updated docs or a docs bug required)

Screenshot

See also

• Gemini CLI Otel - https://github.com/google-gemini/gemini-cli/pull/20237/changes
• Standard Otel endpoints: https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/#otel_exporter_otlp_endpoint

[gemini-code-assist]

Code Review

This pull request consolidates multiple OTLP endpoints into a single handler and refactors trace and log processing to use schema-based parsing and individual span broadcasting. Feedback was provided regarding the span broadcasting logic, noting that it should emit both start and end events and sort them chronologically to maintain consistency with other endpoints and avoid potential UI display issues.