shibd commented on code in PR #23945: URL: https://github.com/apache/pulsar/pull/23945#discussion_r1950178631
########## 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: We can't get real `remaining_msg_permits`, because if a subscription dispatch is throttled there may be limitations across three level (broker, topic, subscription), which can be **difficult** for users to assess. For example, if a broker has 1000 permits remaining, it might impose a restriction on this subscription, or it might not. -- 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]
