v1.1.5 - Initialization Ordering

Improvements

• In certain situations it might happen that Kamon wouldn't load properly due to dependencies between internal components. This release uses lazy loading on the Kamon components to ensure components are only loaded when needed. Contributed by @dpsoft via cb528e4

v1.1.4 - Fixes

Fixes:

• The scheduled actions that sample range samplers were not being cleaned up properly after removing a range sampler metric, which was leading to a memory leak. Fixed by @ivantopo via f841079

v1.1.3 - Minor Improvements and Fixes

Improvements:

• Allow access to Span operation names. Contributed by @Falmarri in #539.
• Ensure immutability of Distribution instances created by Kamon. Contributed by @ivantopo in #538.

Fixes:

• The binary codec for Spans was using the same identity provided for trace and span ids. Fixed by @lustefaniak in #535.

v1.1.2 - Minor Improvement: EnvironmentTagBuilder Utility

Improvements:

• Introduce a EnvironmentTagBuilder utility class. This is meant to be shared across reporting modules that might need to export environment data as tags, providing a unified configuration syntax for all of them. Contributed by @ivantopo on #527.

v1.1.1 - Minor Fixes

Improvements:

• We didn't have the Scala compiler optimizations enabled until now. Contributed by @dpsoft on #521.

Fixes:

• The B3 codec was including the X-B3-ParentId header even in cases where there was no parent, which was causing issues on Safari/Webkit brosers as explained in kamon-io/kamon-akka-http#35. Now the X-B3-ParentId will only be included if there actually is a parentID on the Span. Fixed by @ivantopo on 2f05b3b.

v1.1.0 - Context Propagation Improvements, Environment Tags and Fixes

Context Propagation Improvements

Now you must specify header names for broadcast string keys. In case you didn't know about it just yet, in Kamon 1.0.0 you are able to use the kamon.context.codecs.string-keys setting to define arbitrary context key names for which you will get automatically generated codecs for both HTTP and Binary propagation. This was nice and useful, but the automatically generated header name for HTTP (something like X-KamonContext-$key) wasn't really the most friendly thing ever and didn't allow for cases when you need to follow conventions dictated before Kamon was put in place. You could still achieve that by implementing your own HTTP codec for your context key, but that's an overkill for most cases where you just need to pass arbitrary strings around. Starting on this release the codecs for string-keys will require you to specify both the key name AND the header name to be used. For example:

kamon.context.codecs.string-keys {
  request-id = "X-Request-ID"
}

The above configuration will ensure that the X-Request-ID header is packed/unpacked into a broadcast string key in the context without any code changes. If you wish to read this key in your service code just define a broadcast string Key matching the config-provided key name and get the value from a Context:

// Do this only once, keep a reference
val requestIDKey = Key.broadcastString("request-id")

val requestID = Kamon.currentContext().get(requestIDKey)

Why is this important?

One of the most used features in Kamon is the ability to propagate request or user identifiers across thread/process boundaries and that has been available for quite some time (even before 1.0), but this little change unlocks something that might not be so obvious but of great value: you can now propagate arbitrary context used by sidecars (think Linkerd/Envoy) without having to touch your application code, just configuration! This is a quite exciting feature and requires a dedicated explanation, blog post coming! But to give you an idea, adding this configuration should be enough to propagate all Linkerd Context Headers, regardless of whether you are using Play Framework, Akka HTTP, Http4s or any other supported HTTP toolkit 🎉

kamon.context.codecs.string-keys {
  l5d-ctx-dtab = "l5d-ctx-dtab"
  l5d-ctx-deadline = "l5d-ctx-deadline"
  l5d-ctx-trace = "l5d-ctx-trace"
}

Environment Tags

We now have a place to put environment-specific tags. Think of tags likeenv=staging or region=us-east-1 that should be applied to all data extracted from Kamon. Now, all these tags can be configured in the kamon.environment.tags setting, for example:

kamon.environment.tags {
  env = "staging"
  region = "us-east-1"
}

Please note that these tags are only informative from the Kamon core perspective, it's a well known place to put these tags (contrary to Kamon 0.6.x where each reporting module had its way to do this). Each reporting module should read and publish them if needed and in the following days we will start adding them to the available modules.

New Features

• #505 Arbitrary header names for broadcast string keys when propagating over HTTP. Contributed by @ivantopo in #509.
• #510 Allow environemnt tags. Contributed by @ivantopo in #515.

Fixes:

• The trace reporters ticker was always being restarted on calls to Kamon.reconfigure(...) due to a copy/paste mistake, reported and fixed by @briantopping in #504
• #513: Calls to tagMetric on non-sampled spans would not apply the tag. Fixed by @ivantopo in #516.

v1.0.1 - Minor Fixes

Fixes:

• #502: The Kamon scheduler and reporter registry threads would prevent the JVM from shutting down, even when no reporters were running. After this release all non-reporter threads in Kamon are daemon threads, users will still need to stop all reporters in order by either cancelling Registration received from adding the reporter or calling Kamon.stopAllReporters() Fixed on #508