search

gomods / athens

A Go module datastore and proxy
https://docs.gomods.io
MIT License
4.38k stars 491 forks source link

Move athens to opentelemetry #1771

Open manugupt1 opened 2 years ago

manugupt1 commented 2 years ago

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):

Additional context Add any other context about the problem here.

jamestelfer commented 3 months ago

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:

matt0x6F commented 3 months ago

@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 commented 1 month ago

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.

https://github.com/gomods/athens/blob/bde4952614928964b02617a404df4f4c46bc9b62/pkg/observ/observ.go#L91-L93

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