And you are here why?

“ You can use logging for everything! ”  —  #CowboyDeveloper Well, technically speaking, the resident  #CowboyDeveloper  is correct, you  can  use logging for everything • Metrics : Print out your data, and cut/paste them from the terminal into Google Sheets. Voila! You can now generate all the charts you need from this data! ( I’m not joking. I know a dude that actually did this! ) • Alerting :  tail -f | grep  on your logs, and if anything  bad  happens, pipe it to sendmail. ( Yes. sendmail was a thing. Don’t ask ) • Monitoring :  tail -f | grep  on your logs across many, many terms. ( One for each server, times the number of things you are looking for ) • Debugging : You know the drill. Throw enough  print()  statements in there, and, with enough hair-pulling, you can figure out the problem. • Tracing : Uhhh, what’s that? ( And, once explained, “solved” by sticking unique IDs into each log statement. Again, don’...

“ 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 be...