mirror of
https://github.com/XRPLF/rippled.git
synced 2026-09-27 15:28:03 +00:00
8547adb5c1
Dashboards and alert rules reference 186 metrics; the harness asserted 57. Excluding the 107 per-category overlay-traffic expansions, the meaningful gap was 20 names. This closes it under the contract file's own doctrine: assert only what the workload guarantees, and record the rest with a precise reason. Asserted 18, taking the metric checks from 61 to 79 and the whole metric phase from 66 to 84. No pre-existing check name or position changes. statsd_gauges gains the nine state_accounting_* siblings of the one member already asserted, plus the two NodeFamily full-below-cache gauges and overlay_peer_disconnects. All twelve rest on one mechanism the group description now spells out: on the OTel path a beast gauge is an Int64ObservableGauge, every instance self-registers in its constructor, onCollectionReady arms all of them unconditionally, and the armed callback Observes on every export cycle whether or not set was ever called, so the series exist at 0. The state_accounting family is set in one unconditional block in NetworkOPsImp::collectMetrics, and full_transitions is the input to the NodeStateFlapping alert rule, so the alert's own signal had been going unverified. A new job_queue_per_type_gauges group asserts the six per-job-type gauges that a panel or a rule names literally, jobq_manifest_waiting among them as the ManifestJobQueueConvoy rule's input. The description records why those six and not all 105: the guarantee is identical for every non-special job type, so the discriminator is consumer coverage, and the remaining names are only reached through topk queries over the family that do not depend on any single type being present. Recorded four more in not_asserted rather than asserting them. pathfind_fast_milliseconds is unreachable for this workload, not merely rare: reportFast fires only from the doCreate fast pass, which is guarded by !hasCompletion(), and both ripple_path_find entry points construct the request with a completion function. Only the path_find subscription reaches it, and the generator does not use it. pathfind_full_milliseconds is reachable but only one ledger close after the request, through PathRequestManager::updateAll, and nothing in the harness arranges or checks that, so the guarantee is probabilistic. warn_total and drop_total are resource-manager meters gated on a consumer crossing the warn or drop threshold; their rpc-pathfinding panels are correct and render empty only because the condition has not occurred, which is worth stating because both were briefly mis-read as phantoms. Runbook check counts updated to match.