v2.0.3 - Maintenance Release

Fixes

• Include the error.message tag when a Span is failed with a Throwable. Fixed by @mladens via #625.
• Properly handle calls to Config.pairs when the configuration has a key with special characters in it. Fixed by @mladens via #624

v2.0.2 - Maintenance Release

Improvements

• Show the right error message when a metric redefinition is attempted. Fixes #608 and contributed by @ivantopo via #106
• Remove unused enabled setting in the Status Page reference configuration. Contributed by @pnerg via #621.

v2.0.1 - Maintenance Release

Fixes

• Some typos regarding configure the B3 Single Header propagation for Spans on the reference configuration. This was fixed by @schrepfler via #598 and #599.
• It wasn't possible to start any module after Kamon.stopModules() was called. This was fixed by @ivantopo via #605.

Improvements

• Include the exception thrown by histograms when recording values outside of the configured range on the logged warning messages to help with debugging. Contributed by @ivantopo via cc8d5bc
• Thanks to @melezov we have a cleaner code base! He cleaned up several warnings in the core module via #600.

v2.0.0-RC1 - We are ready to roll 2.0.0

Folks, the time has come! Our efforts on the next Kamon iteration have finally reached the RC stage! We already upgraded many of the instrumentation and reporting modules and will start rolling those releases right after this. Now that the APIs are fixed and stable, we will switch focus to updating the documentation and have a migration path for our users.

If you find any issues while upgrading to this release, please let us know!

Changes since 2.0.0-M5:

• Building on Scala 2.13 🎉 this was a last minute addition thanks to @hughsimpson's effort!
• Include the span.kind tag in Span metrics (this was lost when we moved the Span kind to a dedicated member rather than inferring it from the tags).
• Fix a minor problem that would cause range sampler to re-schedule their auto update tasks if the same instrument was looked up several times.
• Change the Filter API to allow users to match the includes or excludes part alone, if needed.
• Turn the scheduler Threads into daemon Threads.
• Remove the configPath configuration from modules. This is something we added a few weeks ago via #588 but while upgrading the reporting modules we realized that it is really not that convenient to have it. The goal of that setting was to eventually allow users to have more than one instance of the same module running but with different configurations and still, allow for those modules to be discovered via config.. at the end, this didn't work out very well and was making handling of module initialization and reconfiguration a bit tricky, so we decided to remove it. Still, while upgrading the modules we are adding a configPath parameter on their constructors so you could still register them manually.
• Created a counter to track sampling decisions counts per sampler.

v2.0.0-M5 - Minor cleanups

Changes since 2.0.0-M4:

This release packages a few minor changes required for modules to work as expected and simplifying reporter's implementation:

• Removed start method from metrics and span reporters. Long story short is that it lead to having lots of mutable stuff on reporters implementations, but you can read all details about it here: #588
• Remove all usages of scala.util.Try on the Kamon initialization path. This is because the latest futures instrumentation is targeting Try and it might happen these types will be initialized by Kamon before Kanela gets loaded (when attaching at runtime).
• Ignore negative values on gauges.

v2.0.0-M4 - Span Links, Delayed Spans and more!

Changes since 2.0.0-M3:

Span Links and Delayed Spans

This is a relatively big new feature that makes it easier to instrument operations that have a "wait" time (e.g. when sending a message to an actor, it "waits" on the mailbox for sometime or when producing a message to Kafka, it "waits" on Kafka before the consumer(s) receive it) and make links across Spans that might not belong to the same trace. A more detailed story is available on #584.

More Control over Sampling Decisions

Another addition on this version is the ability to suggest a sampling decision when creating working with a SpanBuilder, so that when a sampling decision needs to be taken, the suggestion will be used rather than generating a new decision from the sampler. Furthermore, now you can programatically override the sampling decision by calling .keep()/.drop() on a Trace instance, which will immediately override the sampling decision on all local Spans. You can read more about these changes on #586.

PeriodSnapshot Model Change

The PeriodSnapshot that Kamon passes to all metric reporters was updated to have a simpler model, going from (roughly speaking) Map[MetricName, MetricSnapshot] to a simpler Seq[MetricSnapshot]. Initially we thought that having maps would be more convenient here but in most cases they are just a burden and we just want to get to the values they contain (which also had the metric name anyways) so the model was simplified. Also, the model now matches the way in which metrics are organized in kamon-core: metrics hold several attributes like name, description and settings, paired with a collection of instruments for that metric, identified by their unique combination of tags.

Other Changes

Besides the three big changes above, there are several minor changes as well:

• The packaging hell has been finally fixed by completely removing proguard and copying the parts that we needed from Eclipse Collections' UnifiedMap into Kamon and tweaking the good old sbt-assembly to produce the dependency-less packages that we needed.
• Update the Status Page to include metric descriptions and fix a bug on storing those descriptions on the MetricBuilding trait.
• Ensure that the upstream.name Context tag is automatically propagated when using HTTP/Binary propagation.
• Simplified usage of TestSpanReporter on the testkit module.
• Created a new tool called UnitConverter which replaces the previous Scaler tool.
• The module registry now will explicitly search for the name configuration setting rather than trying to define the module name from the configuration path. This makes for much better display names on the Status Page.
• Fixed (or rather, implemented) custom settings on the metrics factory.

At this point, several modules have been already upgraded to 2.0.0-M4 (through snapshots), including Executors, Futures, Akka, Akka Remote and Akka HTTP, and we feel pretty confident that the implementation and API are in very good shape. Our hopes are to finish upgrading all the remaining modules and then publish 2.0.0-RC1. Stay tuned for the latest news!

v2.0.0-M3 - Fix Packaging, Again

Changes since 2.0.0-M2:

• We needed to add a few more rules to ensure the packaged core jar has everything it is supposed to have.
• We renamed a few builder methods that were called "create" instead of "build", for consistency with the rest of the codebase.

v2.0.0-M2 - Fix Packaging and Include Instrument Groups

Changes since 2.0.0-M1:

• We removed the Proguard step from the build due to invalid bytecode results when having double nested inner classes. Instead of proguard'ing the final jar we just used the info from proguard to create zap rules for SBT assembly and now we got a proper publishing process. More details here: #583
• We brought back instrument groups. This feature was introduced originally via #561 but at some point while the big metrics/tracer refactorings were happening it got removed, since we thought it should be on a different module but actually, core is the right place for it so it came back.

We continue the march towards 2.0.0!

v2.0.0-M1 - Almost complete API for Kamon 2.0

This is the first public milestone of what will become Kamon 2.0 and the results of months of gather feedback, testing and cleaning up what we built on Kamon 1.0 🎉

We will save the super detailed list of changes for when 2.0 gets released, but lets at least point to some of the most relevant changes since Kamon 1.1:

• We got a new abstraction to handle tags: the TagSet. Cool thing about it is that it can handle key/value pairs where the values can be a String, Long or Boolean, and provides a convenient API to access the tag values while still ensuring type safety. And, of course, now we are using TagSets for all tags we need to have: metric tags, span tags, context tags and environment tags! This was introduced via #572
• The Context got tags! Since it is extremely useful for users to have a quick and convenient way of defining key/value pairs that should be propagated with the Context, without having to provide any sort of serialization setup or code, we introduced Context tags via #552 (note: the HTTP server instrumentation on that PR got moved to a separate project).
• We got a huge refresh on the metrics API. Even though generally speaking things are very similar, the internal implementation was revamped and the user-facing API now provides easy-to-add auto updates and tagging on metrics. This was done via #574
• The Tracer also got a refresh where we exposed the Span APIs more cleanly, removed some of the legacy stuff we had from the OpenTracing days and we introduced a new adaptive sampler! This was done via #576
• We made Kamon able to discover and start modules from the classpath, something that was really useful back on the Kamon 0.6 days and that we never got to migrate, the wait is over! This was done via #559
• There is a new Status Page module in Kamon which starts an embedded web server with a single page app that can be used to see what modules, metrics and instrumentation modules are currently being tracked by Kamon. This was introduced via #569

We will spend the following days updating the instrumentation and reporting modules, preparing for the new Kamon Bundle packaging and getting ready for the release. We do not expect to introduce any breaking changes from now on, unless it is necessary to address or fix issues we find while going through the modules jungle.

v1.1.6 - Handle Faulty Initial Configuration

Fixes

• Kamon will now fallback to the reference.conf settings in case there is any problem while loading the initial configuration (reference.conf + application.conf). Fixed by @ivantopo via 53315a0