poorbarcode commented on code in PR #23945: URL: https://github.com/apache/pulsar/pull/23945#discussion_r1950109449
########## pip/pip-406.md: ########## @@ -0,0 +1,75 @@ +# PIP-406: Introduce pulsar_subscription_dispatch_throttled_msgs and bytes metrics + +# Background knowledge + +## Motivation + +Currently, users can monitor subscription backlogs using the `pulsar_subscription_back_log_no_delayed` metric. +However, if [dispatch throttling](https://pulsar.apache.org/docs/next/concepts-throttling/) is configured at the broker/topic/subscription level, +this metric may not accurately reflect whether the backlog is due to insufficient consumer capacity, as it could be caused by dispatch throttling. + +## Goals + +Introduce metrics to indicate the number of `messages/bytes throttled` for a subscription. This allows users to write PromQL queries to identify subscriptions with high backlogs but low or no throttling, pinpointing backlogs caused by insufficient consumer capacity. + +## In Scope +- Introduce the metric `pulsar_subscription_dispatch_throttled_msgs` to represent the total number of messages throttled for a subscription. +- Introduce the metric `pulsar_subscription_dispatch_throttled_bytes` to represent the total number of bytes throttled for a subscription. +- Add `dispatchThrottledMsgs` and `dispatchThrottledBytes` fields to topic subscription stats. Review Comment: Maybe `remaining_msg_permits` is more meaningful, because the value of `pulsar_subscription_dispatch_throttled_msgs` will keep increasing once the throttling worked -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
