cloudzilla Discussions #42

RFC: Should we add OpenTelemetry tracing to the git transport layer? #42

malith started this discussion 3 replies Q&A observabilityrfc
Answered — daisy's reply was marked as the answer.
M malith started the discussion

Our git transport layer — both the HTTP smart protocol and the SSH server — is entirely pure Go, which gives us a clean place to add instrumentation without shelling out to a git binary.

I'd like opinions on wrapping OpenTelemetry spans around pack negotiation, ref advertisement, and the SSH auth handshake. Questions before anyone writes code:

  • Do we export to an OTLP collector, or keep traces in-process behind a debug flag?
  • Is the per-request span overhead acceptable on the hot push/fetch path?
  • Should this wait until after v1.0?

Not committing to anything yet — looking for a steer.

+

3 replies

D daisy Answer replied

Strong +1 on keeping traces in-process behind a debug flag to start. An OTLP exporter is a config surface we'd have to support forever; a flag we can iterate on freely.

+
Marked as answer
Y yumi replied

The overhead worry is real for fetch. Could we sample — trace 1 in N pack negotiations rather than every one? That keeps the hot path cheap and still surfaces the slow outliers.

+
M malith replied

Good steer, both. Plan: in-process spans behind a debug flag, with sampling on the fetch path. I'll write it up as a post-v1.0 item and link a tracking issue here.

+