Ktor provides the capability to log application events using the SLF4J library. You can also install and configure the
CallLogging feature to log client requests.
To enable logging, you need to include Logback artifacts in the build script:
Access the Logger
The Logger instance is represented by a class that implements the Logger interface. The Logger instance in a Ktor application is created when building the application environment, and this instance is assigned to the ApplicationEnvironment.log property. You can access the Logger from ApplicationCall using the
You can also get access to the Logger using Application.log.
CallLogging feature allows you to log incoming client requests.
To install the
CallLogging feature, pass it to the
install function in the application initialization code. This can be the
main function ...
... or a specified module:
You can configure
CallLogging in multiple ways: specify a logging level, filter requests based on a specified condition, customize log messages, and so on. You can see the available configuration settings at CallLogging.Configuration.
Set the Logging Level
By default, Ktor uses the
Level.TRACE logging level. To change it, use the
Filter Log Requests
filter property allows you to add conditions for filtering requests. In the example below, only requests made to
/api/v1 get into a log:
Customize a Log Message Format
By using the
format function, you can put any data related to a request into a log. The example below shows how to show a
User-Agent header value in a log:
Put Call Parameters in MDC
CallLogging feature supports MDC (Mapped Diagnostic Context). You can put a desired context value with the specified name to MDC using the
mdc function. For example, in the code snippet below, a
name query parameter is added to MDC:
You can access the added value during an