Instrument host and enforcement capability health #116

Problem

Packet counter selection, schedule lifecycle and resource cleanup have internal state and logs, but operators cannot collect stable metrics for actual enforcement mode, host pressure or disclosure freshness.

Proposed change

Expose low-cardinality host memory/FD/disk signals plus capability mode, denied traffic, clock uncertainty, disclosure lag and remaining schedule lifetime only where authoritative subsystem observations exist. Add settlement backlog instrumentation by consuming the payment status contract.

Acceptance criteria

• Missing or unavailable instrumentation is explicit rather than a misleading zero.
• Capability downgrade, storage pressure and stale disclosure fixtures change the expected observations without altering enforcement behavior.
• Collection is bounded and does not hold runtime ownership guards over file/network I/O or expose per-destination/user labels.

Current evidence

PR #356 merged the supported observation slice in 8e3eb292a386f5d50aa3e63520ceb8652b3dabd4. The existing authenticated metrics endpoint now aggregates selected packet-counter modes, attribution reasons, kernel clock readiness/error estimates and announced schedule lifetime. Dispatcher RSS, descriptors and state-filesystem capacity were already available. Missing, malformed, stale, future-dated or disconnected reports remain unknown; incomplete numeric summaries are omitted.

All 16 jobs passed in candidate CI 36979225833; the actual merged tree is identical to that candidate. Focused metrics tests passed under the race detector on supported Linux. Pinned Prometheus health, availability and storage fixtures passed. Collection remains bounded, uses fixed labels and introduces no I/O under the registry lock or enforcement changes. See the metrics contract.

Remaining proposal scope: denied-traffic observations, independently measured clock uncertainty, actual end-to-end disclosure delivery lag and settlement backlog still lack the corresponding authoritative exporter contracts. Executor process RSS/descriptor/disk observations are also not exported. Existing observations must not be renamed or treated as these missing measurements. Packet enforcement validation remains coordinated with #67; settlement instrumentation stays with the payment status work. This issue remains open for those gaps.

• internal/executor/node.go: Node selects interface and packet counter at construction.
• internal/executor/config/config.go: TESLA timing and chain horizon are configured separately.
• internal/dispatcher/dispatcher.go: Payment handler owns settlement state; metrics must consume its established status.

Dependencies

• #67 — Measure and validate packet-counter enforcement for supported paths
• #68 — Attach attribution before initial packets and report tagging failure
• #71 — Persist schedule identities and roll TESLA chains without stale-key reuse
• #72 — Define TESLA clock uncertainty and suspend/clock-step behaviour
• #75 — Stop advertising current attribution after failed or stale BPF key refresh

Related work

These are integration points, not prerequisites for starting this issue.

• #79 — Acknowledge payment receipts only after durable processing
• #80 — Reserve exact payout amounts and reconcile uncertain transfers
• #81 — Make refunds safe for empty orders, write failures and uncertain transfers

Validation must use owned local fixtures on supported Linux environments. Record the implementing merge request and relevant test results before closing this issue.

Imported from GitLab issue 115. Originally opened 2026-09-10. Historical GitLab links may require access to the original project.