Provide raw counters metrics
See original GitHub issueIs your feature request related to a problem? Please describe.
Pulsar is offering many built-in metrics, which is pretty awesome. You can find metrics on any layer, from the pulsar-proxy to Bookkeeper. There are easy to plot within Grafana as most of the rate are already computed, for example pulsar_throughput_in
is directly offering the total throughput of the namespace coming into this broker in bytes/second.
However, for some usages, metrics based on rate are not enough. For example, to bill users according to messages produced, you cannot rely on a rate, you need the raw counter
associated.
Describe the solution you’d like
I would like to add a new boolean to the configuration exposeTopicLevelMetricsAsCounterInPrometheus
, which default is false. By setting it to true, broker will expose new counter metrics, which will be the raw counters used to compute the rates internally. The new metrics could be suffixed by _counter, for example:
- pulsar_throughput_in_counter
- pulsar_in_counter
and so on. We could also do the same work for any metrics which are a rate, but I think we should start with the topic metrics
.
Describe alternatives you’ve considered Using the rate to compute the counter is not offering enough precision.
What do you think about it? We can discuss on the name of the parameter and the naming schemas.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:7 (7 by maintainers)
Top GitHub Comments
@PierreZ +1
Can I suggest using names like “pulsar_in_bytes_total” or “pulsar_in_bytes_counter”, “pulsar_in_messages_total” or “pulsar_in_messages_counter”?
Thanks, I will do this 👍