Thanks for the feedback — I did consider a unified metric, but kept them separate for a few reasons:
1. Consistency with existing conventions: Kafka already organizes metrics by component (e.g., `kafka.log:type=Log` for local log metrics and `kafka.log.remote:type=RemoteLogManager` for tiered storage). This proposal follows that established pattern. 2. Implementation boundaries: For non-tiered topics, `SizeInPercent` is computed entirely within the `Log` class, whereas for tiered topics the total size requires `RemoteLogManager` to account for remote segments. The JMX paths reflect where the metric is produced. 3. Clarity for operators: Separate MBeans make it explicit whether the metric applies to a tiered or non-tiered storage model. That said, I agree the semantic meaning of `SizeInPercent` is the same in both cases. If there’s a strong preference for exposing it under a single, unified MBean to simplify dashboards and alerting, I’m open to exploring that, as long as we can do so without breaking existing metric organization conventions. Happy to hear thoughts. On 2026/01/08 09:40:09 Satish Duggana wrote: > Thanks Manan, for the KIP. > > These new metrics are very helpful in operations and capacity planning > of the cluster. > > I have one minor comment on the usage of the metric 'SizeInPercent' > which they have to define individually for both tiered and non-tiered > topics. Did you think about having a single mbean metric for both > tiered or no tiered topics for 'SizeInPercent'? > > ~Satish. > > On Thu, 8 Jan 2026 at 11:42, Kamal Chandraprakash > <[email protected]> wrote: > > > > Hi Manan, > > > > Thanks for the KIP! > > > > The new `sizeInPercent` and `localSizeInPercen`t metrics will be useful > > over the absolute partition size metrics > > for the admin to plan and provision the cluster. > > > > The admin can configure an alert on LocalSizeInPercent metric to ensure > > that the data kept in the local disk > > is up to the configured local-retention time. This will save remote read > > costs. The proposal LGTM. > > > > Thanks, > > Kamal > > > > On Tue, Dec 16, 2025 at 6:58 PM Manan Gupta <[email protected]> wrote: > > > > > Hi all, > > > > > > This email starts the discussion thread for KIP-1257: Partition Size > > > Percentage Metrics for Storage Monitoring. This KIP introduces > > > retention-aware, percentage-based partition metrics that significantly > > > improve Kafka’s storage observability. The proposed metrics simplify > > > alerting, enhance capacity planning, and provide clear visibility into > > > retention pressure—especially for tiered storage—while remaining > > > lightweight, backward compatible, and operationally intuitive. > > > > > > I'd appreciate your initial thoughts and feedback on the proposal. > > > https://cwiki.apache.org/confluence/x/MAEXG > > > > > > > > > Thanks, > > > Manan > > > >
