Skip to content

Persist metric audit - #38664

Draft
SangJunBak wants to merge 3 commits into
mainfrom
persist-metric-audit
Draft

Persist metric audit#38664
SangJunBak wants to merge 3 commits into
mainfrom
persist-metric-audit

Conversation

@SangJunBak

@SangJunBak SangJunBak commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

Breakdown and explanation why we're removing what we're removing:
https://claude.ai/code/artifact/cadbde1e-53ea-4e1d-a7a1-197c799e65c9

`mz_persist_shard_live_writers` and `mz_persist_shard_rewrite_part_count`
appear on no dashboard. `mz_persist_shard_inline_backpressure_count` was
registered together with inline writes but never incremented, so the
panel that plots it has always shown zero.

Every per-shard family costs one series per shard in every process that
holds a handle to that shard, which is where the persist share of the
environmentd /metrics payload comes from.
Six per-shard families were only ever read summed over all shards, so
the shard label bought nothing but one series per shard per process.

The three `mz_persist_backpressure_*` families keep their names and lose
their labels. They are set by the persist_source backpressure operator,
which never runs in environmentd, so there every one of those series was
a zero. The gauge among them now reads as the sum over live operator
instances, each contributing its most recent value through
`GaugeContribution` and withdrawing it on drop.

The operator's metric bundle, `BackpressureOperatorMetrics`, is shared
with the upsert operator. It now holds plain handles, and each owner
keeps its own series alive: the persist client through its process-level
`BackpressureMetrics`, upsert through the new per-worker
`UpsertBackpressureMetrics`.

The three `mz_persist_shard_pubsub_diff_*` counters move next to the
other pubsub receiver metrics as
`mz_persist_pubsub_client_receiver_diff_{applied,not_applied_stale,not_applied_out_of_order}`.
`mz_persist_shard_since`, `mz_persist_shard_upper`,
`mz_persist_shard_stale_version`,
`mz_persist_shard_schema_registry_version_count`,
`mz_persist_shard_inline_part_bytes` and
`mz_persist_shard_batch_part_version_bytes` appear on no curated
dashboard, only on the everything dump. Frontiers per collection are in
`mz_internal.mz_frontiers`, `mz_persist_shard_count` already counts
shards, and each of the two `_bytes` families has a `_count` sibling on
the shard dashboard.

The release sign-off reference counted `mz_persist_shard_upper` series
to get a shard count and now points at `mz_persist_shard_count`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant