Add process.memory.utilization metric to semantic conventions
#2844
Conversation
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
e0c6e53 to
4ae6bef
Compare
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
4ae6bef to
d94668c
Compare
| @@ -36,6 +36,7 @@ Below is a table of Process metric instruments. | |||
| | `process.cpu.time` | Counter | s | Total CPU seconds broken down by different states. | `state`, if specified, SHOULD be one of: `system`, `user`, `wait`. A process SHOULD be characterized _either_ by data points with no `state` labels, _or only_ data points with `state` labels. | | |||
| | `process.cpu.utilization` | Gauge | 1 | Difference in process.cpu.time since the last measurement, divided by the elapsed time and number of CPUs available to the process. | `state`, if specified, SHOULD be one of: `system`, `user`, `wait`. A process SHOULD be characterized _either_ by data points with no `state` labels, _or only_ data points with `state` labels. | | |||
| | `process.memory.usage` | UpDownCounter | By | The amount of physical memory in use. | | | |||
| | `process.memory.utilization` | Gauge | 1 | Percentage of total physical memory on the system that is used by the process. | | | |||
There was a problem hiding this comment.
any label/attribute for this metric?
There was a problem hiding this comment.
Hm no, I don't think so. Looking at the gopsutil implementation, a process's memory utilization is just the amount of physical memory that the process uses (RSS) divided by the total amount of RAM available on the system.
I know that gopsutil is not necessarily a determinant of what can or should be implemented, but I think this single value is what's most interesting to the user.
There was a problem hiding this comment.
If we wanted to provide other usage numbers, how would this scale to account for them?
Also, should this be a derived metric from process.memory.usage and another metric outlining total host memory?
There was a problem hiding this comment.
If we wanted to provide other usage numbers, how would this scale to account for them?
I'm not sure what other usage numbers we would like to provide? The process.memory.usage metric does not have any attributes or "flavors". It seems natural to extend the "usage" metric to "utilization" as a percentage of total available memory.
Also, should this be a derived metric from
process.memory.usageand another metric outlining total host memory?
I agree that if we had a metric that specifies the total available memory on a system, we can achieve process.memory.utilization by dividing the process.memory.usage by system.memory.available or whatever the name. Currently we don't have a name for such metric. Even if we had one though, I believe giving a name to the metric that describes "the process's memory utilization" is still useful.
What we are doing here is we are defining names for things that might or might not (hopefully they do) exist in the world, not at all specifying whether or not a system should or should not provide a metric / a piece of information. I think we can agree that a process's memory utilization is a thing that exists in the world. Even if it can be conveyed from other information, that other information (like total available memory) might not be available. For example, if a user wants to ingest Telegraf metrics into OpenTelemetry, the semantic conventions should help them find canonical names for things.
Sorry for the lengthy post, hope my points are clear.
There was a problem hiding this comment.
@bogdandrutu @jsuereth does this make sense to you? Any further comments?
There was a problem hiding this comment.
@jsuereth @bogdandrutu Please take a look.
There was a problem hiding this comment.
The issue in my mind is still that folks look at SemConv as a "minimum" list of requirements, not a set of options.
- If this is indeed just an optional thing that could be filled out, add a comment about how OTEL prefers raw usage numbers and this is just an option for interacting with legacy / non-OTEL-first systems.
- I don't think your view on SemConv being "possible things" vs. "requirements list" is shared by all who read this. That's a higher-level discussion we can/should have. I actually think the later is more common mindset than the former.
So, I understand your argument about how this is a possible thing for legacy systems, but I'd like to see that in the PR itself, as a comment or some other denotation for when to choose/use utilization vs. other mechanism.
There was a problem hiding this comment.
Oh, I guess I had some assumptions that are not necessarily true. Thanks for pointing this out Josh. This probably means I would need to change the way I think about semantic conventions.
Going back to this specific metric and PR, there already exist system.memory.usage and system.memory.utilization metrics in the semantic conventions. I was hoping that adding process.memory.utilization to the convention would be one of the easier things to add.
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
2 times, most recently
from
887272a to
f2fe253
Compare
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
f2fe253 to
9b00b23
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
9b00b23 to
f67917e
Compare
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
f67917e to
d8b6124
Compare
andrzej-stencel
force-pushed
the
add-process-memory-utilization-metric
branch
from
d8b6124 to
7725a50
Compare
|
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Fixes #2811
Changes
Adds a new metric
process.memory.utilizationto the semantic conventions.Context
Here's a related proposal to implement this metric in the OT collector's
hostmetricsreceiver: open-telemetry/opentelemetry-collector-contrib#14084.