Move athens to opentelemetry

[manugupt1]

Describe the bug
Athens already supports tracing via opencensus; but that is no longer supported and deprecated

Expected behavior
Move to opentelemtry in a non-breaking way.

Environment (please complete the following information):

• OS: [e.g. Linux 64bit]
• Go version :
• Proxy version :
• Storage (fs/mongodb/s3 etc.) :

Additional context
Add any other context about the problem here.

[jamestelfer]

Looking at this issue, it seems that a switch to OpenTelemetry could be made in a manner that was non-breaking, but with the possibility of changing the way traces are emitted.

How much change is acceptable?

Given that the OpenCensus libraries are not maintained (the Go library is archived), making a complete switch rather than using a bridge might be the way to go.

See also:

• https://opentelemetry.io/blog/2023/sunsetting-opencensus/#how-to-migrate-to-opentelemetry

[matt0x6F]

@jamestelfer OpenCensus has been dead for 9 months now. I feel okay about breaking Athens' compatibility with it. I'm willing to hear arguments against it but I think it's a move in the right direction to issue a new minor version with OpenTelemetry when that code is available.

[jamestelfer]

I had a look around at this issue to see what might be necessary, and have recently implemented OTEL in a different service to gain some familiarity.

The following are my thoughts on the implementation (though note that I am not a repository maintainer, just a random person on the Internet).

The current code surface for writing to spans is quite small: the StartSpan API is used by other components to interact with tracing.

athens/pkg/observ/observ.go

Lines 91 to 93 in bde4952

	func StartSpan(ctx context.Context, op string) (context.Context, *trace.Span) {
	return trace.StartSpan(ctx, op)
	}

If this method returned an interface supporting the methods used on the span instead of a direct pointer, an Open Telemetry exporter can be set up as a different option to RegisterExporter. I suggest supporting GRPC and or HTTP channels for telemetry, making the target URL for the chosen variant configurable.

Those using Open Telemetry can direct their output directly to their provider (in the case of say, Honeycomb or Jaeger), or introduce the Open Telemetry collector agent and configure it appropriately for their service. This may be a sidecar image, or another process on the host. Other providers like Datadog support OLTP on their own agents.

Either way, instead of directly supporting different vendors in this project, they would effectively be deprecated in favour of OLTP support.

After a period of months, the old implementations can be removed. This gives users of this server an opportunity to make the switch prior to the removal.

Happy for any thoughts or refinements from maintainers!

@ctgardner FYI