mountstats: add --collector.mountstats.nfs.aggregate-transports flag

[evkuzin]

Adds an opt-in flag, --collector.mountstats.nfs.aggregate-transports, that sums the per-transport NFS metrics across all export entries of a mount and emits a single series per mount (no transport label).

Before 29f6ec0a, mountstats_linux only read the first export entry from /proc/self/mountstats, which silently underreported every transport metric on mounts using NFS nconnect. That commit correctly fixed the numbers by iterating all transports and adding a transport index label.

The fix is right, but for hosts with many NFS mounts and high nconnect values it multiplies the existing (already large) node_mountstats_nfs_* cardinality by nconnect. On a host with tens of mounts, enabling nconect will turns into tens of thousands of additional series per scrape (multiplies all nfs metrics by nconnect value) which is enough to be a real operational problem for the monitoring.

When the new flag is set:

The 10 node_mountstats_nfs_transport_* descriptors are built without the transport label, restoring the pre-29f6ec0a schema and cardinality.
All export entries are aggregated into a single value per mount before being emitted:

• Counters (Bind, Connect, Sends, Receives, BadTransactionIDs, CumulativeBacklog, CumulativeSendingQueue, CumulativePendingQueue) → sum — matches the kernel's actual mount-wide totals.
• IdleTimeSeconds (gauge) → min — represents "time since the mount last saw any RPC traffic on any transport".
• MaximumRPCSlotsUsed (gauge) → max — the busiest transport's peak.

Default is false, so existing scrapes are unchanged.

Happy to add some tests as well.

[evkuzin]

@SuperQ could you take a look when you have time please?

[sagigrimberg]

This LGTM

[evkuzin]

Also I wonder if default should be actually true, because historically this didnt have transport labels/cardinality and likely this is the expected way for majority.

[sagigrimberg]

Also I wonder if default should be actually true, because historically this didnt have transport labels/cardinality and likely this is the expected way for majority.

Shouldn't the default be more verbose?
I'm fine with making it the default though

[evkuzin]

Shouldn't the default be more verbose?

Looking at it from the user perspective, your change feels like a pretty significant behavioural change. Previously users had N metrics, and after upgrading that number could suddenly be multiplied depending on the setup.

I think the decision to enable more detailed reporting should be explicit and made by the user, not introduced implicitly by changing the default behaviour. It potentially break existing dashboards or alerts that relied on the previous output.