Stuff run by target 'all' is usually not needed and a lot of overhead.
So if one wants to make all he should call 'make all' explicitly.

Is absolutely useless to include any VCS specific version strings
or UUIDs into a version stirng: it makes it hard to normal people
to read and if built from a different repo they do not match anyway.
And if the VCS changes, all the bloat for nothing. People should
have learned this lesson a long time ago. What matters only is the
release tag: [0-9]+.[0-9]+.[0-9]+(.[0-9]+)*

We need to know, how long scraping all target takes. Since it may
happen in parallel adding scrapetimes of all targets is misleading.
E.g.: node_scrape_collector_duration_seconds{collector="overall"}

Certain aspects of the running node-exporter are in a day-by-day
scenario interesting (like process metrics), but certainly not
the go metrics - non-developers often don't even know, what they
mean. So admins should be able to turn off this bloat but still
have the process metrics.

HELP and TYPE comments are usually useless for DBs as wel as utilities
processing timeseries. So there is a lot (~ 50% sometimes even more) of
overhead sent over the wire without any needs. Producing and processing
this bloat needs additional ressources. So allow to run it e.g. in
production environments in an efficient way and skip sending this info.

The cpu_linux collector collects several CPU related metrics, which
have little use in a day-by-day scenario (but might be useful from
time to time when troubleshoutinh problems). So people may now use
--no-collector.cpu.stats and --no-collector.cpu.throttle to disable
collecting/emitting such metrics.

Furthermore /proc/cpuinfo duplicates the CPU package infos for each
strand - for many core systems a huge amount of useless data. So
linux cpuinfo collector got modified to collect CPU info for each
CPU package, only.

In addition /proc/cpuinfo now gets collected only once, when the
collector instance gets created. If one adds/removes a CPU package
on the fly, which is very unlikeley, one needs to restart the collector
to reflect the system changes.

Last but not least useless bloat gets removed from model_name and
min, max and base frequency provided in a separate label entry.

Admins need a clear understanding, what values are provided and
where they come from. Therefore metrics got renamed from 'pressure'
to 'psi' (to avoid confusion, too), and labels use the same names
as in related pressure files.

Misleading/vague HELP msgs got corrected, now match the official
documentation.

Last but not least no more useless value convertion from µs to s
(there is no need  at all for it and pure overhead) and the last
value of any line gets parsed, only (all others ignored because
dropped anyway).

Cleanup, bugfixes and consolidation of the linux nfs[d] collectors.
Still a bit messy, and questionable designed (also wrt. performance),
but one step after the other ... ;-)

Obsolete stat data neither get parsed nor "0" metrics emitted for
them anymore.

NFSv4.0 ops got fixed and 4.1 + 4.2 incl. RFC 8276 op support added.

NFS4 metrics with no data get neither constructed nor sent (e.g.
for NFS4.0 box server and client metrics for NFSv4.1 and NFS.4.2
are skipped).

Metrics and related labels got renamed to something what makes sense
to an admin and better reflects its purpose.

Skip parsing data and sending nfsd metrics for the given list of
NFS versions.  list is a comma separated list of 2, 3, 4, or 4ops.
E.g. --collector.nfsd.skip=2,4ops

Underlines are at least for german users a pain because it needs an
extra key to be pressed. So replace '_' with '-' in the binary name.

Get the total number of CPU cores (or strands if HT or SMT is
enabled) which are online or offline. Uses syconf to get the
required data.

If you have NFSd performance problems on Linux, you should 1st look
at these node_nfsd_thread_status metrics - that's basically what
really matters (you probably can't do much wrt. NFS ops executed).
If (enqueued - woken) alias deferred or timedout increaseses
considerably, you probably need to rise the number of knfsd threads
handling the workload ;-).