Hi, thanks for proposing this. This metric would be very useful for users, as it would allow them to easily determine whether there is a backlog for the subscriptions they care about.
+1 on this proposal. Thanks, Baodi Shi guo jiwei <[email protected]> 于2026年8月18日周二 10:47写道： > > Hi dev, > > I'd like to propose PIP-492: Add subscription-level storage backlog age > metric. > > Pulsar currently exposes `pulsar_storage_backlog_age_seconds`, which reports > the > age of the oldest backlog message at the topic level. This is useful for > detecting consumer lag by time, but it does not show which subscription is > responsible for the backlog. For topics with multiple subscriptions, different > subscriptions can have different latency expectations, so a topic-level value > can lead to noisy alerts or extra manual investigation. > > This proposal adds a new Prometheus metric, > `pulsar_subscription_storage_backlog_age_seconds`, to expose the backlog age > per > persistent durable subscription. The existing topic-level metric remains > unchanged. The new value is also exposed through `SubscriptionStats` as a > best-effort field. > > Because this adds per-subscription computation and one potential time series > per > subscription, the proposal introduces a dedicated broker configuration, > `exposeSubscriptionBacklogAgeInPrometheus`, defaulting to `false`. > When disabled, > the broker skips the per-subscription backlog age computation. When enabled, > the > broker computes and caches the value, and the Prometheus metric is emitted > through the existing topic/subscription metrics path when topic-level metrics > are enabled. > > Non-durable Reader subscriptions and non-persistent topics are intentionally > out > of scope for this PIP. > > Full proposal: https://github.com/apache/pulsar/pull/26362 > Implementation PR: https://github.com/apache/pulsar/pull/26313 > > > > Regards > Jiwei Guo (Tboy)
