[receiver/hostmetrics] Add `Dirty` memory metrics

[braydonk]

Component(s)

receiver/hostmetrics

Is your feature request related to a problem? Please describe.

We would like metrics for the Dirty memory 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.available in the memory scraper right now, I am hoping to introduce these metrics as system.linux.memory.dirty{.page.count}. This may end up changing in the semantic conventions transition, but it would change in the exact same way as system.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

[github-actions]

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.

[braydonk]

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.

[crobert-1]

@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.)