For anyone interested in learning how to use Open Telemetry for distributed tracing in go, I recently made a demo app to share with some friends: https://github.com/michaelperel/otel-demo . To run, clone it & docker-compose up
51: Start a span. Equivalent to one line of log
60: Add a event. Equivalent to one log
69: Set attribute. This retroactively add attribute to whole span since the start. While log don't have exact same effect, one line of log can be used here.
74: RecordError. Equivalent to one log
I haven't compare amount of code to setup a proper logger which connected to correct infra with amount of code to setup otel yet. Still, I don't think it gonna make much difference.
In general, I won't mind either approach if I get a great visualizer. The main reason I would choose OpenTelemetry is I get trace visualizers for free and I can switch to better visualizer anytime that I want.
Your counterexample is misleading, because a single simplistic function call is what happens in most of the code, e.g. creating spans for an arbitrary point in the code is like, 1 function call[1] after setup. I don't see anything egregious here. Of course, you also have to record where the span ends, but that's part of the game you're playing when you move beyond logs. You have to record that.
What you're probably looking at is all the boilerplate set up, e.g. configuring the provider and backend to point to the right stuff. It reminds me of SL4J, which isn't actually an insult. It's just boilerplate, because people want a lot out of their logging and tracing systems.
Demo applications like this are often easily misleading because there are only like 50 lines of "business logic" and 50 lines of tracing setup, so it makes it seem like the tracing is excessively hard. But those two things don't scale the same way. In a large application where tracing is really valuable, you'll have 100,000 lines of business logic, and still only 50 (or maybe like 100) lines of tracing setup, per application.[2] Actual usage at the call sites remains only a line or two in most cases, and easy to add as you need, where you need it, just like a logger.
It is also worth noting in other ecosystems like when I played with tokio_trace, I found integrating tracing easy, even at the very start. So some of this definitely involves the "philosophy" of the client library.
Great, so now link each request across services, combined with the timings of each individual component within each service. LogInsights is for logging, not tracing. Logging is not a replacement for tracing.
