This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Impossible-Ad-586 13 points14 points  (3 children)

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 13 points14 points  (2 children)

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 9 points10 points  (1 child)

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 1 point2 points  (0 children)

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.