Library of Ktor features for OpenTracing instrumentation of HTTP servers and clients.
Install the OpenTracingServer
feature as follows in a module:
install(OpenTracingServer)
The feature uses the tracer registered in GlobalTracer, which uses the ThreadContextElementScopeManager
.
This is needed to propagate the tracing context in the coroutine context of the calls.
For example, you can instantiate and register a Jaeger tracer in the module before the call to install
as follows:
val tracer: Tracer = config.tracerBuilder
.withScopeManager(ThreadContextElementScopeManager())
.build()
GlobalTracer.registerIfAbsent(tracer)
At this stage, the application will be creating a single span for the duration of the request. If the incoming request has tracing context in its HTTP headers, then the span will be a child of the one in that context. Otherwise, the feature will start a new trace.
To get a more detailed view of requests, we might want to instrument individual code blocks as child spans.
We could start a new child span using the tracer instance directly, however this would be too intrusive and verbose.
Instead, we can use the span
inline function as follows.
class UserRepository {
fun getUser(id: UUID): User = span("<operation-name>") {
setTag("UserId", id)
... database call ...
return user
}
}
span
is passed an operation name and an anonymous lambda, which has the Span
as a receiver object.
This means that you can call setTag
, log
, getBaggageItem
(or any method on the Span
interface).
Concurrent operations using async
can break in-process context propagation which uses coroutine context, leading to spans with incorrect parents.
To solve this issue, replace the calls to async
with asyncTraced
. This will pass the correct tracing context to the new coroutines.
val scrapeResults = urls.map { url ->
asyncTraced {
httpClient.get(url)
}
.awaitAll()
}
Underneath the hood, asyncTraced
is adding the current tracing context to the coroutine context using a call to tracingContext()
. You can add it yourself by calling async(tracingContext())
. To launch
a new coroutine with the tracing context, call launchTraced
.
If your application calls another service using the Ktor HTTP client, you can install the OpenTracingClient
feature on the client to create client spans:
install(OpenTracingClient)
The outgoing HTTP headers from this client will contain the trace context of the client span. This allows the service that is called to create child spans of this client span.
We recommend using this feature in a server that has OpenTracingServer
installed.
Your application might be serving static content (such as k8s probes), for which you do not to create traces. You can filter these out as follows:
install(OpenTracingServer) {
filter { call -> call.request.path().startsWith("/_probes") }
}
It is also possible to configure tags to be added to each span in a trace. For example to add the thread name and a correlation id:
install(OpenTracingServer) {
addTag("threadName") { Thread.currentThread().name }
addTag("correlationId") { MDC.get("correlationId") }
}
From Maven Central.
Add the following dependency to your pom.xml
:
<dependency>
<groupId>com.zopa</groupId>
<artifactId>ktor-opentracing</artifactId>
<version>VERSION_NUMBER</version>
</dependency>
Add the following to your dependencies
in your build.gradle
implementation "com.zopa:ktor-opentracing:VERSION_NUMBER"
-
For a simple example of ktor app instrumented with OpenTracing, see ktor-opentracing-example. This app uses span names passed explicitly to the
span
inline function. -
For automatic span naming using the class and method name, see ktor-opentracing-span-naming-demo.
- For Ktor services using kotlin-logging, you can use kotlin-logging-opentracing-decorator to enrich your spans with logs.
- If you are using Exposed, you can use Exposed-OpenTracing to instrument database transactions.