Tracing Is Not “Just Logging”!

“I already have enough logging, tracing is just redundant”
 — #CowboyDeveloper 

Logging works — oh yes it does — but only up to a point. The moment you start dealing with interactions that span systems and services all hell breaks loose. Causality becomes increasingly hard to track down (which request caused this response?), and “before-after” relationships are just a PITA. With tracing, you can — trivially — isolate the service and the relevant span, allowing you to drill into the behavior of your system without worrying about other concurrent requests cluttering your analysis.
(And no, don’t get started with timestamps. These are distributed systems we are talking about!)

Enter OpenTracing, with which you can track the journey taken by the request as it bounces through your increasingly elaborate service. The general idea started with the Dapper project at Google, which inspired the OSS Zipkin, and has ended with it becoming part of the CNCF.

The tricky part with distributed tracing is that it requires a lot of work — you have to instrument everything — the services you write, the OSS components that you use in these services, the higher-level business logic, everything. It’s doable, but it is a ridiculous maintenance headache, and historically only worth it if your system was large/complex enough to justify it.

OpenTracing changes this equation, by separating out the Instrumentationfrom the Implementation. Authors can instrument their own code based on this standard (and yes, most people are doing it!) and not have to actually bind to any specific vendor, with the end-user choosing which tooling to use to actually do the tracing!

A pretty cool implementation thereof is Uber’s Jaeger, with an excellent demo/walkthrough here.

About the only reason to not be using tracing in your distributed tracing is that you didn’t know it existed — and now you do. 
Don’t be a #CowboyDeveloper. Don’t reinvent the wheel (or worse, ignore the wheel entirely!).