executor-service-capture-on-submittracing system instead of the regular
executor-servicebut it doesn't capture spans on
java.util.concurrent.ScheduledExecutorService(there is no instrumentation for it). Is it a voluntary omission or just something that was never asked for ?
@redkhalil to your quuestions:
- Disabling Kamon via config. There is nothing ready yet but @jtjeferreira put an initial bunch of work here: kamon-io/Kamon#780
- Issue with upgrading from v1 to v2. If you are using Kamon.init, are you 100% sure that the call is happening before any of the Akka HTTP-related classes are loaded?
- Preferred version: latest! I know that Kamon is not working well with Akka HTTP 10.0 and early 10.1 so the latest 10.1 should be fine
I've figured out what was missing, I still need the javaagent, which I initially removed. Now I got it working. The information is out there on the website, just that it's a bit of a puzzle that you need to put together ;)
fork in run : = truein
build.sbt, it throws
[main] ERROR 2020-06-10 01:01:49 Logger : Unable to start Kanela Agent. Please remove -javaagent from your startup arguments and contact Kanela support.: java.lang.NoSuchMethodError: 'void kamon.instrumentation.akka.instrumentations.VersionFiltering.onAkka$(kamon.instrumentation.akka.instrumentations.VersionFiltering, java.lang.String, scala.Function0)'any idea why?
In my application, there is a long living WebSocket for a user session. The user interacts on the UI, which sends messages on the WebSocket, and the application does a bunch of things and sends one or multiple messages back to the UI. I'm unable to get traces for this in jaeger. I'm able to get traces for other HTTP requests, but not WebSocket requests. Is there any examples around this that I could follow? I'm on play 2.6 and using WebSocket like https://www.playframework.com/documentation/2.6.x/ScalaWebSockets. I've tried both Netty Server and Akka Server behind the scenes, but the result is same: HTTP requests are getting traced, websocket is not.
Ideally I'd like the whole user session traced, with spans for messages and other sub-operations like db calls, outbound HTTP calls etc.
sort of yes.. let me elaborate: if that initial Context has a not-sampled Span in it and you reuse that same Context then all other Spans that would be created by those actor messages will not be sampled as well. Also, all of the Spans would be part of the same trace which most likely will turn the trace useless if you end up having thousands and thousands of Spans spanning (possibly) hours.
I would recommend you manually create a Context with the user/session ids when the actor handling the websocket is created and then, every time you get a new "command" into that actor you create a new span for that new command, call
yourOriginalContext.withEntry(Span.Key, newSpanForThisOperation) and then use