📣 HELP make Pulsar Metrics better 📣 Today I raised a PIP (Pulsar Improvement Proposal), PIP-264, to solve two major problems for users of Pulsar: • Monitoring brokers with large topic count • No fine-grained control for metrics exporting PIP-264, will be OpenTelemetry-based, and improve so many aspects of Pulsar Metrics. Just to name a few of its goals: • Allow monitoring Pulsar broker with very high topic count (10k - 1M), without paying the price of high cardinality, by providing a mechanism which aggregates topic-level metrics to an aggregation level called Topic Metric Group which the operator controls dynamically. • Allow dictating (filtering) which metrics will be exported, per any granularity level metrics: namespace, topic metric group, topic, consumer, producer, subscription. • Provide a rich typed interface to hook into Pulsar metrics system for Plugin authors • Make histogram reporting conformant with Prometheus when exported to Prometheus format • Provide ability in the future to correlated metrics with logs and traces, by sharing context • Support the most efficient observability protocol, OTLP. • Stop using delta reset, everywhere, including function metrics • All Pulsar metrics are properly named following a well-defined convention, adhering to OTel Semantic Conventions for instrument and attribute naming where possible This proposal both improve Pulsar observability immensely, with the cost of non backward compatible changes. I would really appreciate any time you can allocate to reading and providing feedback 🙏 https://github.com/apache/pulsar/issues/20197