A few weeks ago I gave a talk at JSConf Asia on using the Performance API. Although my talk was primarily about the API, I also talked a bit about tracing. People liked the explanation on tracing, so I thought I’d do a deep dive ✌️
So! Tracing! Tracing is a form of logging. Instead of being unstructured
console.log(), tracing provides extra information about the log. With a trace you’re able to see relationships between logs.
A trace is made up of spans. A span is a log that describes a single piece of work. It normally has a timestamp for the start and end time of the work, and maybe some annotations about a changed state of a given object. It would also have useful information you will want to see when you debug.
A group of spans construct a tree of nodes grouped by their relationship to one another over time.
But how does the grouping of that information happen? There are a two main methods of collecting trace data: in-band and out-of-band collection. In-band collection happens when you pass data along with the headers of your request. For example a server-timing header, or a custom one that you can store and read information from. In out-of-band collection, you write and read information from an API as you move along your trace tree.
g o o d l i n k z .
I learned a bunch of this information through Google’s dapper paper. It’s got good basics on the way they’ve handled tracing implementation.
Similar to Dapper, I’d suggest you to checkout opentracing format.
Chrome recently released a way for you to inspect server timings by using the server-timing header I mentioned above. I haven’t used it myself yet, but it seems like an interesting way to see server timings in the dev tools.
Thanks for viewing everyone ✨ ✌️ If you’d like to see more of my doodles, follow me along on twitter. Also, if you happen to be in Melbourne at JSConf AU, come say hi! I’ll be giving a talk on HTTP/2 in Node.js 💻