Changelog History
Page 2
-
v2.0.5 Changes
March 06, 2020 -
v2.0.4 Changes
December 17, 2019 -
v2.0.3 Changes
December 14, 2019 -
v2.0.1 Changes
September 30, 2019🛠 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
July 24, 2019 -
v2.0.0-RC1 Changes
June 18, 2019📚 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.kindtag 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
FilterAPI to allow users to match the includes or excludes part alone, if needed. - ⏱ Turn the scheduler Threads into daemon Threads.
- ✂ Remove the
configPathconfiguration 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 aconfigPathparameter on their constructors so you could still register them manually. - Created a counter to track sampling decisions counts per sampler.
-
v2.0.0-M5 Changes
June 03, 2019🔄 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
startmethod 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.Tryon the Kamon initialization path. This is because the latest futures instrumentation is targetingTryand it might happen these types will be initialized by Kamon before Kanela gets loaded (when attaching at runtime). - Ignore negative values on gauges.
- ✂ Removed
-
v2.0.0-M4 Changes
May 22, 2019🔄 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 aTraceinstance, which will immediately override the sampling decision on all local Spans. You can read more about these changes on #586.PeriodSnapshot Model Change
⚡️ The
PeriodSnapshotthat Kamon passes to all metric reporters was updated to have a simpler model, going from (roughly speaking)Map[MetricName, MetricSnapshot]to a simplerSeq[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
MetricBuildingtrait. - Ensure that the
upstream.nameContext tag is automatically propagated when using HTTP/Binary propagation. - ✅ Simplified usage of
TestSpanReporteron the testkit module. - Created a new tool called
UnitConverterwhich replaces the previousScalertool. - 🔧 The module registry now will explicitly search for the
nameconfiguration 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 Changes
April 26, 2019🔄 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.