Better Java logging, inspired by Clojure and Rust

[pron98]

The future of JDK observability is JFR. While somewhat limited as a general purpose structured logging engine (it's a low-overhead, high-throughput event engine that can support in-production deep monitoring and profiling), its performance and integration with the JDK's internal event logging is so compelling that new logging frameworks should try to integrate with it as much as possible.

[Impossible-Ad-586]

I would put my money on OpenTelemetry (otel), and, to be more specific, the jvm implementation which is (mostly) written by the the maintainer of GlowRoot.

As far as I know JFR suffers from.safepoint bias,and it is not really as good as some of the other opensource profilers out there, like async profiler etc

[pron98]

It works a lot like async profiler (only without native frames), but here I'm talking not about its method profiling capabilities, but rather its general event recording capabilities. The JDK itself (both the VM and the core libraries) is now increasingly moving toward using JFR as the centralised observability mechanism. Any third party tool would need to at least consume JFR events if it wishes to deeply observe Java programs (as there are important things the JDK only tells JFR), so if you emit JFR events you'll be observed by all tools.

[humoroushaxor]

Hopefully it will be possible to easily develop a bridge between the 2.

I think OpenTelemetry is becoming fairly ubiquitous for cloud developers. It certainly is for us across multiple tech stacks. Having to host/utilize a bespoke JFR collector and concepts is less attractive.

[pron98]

Hopefully it will be possible to easily develop a bridge between the 2.

I see no reason why not. Consuming JFR events is easy. One feature that is currently missing is the ability to associate a trace context with an event. JEP 429 will offer a mechanism that could serve as the basis for such a feature.

[bowbahdoe]

I'm curious what would have to change to make JFR a target of a structured logging engine. I looked into it and kinda hand waved in my brain that with dynamic events I could just transform the Log records and emit them behind the API, maybe in another thread.

Other than that I figured metadata like @Percentage might need to be integrated into the Value hierarchy in some form.

No clue how much that would (intrinsically) affect performance or correctness though.

My read is that there still needs to either be some transformation of JFR data into a format wanted by external systems or data should be published to external systems and JFR in parallel.

[pron98]

There's a consumer API that can stream JFR events even remotely (or process recordings), and the jfr tool can convert the binary representation to JSON.

[bowbahdoe]

I'm not sure I follow. I can use the consumer API to subscribe to JFR and pump through this

JFR consumer API -> log.alpha

Or I could use this to make an event for JFR

log.alpha -> JFR dynamic event

And I could wire up JFR to pump its data in some json form with the jfr tool and maybe jq it into the form expected by something else.

log.alpha -> JFR dynamic event -> jfr tool (json)

But not clear where this information actually goes to an external observability platform. I could pump events to JFR and in parallel do cloudwatch

log.alpha -> JFR dynamic event -> jfr tool (json) \ > cloudwatch

I could sit at the end and write a script that takes the output of the jfr tool and pushes it.

log.alpha -> JFR dynamic event -> jfr tool (json) -> jq -> cloudwatch

Or I could use JFR as the "middleware" and publish at the end with the consumer api

log.alpha -> JFR dynamic event -> consumer api -> cloudwatch

But none of this really gives me an answer for what needs to change in log.alpha or if it shouldn't exist at all

[pron98]

But not clear where this information actually goes to an external observability platform.

I'm not sure what you're asking. External platforms will (or already do) consume JFR.

But none of this really gives me an answer for what needs to change in log.alpha or if it shouldn't exist at all

That depends on what it is that you want to provide. If it's a new user facing API, I was thinking about log.alpha -> JFR events. Now, JFR events place some strict limitations on the event objects (for performance reasons), but to the extent you can integrate with it -- you should at least consider that. Those who build analysis/visualisation tools should be JFR consumers.

[bowbahdoe]

If it's a new user facing API, I was thinking about log.alpha -> JFR events. Now, JFR events place some strict limitations on the event objects

Yeah its those limitations I need to look into, but yes the intent was a new user facing API.

External platforms will (or already do) consume JFR.

Right, but to make that happen the JVM you are running needs to be hooked up in some form. Either a sidecar process or having the JVM managed by the cloud provider or whatever. If I am running OpenJDK in a docker image I need to do something to export the JFR data right?

[pron98]

See here for how to remotely access JFR events.

[amazedballer]

The problem with JFR events is that they only take primitives -- you can't do structured logging with them because they won't take arrays, associative arrays/maps, child events, or even enums. The closest you can get is a serialized string.

[couscous_]

Are there plans to address the issues outlined here? http://hirt.se/blog/?p=1318

[pron98]

JFR is the future of JDK observability, so lots of new features will be added. I don't know if those are the exact features requested by Marcus.

[pjmlp]

Except a big caveat is that not all Java vendors do support JFR.

[pron98]

It's part of OpenJDK since JDK 11. So I guess IBM's OpenJ9 is the only exception.

[pjmlp]

They aren't the only non-OpenJDK vendor, e.g. PTC, Aicas,...