クライアントのリクエストをログ出力

Estimated reading time: 1 minute

クライアントリクエストをログ出力したいことがあるかもしれません。CallLogging Featureはそれを実現してくれます。 Featureはこれはslf4jを使ったApplicationEnvironment.log (LoggerFactory.getLogger("Application"))を利用しており、 簡単に出力内容を設定することができます。 Ktorでのロギングについてのより詳細な情報は、ktor内でのロギングページをご覧ください。

This feature is defined in the class io.ktor.features.CallLogging and no additional artifacts are required.

基本的な使い方

Featureを未設定の場合、すべてのリクエストに対しTRACEレベルでログ出力します:

install(CallLogging)

設定

このFeatureはログレベルとログ出力が行われるリクエストのフィルタリングの設定ができます:

install(CallLogging) {
    level = Level.INFO
    filter { call -> call.request.path().startsWith("/section1") }
    filter { call -> call.request.path().startsWith("/section2") }
    // ...
}

filterメソッドはホワイトリストとしてフィルター一覧を保持しています。 もしフィルターが定義されていないなら、すべてがログ出力されます。 もしフィルターがあるなら、フィルターのうちいずれかがtrueをreturnする場合にログ出力されます。

この例では、/section1/*/section2/*リクエストの両方で出力されます。

MDC

CallLogging Featureはslf4jのMDC (Mapped Diagnostic Context)をサポートしており、リクエストの一部として情報を紐付けられます。

CallLoggingをインスタンス化するとき、mdcメソッドを使ってリクエストに紐付けるパラメータを設定できます。 このメソッドはkey名と関数のProviderを必要とします。 コンテキストはMonitoringパイプラインフェーズの一部として紐付けられ(そして関数provider群が呼び出され)ます。

install(CallLogging) {
    mdc(name) { // call: ApplicationCall -> 
        "value"
    }
    // ...
}

MDCはThreadLocalsを使って動作しており、Ktorは指定したThreadに紐付かないcoroutinesを利用しています。 このFeatureはその問題に対処するため内部的にkotlinx.coroutines ThreadContextElementを利用しています。