nbari / pg_exporter / 34187786891

90%

main: 90%

Build Type

push

github

Committed by nbari

Commit Message

fix: stop the process-group CPU counter over-reporting and take two more collectors off the runtime

Follow-ups from reviewing fcc2292; the two root-cause fixes there are
unchanged.

pg_system_process_group_cpu_seconds_total could over-report once scrapes
overlap. Reopening the gate on timeout means a new scrape can start while an
abandoned scrape's sample is still running - a spawn_blocking task that has
already begun cannot be cancelled, so the abort does not stop it. The
process-group collector sampled /proc outside its per-PID CPU baseline lock,
so the newer pass could publish its baseline first, the older pass would then
find every total lower, count no delta, and overwrite the baseline with its
own older values - and the next pass re-counted the interval between them.
The lock now spans the sample, which also keeps two concurrent walks from
doubling the /proc load and means the gauges are published in sample order.

The exporter collector's own process metrics (a sysinfo refresh plus a
/proc/<pid>/fd read) and the tls collector's certificate read and X.509 parse
still ran inline in collect_once. Both are far smaller than #35's walk, but
they are the same defect, and ssl_cert_file can point anywhere, including a
mount that hangs. blocking::offload moves from src/collectors/system/ up to
src/collectors/ so every collector can reach it.

pss_mode_reports_the_smaps_rollup_value was flaky - 17 failures in 25 runs of
the module. It compared two independent smaps_rollup reads of the test process
within a fixed 64-page tolerance, but a test binary's footprint moves by more
than that between the reads (measured: RSS drifts ~600KB while the RSS-PSS gap
is a stable ~1.8MB). The source dispatch is now injectable, so the tests
assert which reader gets called rather than a byte value, and the documented
PSS-to-RSS permission fallback gains its first coverage.

Docs corrected:

- The CHANGELOG said abort() could not have fixed #34 because the system
  collecto... (continued)

Coverage Stats

118 of 138 new or added lines in 7 files covered. (85.51%)

8 existing lines in 5 files now uncovered.

19459 of 21677 relevant lines covered (89.77%)

443.68 hits per line