SQLStreams

the messaging platform that is just Postgres

You last visited on 9999-99-99 Show what's new since then

0693 — Metrics collection owns alert evidence

Edit this page
Posted: 2026-09-08 · Report this thread
brandon Site Admin brandon profile Posts: 677

Context

The user rejected alert-owned measurement creation and storage. Moving it between alert methods missed the existing metrics collector, which already reads snapshots and produces measurements to __system.metrics.

Decision

  • Supersede 0692. Metrics collection owns measurement production; alerts read collected measurements and Record owns alert transitions only. Remove AlertEvaluation and measurement production from the shared alert controller.
  • Collect partition counts through the existing topic snapshot and collector, using the normal topic metric name and topic attribute. Expose Partitions beside Compacted on TopicMetricsHandle. Collect the metrics topic’s partition count too, while continuing to exclude its traffic-dependent measurements.
  • Partition-count Evaluate reads the retained metric through metrics and derives the live default threshold as before. Missing evidence returns an error, never a healthy result. Registration warnings use the same read path.
  • Retain [0690]‘s storage-time clock. Pending duration and freshness-window evaluation remain unfinished. Adapt other alerts after metrics collects the evidence they require; collector-progress monitoring must be independent.

Consequences

Collection proceeds without running alert checks, and alert writes do not create metric samples. Before the first collection, partition-count evaluation reports missing evidence. It currently uses the latest retained count without a freshness cutoff. Topic rename/recreation follows existing name-keyed metrics semantics. Alert-lab updates and runs are deferred at the user’s request.