collector/conntrack: make procfs statistics optional

[bianbbc87]

Summary

The eight nf_conntrack_stat_* metrics are listed in the README alongside the two sysctl ones, with no note that they depend on a kernel option that no longer defaults to y. Operators reasonably read that as a promise the collector will keep. Nothing in the runtime output corrects the impression: the metrics are simply absent, and the only trace is a debug-level line most deployments never enable.

The result is a steady trickle of duplicate reports #2491, #3184 that stay open because there is no canonical answer to point at, and keep collecting comments from operators arriving at the same dead end years apart. Whichever direction this ends up going, the collector should at least be able to state its own status.

What changes

Add --collector.conntrack.stats, enabled by default, following the existing --collector.arp.netlink and --collector.netclass.netlink precedent. The sysctl metrics are collected before the flag is consulted, so they are unaffected either way.

When the flag is on and the file is missing, the collector logs a warning once per process instead of a per-scrape debug message.

level=warn msg="conntrack statistics unavailable"
  file=/proc/net/stat/nf_conntrack
  reason="kernel built without CONFIG_NF_CONNTRACK_PROCFS"
  hint="pass --no-collector.conntrack.stats to stop collecting them"

Behaviour

Kernel	Flag	nf_conntrack_stat_*	collector_success
CONFIG_NF_CONNTRACK_PROCFS=y	default	collected	1
CONFIG_NF_CONNTRACK_PROCFS=n	default	absent	0, warned once
CONFIG_NF_CONNTRACK_PROCFS=n	--no-collector.conntrack.stats	absent	1
nf_conntrack not loaded	any	absent	0 (unchanged)

Systems where the collector works today are unchanged; systems where it does not gain a way to say so and a way to opt out.

Discussion

This PR only makes the current state legible and controllable; it does not bring the eight metrics back. Every option that actually does has to pay for CAP_NET_ADMIN somewhere, because nfnetlink_rcv() demands it even for read-only requests and there is no sysctl to relax that.

Option	node_exporter change	Capability held by	Metric names	Main obstacle
ctnetlink behind an opt-in flag, default off	~150-200 LOC on the existing mdlayher/netlink dependency, no new one	the node_exporter process	unchanged	policy, not code: first collector to want a capability. CAP_NET_ADMIN also grants interface, nftables and routing changes, which is a wide blast radius for eight read-only counters
textfile collector running conntrack -S	none, this is the route CONTRIBUTING.md already points to	the cron job only; node_exporter stays unprivileged	operator-defined, no longer matching the built-in names	operators maintain the script; collection lags the cron interval
This PR, statistics turned off	done	nobody	n/a, the eight stay absent	loses insert_failed / drop diagnostics. Saturation alerting is unaffected, since the mixin's NodeHighNumberConntrackEntriesUsed only uses entries / entries_limit

has been open since #2491 was filed in 2022. I'd appreciate your thoughts on the right direction here.

[bianbbc87]

Hi @discordianfish,
#3184 was closed on the expectation that a newer release would help. getConntrackStatistics() still reads only /proc/net/stat/nf_conntrack on v1.12.1 and on master, so the reports against 1.9.1 in that thread still hold. Tagging you per CONTRIBUTING.md, and because you asked in #2491 whether this should move to netlink.

This PR does not try to settle that question. It stops the collector from failing silently and gives operators a way to opt out, with no change to metric names, values or collector_success semantics. If you would rather see the ctnetlink route, or the selinux-style success=1 shape, I am happy to follow up with either.