Best practices for adding OTEL to a codebase while avoiding messy/verbose code?

[C-Loftus]

Hello, I am working on adding otel to an open source CLI tool written in golang. I trying to use otel since I want to get timing info using traces from multiple concurrent operations and plot it with jaeger.

In short, I am finding the golang otel semantics to require passing lots of ctx objects around in sections of the code that ordinarily wouldn't need it. I am trying to find ways of reducing this verbosity.

Questions:

1. Is it possible to reduce otel client verbosity in golang using global state?
   • (I am writing an otherwise stateless cli tool so global vals to reduce boilerplate is fine with me)
   • I saw there is Tracer.start_as_current_span in the Python otel client
     • This appears to auto inject the context somehow dynamically and thus doesn't need to pass around context objects. I am wondering if there is an equivalent for golang
   • In golang it appears the Tracer.start method requires a ctx object to create a subspan so if I want to create subspans I need pass the parent's ctx object to every child function until I reach the intended start of the subspan, even if the function doesn't use a ctx for any other reason
2. Are there any other reference codebases or tutorials I should be referencing when integrating otel for golang?
   • The API docs are very useful but are more descriptive than prescriptive for best practices
   • The github examples are very useful to reference but I was hoping to find something of a bigger codebase with less of a focus on web servers / more general best practice info

[XSAM]

In short, I am finding the golang otel semantics to require passing lots of ctx objects around in sections of the code that ordinarily wouldn't need it. I am trying to find ways of reducing this verbosity.

In Go, explicitly passing ctx objects is the convention that every method with context info should have. https://go.dev/blog/context#conclusion

Tracer.start method uses context to retrieve the current span, so it can create a new span with the same trace_id.

I am not familiar with the otel implementation in Python, but I guess it uses thread-local storage to propagate the current span info (implicitly passing ctx objects). So users don't need to specify the context.

There is no such thing as thread-local storage in Go. Even if it has, I wouldn't prefer this style, as thread-local storage does not work well in an async manner because it would require hard work to carefully maintain the correct context attached to the thread when switching jobs between threads. From my experience in OTel Java, which also uses thread-local storage, the result would usually become bad if the instrumentation with async didn't deal carefully with the context propagation. And, if something went wrong, it would be difficult for developers to debug.

[C-Loftus]

Thank you for your reply, that makes sense. Could you clarify if there are any patterns that would be reasonable for me as a user to explore to get around this? (i.e. some sort of global state or sharing the same ctx across a struct?) Although yes I agree adding an additional argument is the common pattern, it does strike me as a bit unfortunate since I would need to change all my function definitions and if I don't need otel I am just going to be passing in a semantically meaningless context.background() value.

It is understandable if changing all the methods is easier than trying to deal with global context or something of that nature, just wanted to be sure that there aren't any other ways.

Thank you very much

[dmathieu]

As Sam mentions, Go provides no way to pass the span context around without the use of a ctx. That's how the language is designed, and we can't relly do anything about that.
Hence the need to pass a context around.

I would avoid storing the context as a struct argument though.
See https://go.dev/blog/context-and-structs

There are plenty more documentation on the use of context, either on the official Go blog or elsewhere.
This one is a good starting point: https://go.dev/blog/context