Hi Sean, This is a tough question. I guess maybe the same granularity as the log messages: that is, emitting a JFR event for every step where now a log message is logged, with similar parameters would probably make sense?
At the same time, would anyone use JFR events to debug a Kerberos issue? I am unsure about that. What do you think? Best, Peter Seán Coffey <sean.cof...@oracle.com> ezt írta (időpont: 2024. márc. 13., Sze, 10:53): > > On 13/03/2024 01:40, Wei-Jun Wang wrote: > > Thinking about this raises the question: wouldn't it be possible to have > these components emit Flight Recorder events as well? > I understand this is a dubious topic, as some arguments contain secrets, but > it would be interesting to know. > Maybe restricting FR events when security debug logging is enabled anyways > would be an option? > > Seán is our expert on JFR events. He has already created some > security-related events, like provider loading and security properties > access. You can tell him what else you are interested in. > > Using JFR events is certainly worthy of discussion. What would those JFR > events looks like ? Would you propose one for each log action currently in > the krb5 code ? It becomes unmaintainable IMO. > > The suggestion has also been made for the TLS logging code in the past. > It's not trivial to convert every log entry to a JFR event. A typical > client/server handshake in TLS can generate 1000's of lines of log output > with -Djavax.net.debug=all enabled. It doesn't translate easily to JFR > events. Reading text is probably easier also. > > On a related note, I think the current TLS logging is too verbose at the > moment. Over 3,500 lines of output are generated before a ClientHello gets > created in a typical TLS debug capture. It's too much. Most of it is > iterating over certs found in the truststore (cacerts by default). Need to > log a bug on that. > > regards, > Sean. >
