Skip to content
Hallway
0:00 / 0:00

#jdkflightrecorder#jfr#jvm

Continuous Monitoring with JDK Flight Recorder (JFR)

InfoQ

234K subscribers • 68 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • Presented by Mikael Vidstedt

Intermediate. Assumes working knowledge.

6.6K views6 years ago2 recommendations

Systems programmingTools and practiceJava and the JVMPerformance and optimizationObservability and monitoring

Mikael Vidstedt explains how JDK Flight Recorder provides low-overhead, continuous profiling and monitoring directly within the JVM.

QCon San Francisco, the international software conference, returns November 17-21, 2025. Join senior software practitioners from early adopter companies as they share real-world insights and actionable advice to help you adopt the right technologies and practices. Gain exposure to innovative approaches and fresh ideas in software development and engineering, designed to inspire and challenge you. Don’t miss this chance to deepen your knowledge, sharpen your skills, and stay ahead in the ever-evolving world of technology. Register now: bit.ly/3BYzfbe --------------------------------------------------------------------------------- Video with transcript included: bit.ly/2VEIh47 Mikael Vidstedt gives an overview of JDK Flight Recorder (JFR), showcases the current feature, as well as some features coming in the future. JFR is a monitoring and troubleshooting framework built directly into the Java runtime. JFR has access to all the internal data of the JVM and can capture and surface data on a fine-grained level with extremely low overhead. #Java #JFR #DevOps

Why it's here

2 people recommend this

What people say. Recommended as an excellent overview of Java's low-overhead production profiling capabilities.

u/pron98in r/programming • Recommends

On “State of Project Loom on JVM”

It tracks a lot of stuff in the VM, including method profiles, and it can also track stuff in your application if you want to add application-specific low-overhead monitoring. It gives much greater insight than JMX. In fact, it gives better insight than any observability mechanism on any platform, which is what makes it one of Java's greatest achievements. See more here and here.
6View on Reddit

u/couscous_in r/dotnet • Recommends

On “Company statement on C# use.”

Continuous profiling: link to this video Because of the very low overhead, you keep running it in production so you always have data in case something happens and you're able to look back at it to investigate.
2View on Reddit

u/couscous_in r/dotnet • Mentions

On “Company statement on C# use.”

Only partially. When you attach a remote debugger, you have already encountered a problem and now you're playing catch up to try to see what happened, and hope that it happens again after you attach the debugger. Secondly, attaching a debugger has a high overhead on the application. With JFR, you have extremely low overhead continuous profiling that you keep running in production (always-on). This way, if an incident happens, you already have the data collected, and no need to affect your program by attaching a debugger and hope that the issue is still happening during the debugger session. Watch this if you're interested: link to this video
1View on Reddit

u/couscous_in r/dotnet • Mentions

On “Company statement on C# use.”

…ut (1) it doesn't seem to give you continuous flamegraphs/call stacks via sampling, and (2) it seems it's bound to Azure. ~~What if I want to host my service elsewhere or even on my own hardware?~~ EDIT: while not bound to Azure for hosting the app, it seems that the metrics are sent to the Azure portal for viewing. This is what I'm referring to: link to this video EDIT: (3) you can also write your own custom very low overhead events and have them emitted. Basically a replacement for structured logging but very lightweight because they're built into the JVM. EDIT: seems it's not free? https://docs.microsoft.com/en-us/azure/azure-monitor/app/api-custom-events-metrics#limits > I think we did end up o…
1View on Reddit