[receiver/hostmetrics] Add Dirty memory metrics
#38672
Assignees
Labels
Comments
|
Pinging code owners for receiver/hostmetrics: @dmitryax @braydonk. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label. |
|
Thanks @crobert-1, do you know if something changed in the way we open issues? I added the hostmetrics component but didn't notice the label wasn't added automatically. |
braydonk
changed the title
Dirty memory metricsDirty memory metrics
|
@braydonk I haven't seen anything change, but I'm seeing a lot more failures to add labels and ping code owners, so it looks like something's gone wrong. (It's not related to this issue or component.) |
atoulme
pushed a commit
that referenced
this issue
Mar 20, 2025
…r filed (#38841) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Currently when a code owner files an issue the component's label is not added and the code owners are not pinged. This changes functionality so that even if a code owner files an issue, the component label is added and the code owners are pinged. I investigated this as a result of [confusion because of the existing behavior](#38672 (comment)). Note: If the component is included in the title the label will be properly added to the component even before this change. Pros for this change: - Labels are added automatically - Other code owners (for the case of >1 code owner for a component) are notified of a new issue against their component. Cons for this change: - It might result in noise for the code owner who is filing issues, especially if they're filing in bulk. Alternatives: - We could at least add the label even if a code owner filed the issue. - We could try to remove the filing code owner's handle from the ping message so they don't get pinged, and add a case for not pinging code owners if the user filing is the only code owner. Related: #33437 #30136
This was referenced Mar 23, 2025
Fiery-Fenix
pushed a commit
to Fiery-Fenix/opentelemetry-collector-contrib
that referenced
this issue
Apr 24, 2025
…r filed (open-telemetry#38841) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Currently when a code owner files an issue the component's label is not added and the code owners are not pinged. This changes functionality so that even if a code owner files an issue, the component label is added and the code owners are pinged. I investigated this as a result of [confusion because of the existing behavior](open-telemetry#38672 (comment)). Note: If the component is included in the title the label will be properly added to the component even before this change. Pros for this change: - Labels are added automatically - Other code owners (for the case of >1 code owner for a component) are notified of a new issue against their component. Cons for this change: - It might result in noise for the code owner who is filing issues, especially if they're filing in bulk. Alternatives: - We could at least add the label even if a code owner filed the issue. - We could try to remove the filing code owner's handle from the ping message so they don't get pinged, and add a case for not pinging code owners if the user filing is the only code owner. Related: open-telemetry#33437 open-telemetry#30136
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
receiver/hostmetrics
Is your feature request related to a problem? Please describe.
We would like metrics for the
Dirtymemory stat from/proc/meminfo.Describe the solution you'd like
New metrics as will be defined in open-telemetry/semantic-conventions#1998. This issue also contains research stating how the metrics should be implemented with references to kernel source code explaining reasoning.
As mentioned in that issue, the naming is blocked on OS name rules changin in semantic conventions. However, since we already have
system.linux.memory.availablein thememoryscraper right now, I am hoping to introduce these metrics assystem.linux.memory.dirty{.page.count}. This may end up changing in the semantic conventions transition, but it would change in the exact same way assystem.linux.memory.available.Describe alternatives you've considered
No response
Additional context
Directly linking the research gist for awareness: https://gist.github.com/braydonk/78ff4581be2056c0b3e77b471088258a
The text was updated successfully, but these errors were encountered: