GitHub user TheBuilderJR added a comment to the discussion: [Ideas] Add instrumentation and latency metrics to the Anser subsystem
For the `anser.stats()` / `stats_reset()` contract, could each snapshot identify its reset generation, and could the API document how a reader knows a reset has completed? A consumer computing interval rates from cumulative counters needs to distinguish two reads that straddle a reset. Checking for a negative delta alone can miss the reset if enough new activity has already exceeded the previous count. This also affects interval histogram quantiles: subtract corresponding bucket counts only across compatible snapshots from one reset generation, then derive an approximate quantile from that interval distribution; subtracting the displayed p99 values would not give an interval p99. Given the no-new-locks constraint, stating whether count, total time and bucket reads are a best-effort snapshot would help consumers avoid asserting exact consistency during concurrent updates. This is feedback on the proposed API, not a reproduced implementation issue. Disclosure: I build Telemetry; this reply was drafted with AI assistance. GitHub link: https://github.com/apache/cloudberry/discussions/1958#discussioncomment-18319661 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
