When creating reporters it should be clear that environment tags win over metric tags, more info here: https://github.com/kamon-io/kamon-prometheus/pull/10/files#r172143022

Write at least the basic concepts around the context and propagation, both locally and remotely.

https://kamon.io/docs/latest/guides/how-to/start-with-the-kanela-agent/
latest release from our Kanela releases repository and start

Hello,

The examples in https://kamon.io/docs/latest/core/metrics/ do not mention the need to invoke the withTags / withoutTags methods in order to obtain an Instrument instance (e.g. Timer) that is needed to gain control over recording: as a consequence, someone following the guide (like me 🙂) would be left wondering why he cannot start a timer...

Near the end of this segment there's a link to what is supposed to be documentation for the bytecode instrumentation agent.

The link appears to be dead. Maybe it should point to this?

Edit:
Found another one
https://kamon.io/docs/latest/core/tracing/ leads to https://kamon.io/docs/latest/advanced/instrumentation-guidelines/

They are using the old API, like Kamon.withContext and Key.broadcastString.

There are a few classes in kamon-core that quite confuse the compiler:

kamon.metric.Metric - a toplevel interface
kamon.metric.Metric$ - a toplevel class
kamon.metric.Metric$Settings - an inner interface of the kamon.metric.Metric
kamon.metric.Metric$Settings$ - an inner class of the kamon.metric.Metric
kamon.metric.Metric$Settings$ForDistributionInstrument - inner class of kamon.metric.Metric$Settings$
kamon.metric.Metric$Settings$ForDistributionInstrument$ - inner class of kamon.metric.Metric$Settings$
According to Java rules, kamon.metric.Metric$Settings$ForDistributionInstrument should be inner class of kamon.metric.Metric$Settings (no trailing $), because the $ is needed as the separator of name segments. Apparently the scala compiler, which produced these .class files, didn't pay attention to such rules. Given that the InnerClasses is the only manifestation of inner classes at the bytecode level, it is possible for a non-Java compiler to produce such .class files.

What's more: kamon.metric.Metric$Settings$ does not have a source name as seen in this bytecode attribute:

InnerClasses:
public static #8= #2 of #7; // =class kamon/metric/Metric$Settings$ of class kamon/metric/Metric
The source name would be the value of #8, i.e., the part before the =. I.e., we regard this type as an anonymous class.

In the Java world this means the type is anonymous, and hence no external reference to this type is possible. The compiler only has provisions for the source variant of anonymous classes, not for their binary counter part, as they are never relevant for compilation.

From this, type.isLocalType() is a sufficient guard for a cast to LocalTypeBinding - for legal .class files, i.e.

Still we find Metric$Settings$ just by looking at public API:

public static interface kamon.metric.Metric$Timer implements Metric<kamon.metric.Timer,kamon.metric.Metric$Settings$ForDistributionInstrument>
type argument kamon.metric.Metric$Settings$ForDistributionInstrument is inner class of kamon.metric.Metric$Settings$
booom
To a java compiler this tells: here is a public interface that depends on an anonymous type. This is nonsense.

The scala compiler will have to make up its mind whether or not kamon.metric.Metric$Settings$ is anonymous.

In JDT we could further protect this one cast, but we have a total of 64 callers of isLocalType(). Each would need to be thoroughly checked, which IMHO is way too much effort just to support non-Java .class files.

When following the instructions, after sbt disting and then running Play (in production mode), there were no metrics reported via the Prometheus exporter web page.

Actually there were a few kamon metrics, but not the hundreds of akka metrics I got otherwise when using the SBT Kanela Runner Plugin, in both dev and production mode.

I noticed in the dist-generated start script, there was no -javaagent: JVM argument provided, which I'm guessing is the problem since I understand you're using the aspectj agent to do the instrumentation. Seems the instructions are thus missing the needed step of adding this to build.sbt: javaAgents += "org.aspectj" % "aspectjweaver" % "1.9.6" % "runtime".