[receiver/hostmetricsreceiver] Add system.memory.shared metric

[osullivandonal]

Description

Adding system.memory.shared metric to receiver/hostmetricsreciever.

Important

The utility gopsutil provides the shared memory value for Linux only atm. This PR has implemented this for Linux only.

Link to tracking issue

Closes #32712

Testing

Unit tests

Tests have been added and updated at receiver/hostmetricsreciever.

Local testing

• Compile the binary make otelcontribcol
• Run locally with config enabling system.memory.shared

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 5s
    scrapers:
      memory:
        metrics:
          system.memory.shared:
            enabled: true

processors:
  batch:
exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]
    metrics:
      receivers: [otlp, hostmetrics]
      processors: [batch]
      exporters: [debug]
    logs:
      receivers: [otlp]
      processors: [batch]
      exportezs: [debug]

Output on Linux

Metric #0
Descriptor:
     -> Name: system.memory.shared
     -> Description: Shared memory usage, including tmpfs filesystems and System V/POSIX shared memory. Currently only supported on Linux.
     -> Unit: By
     -> DataType: Sum
     -> IsMonotonic: false
     -> AggregationTemporality: Cumulative
NumberDataPoints #0
StartTimestamp: 2025-12-19 14:46:29 +0000 UTC
Timestamp: 2025-12-30 11:45:18.588949995 +0000 UTC
Value: 2334576640

[osullivandonal]

/rerun

[braydonk]

This will only ever be available on Linux to my knowledge. To my knowledge, the other target platforms for the collector do not provide singular shared memory usage as a programatically readable statistic. I would recommend removing the suggestion that this will be supported by other platforms.

(We may also need to rename this metric in our semantic conventions to reflect that, CC @rogercoll)

[osullivandonal]

That makes sense, I have removed the suggestion that other platforms may support this in the future.

Regarding renaming, we could go with something like system.linux.memory.shared: That would be more accurate and consistent with system.linux.memory.available and system.linux.memory.dirty.
Should I wait for the semantic conventions to be updated first, or would you prefer I rename it in this PR and we update semconv afterward?

[braydonk]

We're having kind of a growing-pain with the OS name in semconv right now. Our written guidance suggests that the OS name goes after the "representative subsystem" of a metric namespace, and we would generally consider system.memory to be a "subsystem". So we would use the name system.memory.linux.shared in that case. The tension is that this name is kind of awkward; the "memory" is what's shared, not the "linux".

It's on my task list this week to get that sorted out once and for all. It's gonna come down to whether Semantic Conventions generally values clearer individual names or clearer organization within a namespace.

In the meantime, this PR can stay open since the functionality is all correct, and it's just down to the name.