Consider adding JVM metric for open file descriptors Semantic Conventions

[schmikei]

Propose new conventions

I'd like to add this metric to the java-contrib project.

  - bean: java.lang:type=OperatingSystem
    mapping:
      OpenFileDescriptorCount:
        metric: jvm.fd.open
        unit: 1
        desc: open file descriptors

Happy to discuss naming conventions on these as well but would like to collect this information!

I believe that this metric would be useful for monitoring resource usage and detecting potential file descriptor leaks and should be recommended metric.

Apologies if there was already discussion on adding this metric I just did not see it in the current list found here: https://opentelemetry.io/docs/specs/semconv/runtime/jvm-metrics/

[trask]

hi @schmikei!

let's watch #1798, and once they decide on a name, we can reuse that same name under jvm.*, similar to how we have jvm.cpu.time reflecting process.cpu.time

[trask]

@schmikei I'm not finding the OpenFileDescriptorCount metric you're showing in the screenshot.

I looked in

• https://docs.oracle.com/en/java/javase/17/docs/api/java.management/java/lang/management/OperatingSystemMXBean.html
• https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html

[schmikei]

@trask

They can be found here:

https://docs.oracle.com/en/java/javase/17/docs/api/jdk.management/com/sun/management/UnixOperatingSystemMXBean.html

They are unix based only since Windows doesn't use file descriptors on the kernel layer

[ridwanmsharif]

We're also very interested in this metric. From the discussion on #1798 am I understanding this currently that our two options for the name of this new metric are:

• jvm.unix.file_descriptor.count
• unix.jvm.file_descriptor.count

Is this understanding right?

[braydonk]

I've left a long-winded comment on #1798 in an effort to resolve the terminology debate for process.open_file_descriptors. The OS being the root namespace or first sub-namespace is a hot topic that we are still chasing in #1932 but I am hoping that resolving the terminology debate will help unblock the work to introduce this in JVM.

Regardless of the decision in process, I actually think the JVM metric really should end up being file_descriptor.count. The debate in the process namespace stems from a general ambiguity between the terms descriptor and handle to mean similar things, but have weird overloaded distinctions across different operating systems. In the case of this JVM metric, the API is very clear and unambiguous, as the term used is directly file descriptor. So I think the metric should match what the runtime calls it. Language runtimes generally have that luxury of one source of truth for a name like this, vs system where you could go with any of 50 years of random OS documentation to try and decode 😄

I don't closely follow JVM metrics, would this be the first time there is an OS exclusive runtime metric? That means it may be affected by #1932 based on how the @open-telemetry/semconv-jvm-approvers want to handle this scenario.