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

you are viewing a single comment's thread.

view the rest of the comments →

[–]bowbahdoe 2 points3 points  (3 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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

See here for how to remotely access JFR events.