Wishlist for Kamon Telemetry 3.x Series

[ivantopo]

Hello people!

In the 2-ish years since we released Kamon 2.0, and I think it is time to clean things up for a new major version. I remember that back in 2019 we did a lot of "defensive" coding in Kamon because OpenTracing was still around and changing, folks were talking more about OpenCensus/w3c-tracecontext, and suddenly OpenTelemetry started taking shape.

We made things more configurable and complicated than necessary (think propagation channels, HTTP client/server instrumentation, and trace identifiers) because of the fear that we would commit to something and the standards would move in a different direction so, we would need to introduce breaking changes. After a bit over two years, things are more stable and predictable, so we can clean up and move Kamon Telemetry forward!

Here is the wishlist I have so far, but please feel free to comment below and share any ideas you might have!

• [ ] Use the OpenTelemetry semantic conventions for all of our metrics. This is a big breaking change because pretty much every metric name will be different, breaking tons of dashboards out there. I would love to work on this as a "conventions" layer that we can switch, so users don't need to break everything to upgrade. Maybe even release it as optional in 2.x and switch to default OtelConventions on 3.x
• [ ] Simplify context manipulation. Context instances have tags and entries, but roughly speaking they are the same thing. Just tags have known types (String, Bool, Long) and entries require additional typing through a context key instance. I think we could flatten this as Context values, remove all the "lookups" from the context, and have special methods only for custom-type entries.
• [ ] Have a single binary/http propagation channel. We don't need more than one HTTP and one Binary propagation channel.
• [ ] Consider removing SpanBuilders and creating Spans directly. SpanBuilder instances are not thread-safe, hold a ton of fields, and then get thrown away immediately to create the real span instances. But, Spans are mutable anyways! We could save some CPU/memory allocations by cutting the middle man, if practical.
• [ ] Have a single flag to enable/disable Kamon completely. Including reporters, instrumentation, and everything in between. Idea from @lucasamoroso below (and request by a ton of people before!)
• [ ] Allowing to enable/disable specific metrics, spans, and span-generated metrics via configuration. Linked to #659.

[lucasamoroso]

Hi!

I don't know if this applies for Kamon 3 but one thing that I would love is to have a configuration field at the root of kamon to enable/disable it and this should enable/disable all modules (instrumentation, reporters, everything).

In my experience most of the times when I need to shutdown Kamon on a specific environment I need to add custom code, very simple code but needs to be added, to stop doing Kamon.init on that environment, because when there are a lot of modules in our application it's not a nice experience to disable them all one by one. I think we should be able to do this by just one configuration field on Kamon's root config.

[nvollmar]

Regarding the OpenTelemetry semantics it wouldn't be too much of a burden if the release came with a list of the changes to search/replace or a simple script that can be applied once and get the change done.

The other changes would be some welcome simplifications.