CtrlK
BlogDocsLog inGet started
Tessl Logo

tessl/maven-io-ktor--ktor-client-logging-jvm

HTTP client logging plugin for Ktor client framework with configurable logging formats, levels, and platform-specific logger integrations

—

Pending
Overview
Eval results
Files

levels-formats.mddocs/

Log Levels and Formats

The Ktor Client Logging plugin provides fine-grained control over what information gets logged and how it's formatted.

Required Imports

import io.ktor.client.*
import io.ktor.client.plugins.logging.*

Log Levels

enum class LogLevel(
    val info: Boolean,
    val headers: Boolean,
    val body: Boolean
) {
    ALL(true, true, true),
    HEADERS(true, true, false),
    BODY(true, false, true),
    INFO(true, false, false),
    NONE(false, false, false)
}

The LogLevel enum controls the verbosity of logging output with boolean flags indicating what information categories are included.

Level Properties

Each log level has three boolean properties that determine what gets logged:

  • info: Boolean - Basic request/response information (URL, method, status, timing)
  • headers: Boolean - HTTP headers for requests and responses
  • body: Boolean - Request and response body content

Available Levels

ALL

LogLevel.ALL(true, true, true)

Logs everything: basic info, headers, and body content. Most verbose option.

Example Output:

REQUEST: https://api.example.com/users
METHOD: POST
COMMON HEADERS
-> Content-Type: application/json
-> Authorization: ***
CONTENT HEADERS
-> Content-Length: 156
BODY Content-Type: application/json
BODY START
{"name":"John Doe","email":"john@example.com"}
BODY END

RESPONSE: 201 Created
METHOD: POST
FROM: https://api.example.com/users
COMMON HEADERS
-> Content-Type: application/json
-> Server: nginx/1.18.0
BODY Content-Type: application/json
BODY START
{"id":123,"name":"John Doe","email":"john@example.com","created":"2023-01-01T00:00:00Z"}
BODY END

HEADERS

LogLevel.HEADERS(true, true, false)

Logs basic info and headers but not body content. Good balance for debugging without exposing sensitive payloads.

Example Output:

REQUEST: https://api.example.com/users
METHOD: POST
COMMON HEADERS
-> Content-Type: application/json
-> Authorization: ***
CONTENT HEADERS
-> Content-Length: 156

RESPONSE: 201 Created
METHOD: POST
FROM: https://api.example.com/users
COMMON HEADERS
-> Content-Type: application/json
-> Server: nginx/1.18.0

BODY

LogLevel.BODY(true, false, true)

Logs basic info and body content but not headers. Useful when headers are not relevant but payload content is important.

Example Output:

REQUEST: https://api.example.com/users
METHOD: POST
BODY Content-Type: application/json
BODY START
{"name":"John Doe","email":"john@example.com"}
BODY END

RESPONSE: 201 Created
METHOD: POST
FROM: https://api.example.com/users
BODY Content-Type: application/json
BODY START
{"id":123,"name":"John Doe","email":"john@example.com"}
BODY END

INFO

LogLevel.INFO(true, false, false)

Logs only basic request/response information. Minimal logging for production environments.

Example Output:

REQUEST: https://api.example.com/users
METHOD: POST

RESPONSE: 201 Created
METHOD: POST
FROM: https://api.example.com/users

NONE

LogLevel.NONE(false, false, false)

Disables all logging. No output is generated.

Usage Examples

// Maximum verbosity
Logging {
    level = LogLevel.ALL
}

// Production-friendly logging
Logging {
    level = LogLevel.INFO
}

// Debug headers without exposing payloads
Logging {
    level = LogLevel.HEADERS
}

// Disable logging entirely
Logging {
    level = LogLevel.NONE
}

Logging Formats

enum class LoggingFormat {
    Default,
    OkHttp
}

The LoggingFormat enum controls the overall structure and style of logged output.

Available Formats

Default Format

LoggingFormat.Default

Standard Ktor logging format with structured request/response sections and detailed information layout.

Characteristics:

  • Multi-line structured format
  • Separate REQUEST and RESPONSE sections
  • Detailed header and body sections
  • Clear separation between different information types

Example:

REQUEST: https://api.example.com/users/123
METHOD: GET
COMMON HEADERS
-> Authorization: ***
-> User-Agent: Ktor-Client

RESPONSE: 200 OK
METHOD: GET
FROM: https://api.example.com/users/123
COMMON HEADERS
-> Content-Type: application/json
-> Content-Length: 87
BODY START
{"id":123,"name":"John Doe","email":"john@example.com"}
BODY END

OkHttp Format

LoggingFormat.OkHttp

OkHttp-compatible logging format that mimics the popular OkHttp logging interceptor output style. More concise than Default format.

Characteristics:

  • Single-line start/end markers with timing information
  • Compact header format
  • Request/response correlation with timing
  • Application-level logging only (no low-level HTTP details)

Example:

--> POST /users (156-byte body)
Content-Type: application/json
Authorization: ██

{"name":"John Doe","email":"john@example.com"}
--> END POST

<-- 201 Created /users (342ms, 87-byte body)
Content-Type: application/json
Server: nginx/1.18.0

{"id":123,"name":"John Doe","email":"john@example.com","created":"2023-01-01T00:00:00Z"}
<-- END HTTP (342ms, 87-byte body)

Format-Specific Features

Default Format Features

  • Structured Sections: Clear REQUEST/RESPONSE boundaries
  • Header Categorization: Separates common headers from content headers
  • Detailed Body Information: Explicit BODY START/END markers with content type
  • Method Repetition: Shows HTTP method in both request and response sections

OkHttp Format Features

  • Timing Information: Shows request duration in milliseconds
  • Body Size Indication: Shows expected or actual body sizes
  • Compact Headers: Single-line header format
  • Direction Indicators: --> for outgoing, <-- for incoming
  • Binary Detection: Indicates when binary or encoded content is omitted

Binary Content Handling

Both formats automatically detect and handle binary content:

Text Content:

BODY START
{"message": "Hello, World!"}
BODY END

Binary Content:

--> END POST (binary 1024-byte body omitted)

Encoded Content:

<-- END HTTP (342ms, encoded 2048-byte body omitted)

Format Selection Guidelines

Use CaseRecommended FormatReason
Development & DebuggingDefaultMore detailed, structured output
Integration with OkHttp toolsOkHttpCompatible with existing tooling
Performance monitoringOkHttpIncludes timing information
Production loggingOkHttpMore compact output
Log analysisDefaultEasier to parse structured sections

Combined Configuration Example

Logging {
    // Detailed logging for development
    level = LogLevel.ALL
    format = LoggingFormat.Default
}

// vs

Logging {
    // Production-friendly logging
    level = LogLevel.INFO
    format = LoggingFormat.OkHttp
}

Install with Tessl CLI

npx tessl i tessl/maven-io-ktor--ktor-client-logging-jvm

docs

advanced-config.md

configuration.md

index.md

levels-formats.md

loggers.md

platform-features.md

tile.json