log4k 2.3.0 — a Kotlin IR compiler plugin that ins...

# feed

[Yorgos S.]

log4k 2.3.0 — a Kotlin IR compiler plugin that instruments your functions with tracing, logging and metrics

log4k is a coroutine/channel-based logging + tracing + metering library for Kotlin Multiplatform (JVM, Android, iOS,
macOS, Linux, Windows, JS, wasmJs, wasmWasi), aligned with the OpenTelemetry model.

The recent addition is log4k-compiler-plugin — a Kotlin IR compiler plugin that rewrites annotated functions at compile
time, so the instrumentation boilerplate disappears from your source. It runs on common IR before backend lowering, so
the same annotations work on every KMP target — not just the JVM (no AspectJ, no bytecode agent, no reflection).

Setup — one Gradle plugin, no extra config:

plugins {
    id("io.github.smyrgeorge.log4k") version "2.3.0"
}

dependencies {
    implementation("io.github.smyrgeorge:log4k-classic:2.3.0")
}

@Traced — wraps the body in a span (started, ended, marked failed on throw):

@Traced
context(_: TracingContext)
suspend fun loadUser(id: Long): User {
    // ...
}   // span "UserService.loadUser"

The parent span is resolved from what's in scope: a TracingContext param/receiver → nests under its current span; else a
TracingEvent.Span in scope → used as parent; else a trace: Tracer member (reused, or synthesized) → new root span.

@Logged — entry/exit/failure logging:

@Logged
fun compute(x: Int): Int = x * x
// → UserService.compute(x = 5)
// ← UserService.compute = 25(12.5 us)

Throwing logs ✗ UserService.compute failed (…) at ERROR with the throwable, then rethrows. If a span is in scope
it's attached to every emitted line.

@Timed — call/error counters + a duration histogram:

@Timed(tags = [Tag("tier", "gold")])
suspend fun placeOrder(id: Long): Order {
    // ...
}

Records OrderService.placeOrder.calls, .errors and .duration (ms histogram) — exportable in OpenMetrics line
format via SimpleMeteringCollectorAppender.

The plugin is marked experimental — behavior and API may still change.

Feedback welcome, especially on the annotation surface and on cases where thon't pick what you'd expect.

Repo: github.com/smyrgeorge/log4k
Compiler Plugin: github.com/smyrgeorge/log4k#…
Docs: smyrgeorge.github.io/log4k

[altavir]

I do not think that any new logging library would work without comprehensive comparison with existing logging libraries. You can use what you want, but the main problem with logging libraries is that you need clear advantage to use one. Otherwise each part of your application will bring yet another logging with it.

[Yorgos S.]

Actually is not a new library. I first published it like two years ago and still actively maintaining it. The advantage of this library is that apart from the logging functionalities also offers tracing and instrumentation under a single package. I generally think that instrumentation (metering), tracing an logging is part of the same problem, observability. So, having a library that offers a bunch of features around those three, for me is a clear plus.

[altavir]

Still, the problem with logging hell should be addressed. There are tens of different logging libraries in Kotlin ecosystem.

[Yorgos S.]

That's true.. I think is happening because the kotlin ecosystem is still young, especially if you consider KMP. To be fair, I started this project because at that moment there wasn't any option for native targets (with tracing, etc). Another thing is that some of the existing libraries are build without including the new features of kotlin, like for example context parameters, etc.

[altavir]

It is the very same thing that caused logging hell in Java ecosystem. So probably solution is the same - provide compatibility notes and methods for different libraries.

[altavir]

I think Kermit and Kotlin-logging are the most popular

[Yorgos S.]

True but those lack tracing and metrics (as far as is know). I’m coming from a back end environment and those two are absolutely necessary

[Yorgos S.]

In Java the library hell was solved with slf4j. In Rust for example they introduced the front end API (for logging and tracing) from the beginning, so that mess never happened

[Didier Villevalois]

That's a really interesting library. I read your readme and documentation, and it seems you don't provide an appender for the OpenTelemetry Kotlin SDK. Is this something feasible? Maybe you already have one somewhere?

[Yorgos S.]

Hello!
I don’t currently have one, but I guess would be easy to create one.
I have an open branch (private) for a Slf4jLoggingAppender for a logging appender that forwards to slf4j . I also plan to publish the appender that I’m using in some personal projects that sends the traces to a local open telemetry agent.

For metering, you can also check the SimpleMeteringCollectorAppender that creates an OpenMetrics formatted string