v2.0.5 - Maintenance Release

Improvements

• The context Scope is now AutoCloseable. This allows for more ergonomic usage when combining it with try-with-resources, scala.util.Using, cats.effect.Resource or anything similar. Contributed by @liff via #637.

Project Structure Changes

• This release will be the first automated release done entirely from Github Actions, which is the first step towards getting #626 done. All the core sources were moved to the core folder and soon, instrumentation and reporter folders will follow. Contributed by @ivantopo via 295da01

v2.0.4 - Maintenance Release

Fixes

• Duplicated timers data was reported when a PeriodSnapshot.Accumulator was used. This would only happen if a reporter is expecting a different tick interval size than what Core has configured so not a very common situation. Fixed by @ivantopo via #628.

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!