Simplifying assumptions - adamvinueza/libtrace GitHub Wiki

Honeycomb does a number of things with its tracing library that I can't be troubled to implement here, mainly because it would take too much time and aren't central to what I'm trying to accomplish.

1. Honeycomb uses what it calls "rollup fields" for aggregating data squirted into events once a trace has completed. For example, if I want to know the total amount of time a database has spent performing queries, I could put a database_ms field into every span involving a database call, then at the end sum ("rollup") the values. It's a great feature, but I consider it a nice-to-have instead of a must-have.

2. Tracing can happen both synchronously and asynchronously. Python's asynchronous programming model involves a lot more complexity than I want to deal with just to get a basic version of tracing implemented, so I decided to leave that to a later iteration.

3. Distributed tracing is critical when a single operation from a user's perspective can involve operations across multiple services. Implementing distributed tracing requires being able to propagate trace information from one service to another. That's a lot of complexity I don't understand well, so I decided that limiting tracing to a single application is good enough.

4. A lot can happen when a tracing library is being used in a live production system, especially when the tracing is performed asynchronously. So Honeycomb has done things like put in checks for existing trace identifiers when starting a trace. Perhaps this is a very important thing to do, but this feels like complexity I don't need right now.

5. Honeycomb uses a global Tracer embedded in a global Beeline object. The Beeline object has a bunch of properties particular to stuff Honeycomb does, but one of its properties is a logger, which is useful. I'm pulling it out and making it global, so logging can be done globally without having to use a container class.