-
Notifications
You must be signed in to change notification settings - Fork 888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are processes allowed to report their process.cpu.time? #2439
Comments
I think this is not about "allowing", it is about is it expected to have this instrumentation? Do we want to maintain this in all the language? etc. /cc @yurishkuro |
I think this may be a language-ecosystem thing. The JVM has been emitting "process cpu time" for almost 2 decades, so Java users very much expect this to be emitted by any Java metric library. |
Did you also mean I'm beginning to question if it is even possible for an instrumentation library to support
In the event of multiple meter providers, their reporting intervals may be different. So, calculating the difference in process.cpu.time since the last measurement requires the instrumentation to maintain some state per meter provider. I don't think the metric API spec offers the support necessary for this. |
What are you trying to achieve?
Clarification on whether language-based instrumentation is allowed to report
process.cpu.time
for its process.The specification currently says:
I think there are roughly three options:
process.cpu.time
for their own process (resource attributes would differentiate it fromprocess.cpu.time
reported by the OpenTelemetry Collector)process.runtime.*
orprocess.runtime.[jvm].*
, e.g.process.runtime.cpu.time
orprocess.runtime.[jvm].cpu.time
The text was updated successfully, but these errors were encountered: