Distributed tracing with OpenTelemetry in Ktor Client
Ktor integrates with OpenTelemetry — an open-source observability framework for collecting telemetry data such as traces, metrics, and logs. It provides a standard way to instrument applications and export data to monitoring and observability tools like Grafana or Jaeger.
The KtorClientTelemetry
plugin allows you to automatically trace outgoing HTTP requests. It captures metadata like method, URL, and status code and propagates trace context across services. You can also customize span attributes or use your own OpenTelemetry configuration.
Add dependencies
To use KtorClientTelemetry
, you need to include the opentelemetry-ktor-3.0
artifact in the build script:
Configure OpenTelemetry
Before installing the KtorClientTelemetry
plugin in your Ktor application, you need to configure and initialize an OpenTelemetry
instance. This instance is responsible for managing telemetry data, including traces and metrics.
Automatic configuration
A common way to configure OpenTelemetry is to use AutoConfiguredOpenTelemetrySdk
. This simplifies setup by automatically configuring exporters and resources based on system properties and environment variables.
You can still customize the automatically detected configuration — for example, by adding a service.name
resource attribute:
Programmatic configuration
To define exporters, processors, and propagators in code, instead of relying on environment-based configuration, you can use OpenTelemetrySdk
.
The following example shows how to configure OpenTelemetry programmatically with an OTLP exporter, a span processor, and a trace context propagator:
Use this approach if you require full control over telemetry setup, or when your deployment environment cannot rely on automatic configuration.
Install KtorClientTelemetry
To install the KtorClientTelemetry
plugin, pass it to the install
function inside a client configuration block and set the configured OpenTelemetry
instance:
Configure tracing
You can customize how the Ktor client records and exports OpenTelemetry spans for outgoing HTTP calls. The options below allow you to adjust which requests are traced, how spans are named, what attributes they contain, which headers are captured, and how span kinds are determined.
Trace additional HTTP methods
By default, the plugin traces standard HTTP methods (GET
, POST
, PUT
, etc.). To trace additional or custom methods, configure the knownMethods
property:
Capture headers
To include specific HTTP request headers as span attributes, use the capturedRequestHeaders
property:
Capture response headers
To capture specific HTTP response headers as span attributes, use the capturedResponseHeaders
property:
Add custom attributes
To attach custom attributes at the start or end of a span, use the attributesExtractor
property:
Next steps
Once you have KtorClientTelemetry installed and configured, you can verify that spans are being created and propagated by sending requests to a service that also has telemetry enabled—such as one using KtorServerTelemetry
. Viewing both sides of the trace in an observability backend like Jaeger, Zipkin, or Grafana Tempo will confirm that distributed tracing is working end-to-end.