ref!: convert linux meminfo implementation to use procfs lib

[tjhop]

Part of #2957

Prometheus' procfs lib supports collecting memory info and we're using a
new enough version of the lib that has it available, so this converts
the meminfo collector for Linux to use data from procfs lib instead. The
bits I've touched for darwin/openbsd/netbsd are with intent to preserve
the original struct implementation/backwards compatibility.

Signed-off-by: TJ Hoplock t.hoplock@gmail.com

[tjhop]

Looking at the failing tests

[tjhop]

@SuperQ would you mind taking a look when you get time? Lemme know your thoughts 👍

[tjhop]

Ah, good point, I appreciate the forethought. I'll rework it to not coerce nils and leave them out 👍

[tjhop]

@SuperQ is this more in line with what you were thinking?

[SuperQ]

Yes, this is looking much better. I'll try and do a deeper review soon.

[tjhop]

Friendly bump. @SuperQ please lemme know if you have any further thoughts 👍

[discordianfish]

I'd convert this to a loop, something like:

for k, v := range map[string]*int {..} {
  if v == nil {
    continue
  }
  metrics[k] = float64(*v)

[SuperQ]

I think we wanted to switch to an explicit mapping.

[tjhop]

Agreed, I think we need an explicit mapping here, especially since the field names in the Meminfo struct don't 100% align with the existing metric names, ex:

	if meminfo.ActiveAnonBytes != nil {
		metrics["Active_anon_bytes"] = float64(*meminfo.ActiveAnonBytes)

[juliusv]

I just updated the Node Exporter on https://demo.promlabs.com/ from 1.7.0 to 1.9.0 and noticed that a few meminfo time series disappeared after the update. These were there previously but no longer present after the update:

node_memory_FileHugePages_bytes{instance="node-exporter:9100", job="node"}	0
node_memory_FilePmdMapped_bytes{instance="node-exporter:9100", job="node"}	0
node_memory_Hugetlb_bytes{instance="node-exporter:9100", job="node"}	0
node_memory_KReclaimable_bytes{instance="node-exporter:9100", job="node"}	84930560
node_memory_SecPageTables_bytes{instance="node-exporter:9100", job="node"}	0
node_memory_ShadowCallStack_bytes{instance="node-exporter:9100", job="node"}	1843200
node_memory_Zswap_bytes{instance="node-exporter:9100", job="node"}	0
node_memory_Zswapped_bytes{instance="node-exporter:9100", job="node"}	0

See also https://demo.promlabs.com/query?g0.expr=%7B__name__%3D%7E%22node_memory_.*%22%7D+offset+1h+unless+on%28__name__%29+%7B__name__%3D%7E%22node_memory_.*%22%7D&g0.show_tree=0&g0.tab=table&g0.end_input=2025-02-24+09%3A18%3A00&g0.moment_input=2025-02-24+09%3A18%3A00&g0.range_input=1h&g0.res_type=auto&g0.res_density=medium&g0.display_mode=lines&g0.show_exemplars=0

Is this related to the new explicit mapping not catching all possible fields?

[SuperQ]

Yes, that is probably related. I guess we need to update the procfs parsing library.

[juliusv]

Yes, that is probably related. I guess we need to update the procfs parsing library.

Previously we just parsed whatever fields the /proc/meminfo file contained and translated those directly into metric names. With the procfs library, we now explicitly map each known field into a Go struct field and then read it out again. That seems brittle, as you'll never know what kind of memory usage field the kernel will add next, or which fields are only present with certain kernel / host combinations. Would it be better to go back to just passing through all fields that are actually there, as before?

[SuperQ]

I think some of the intention here was to better curate the output of these metrics for HELP text and cardinality control.

[tjhop]

Ironically, moving away from the raw mapping -> struct was an explicit design decision in the beginning to better align with other collectors and to take advantage of the fact that struct breakage surfaces a compile time error:

#2957 (comment)