Metric for Dirty memory (Linux exclusive)

[braydonk]

Propose new conventions

I'd like to introduce two new Linux-exclusive metrics for Dirty memory:

• system.memory.dirty
• system.memory.dirty.page.count

system.memory.dirty will be the bytes from /proc/meminfo's Dirty field. system.memory.dirty.page.count will be that number divided by getconf PAGESIZE. I did some research to determine why I think this will produce an accurate number which you can audit here: https://gist.github.com/braydonk/78ff4581be2056c0b3e77b471088258a

This issue will be blocked on #1932. These will be Specialist Class metrics, and they will be OS exclusive, so the name will either start with linux or be system.linux.

[braydonk]

I forgot to add: Why should page.count be a separate metric?

This a pretty simple calculation on the surface, but the reason I think it should be a separate metric is because getting the configured page size from the system is better done by instrumentation. In the Collector we could theoretically add getting the page size as a function in OTTL or something, but it is far simpler for the source reporting the metric to get this information and use it in the calculation than for users to have to configure something extra.

[braydonk]

In the PR for open-telemetry/opentelemetry-collector-contrib#38672 Dmitrii brought up a good point that introducing a page.count metric could open up the floodgates for all sorts of memory metrics to have their own duplicate *.page.count metrics. To get around the issue mentioned in my previous comment, we are going to introduce system.memory.page_size as a separate metric that can be used in calculations for any other metrics that may come in the future similar to this one where a calculated pagesize would make sense (i.e. any other metrics from /proc/meminfo which are similarly calculated to kB from page numbers).