How can I prevent Micrometer from adding _total suffix to Counter metric name

Question

In my code I define my custom (counter) metric as follows:

Counter.builder("request_count")
            .tags("method","GET")
            .tags("path","/my/test/path")
            .register(meterRegistry)
            .increment();

You'll note the metric name is defined as request_count However when I run the application the metric is being published as follows:

# HELP request_count_total  
# TYPE request_count_total counter
request_count_total{method="GET",path="/my/test/path"} 1.0

Note the _total suffix being appended to the metric name. Apparently this is being cause by the default PrometheusNamingConvention and thus I override this class and provide a custom name() implementation which explicitly omits the process of appending the _total suffix. However this STILL results in the metric being published with the suffix.

On attaching a debugger to the application and tracing through the code, I determined that this is because any defined custom NamingConvention class, in respect of the counter metric, is ultimately ignored as the internal PrometheusMeterRegistry class defines a CollectorRegistry which updates all counter metric names to include the _total suffix, just before the metric is published. Here a snippet from the CollectorRegistry.collectorNames() method that undertakes the renaming:

 while(var4.hasNext()) {
        Collector.MetricFamilySamples family = (Collector.MetricFamilySamples)var4.next();
        switch (family.type) {
            case COUNTER:
                names.add(family.name + "_total");
                names.add(family.name + "_created");
                names.add(family.name);
                break;

Thus, it would seem to me that, the only conceivable option at this point would be to use the PrometheusMeterRegistry class directly; it's constructor allows for the specification of a CollectorRegistry instance and ergo I should be able to pass in a custom implementation of this class that does not undertake this renaming operation. My question essentially is:

1)Aside from tying down the Micometer to a single implementation (i.e prometheus) are there any other down sides to this approach?

2)Could you point me to any documentation that provides examples of making use of the PrometheusMeterRegistry directly?

Kleper

This is probably none of my business but breaking conventions must have a solid reason behind it. This suffix makes it easier for people and tools (such as Grafana) to identify with what kind of data you're dealing with, and a counter is one of those things when it's best to know that it is indeed a counter. I hope the effort you are putting into this and the troubles you may cause to whoever will inherit this solution are well worth it, otherwise I'd rather suggested to drop the idea. – Hawking

Any luck on this? – Brightman

@Hawking There is a simple reason- you can count requests of type A, requests of type B and request in total- three different counters, but only one is a total. Marking a Meter as counter can be done for example by some specific tag, for example micrometer.tag.type=counter. Making people happy when they do not expect that, with no option to disable is not best soliution. – Electrothermal