I run applications with camel/cxf in quarkus (3.15.3) and use quarkus-micrometer-registry-prometheus. I have a CustomMetrics class that updates the standardized metric value http_server_requests_seconds with information about which exception was thrown.

Everything works fine as long as the camel route works as it should and my custom metric class is triggered. Some of our applications have camel routers that sometimes lose their concept, causing the custom metric class not to be triggered, and instead the default Quarkus Micrometer/Prometheus metric runs, which does not include exception as a parameter in the metric logging.

The problem that arises with this is that since both create metric logging with the same name but different tag structures, the one that runs first after program start will "define" the metric's structure. This leads to:

• If the custom metric logging runs first after restart, exceptions are logged correctly but I lose logging from the default metric because it lacks the exception tag.
• If the standard metric is created first, the exception tag is missing in all subsequent metrics.
• This leads to inconsistent metric data depending on the order in which different routes are called after restart.

I have tested the following:

MetricInitializer Created a class that pre-registers metric templates at application startup so that the structure is in place before any routes run. It fetches URIs from configuration and registers templates for different HTTP methods and response codes.

MetricsConfiguration Implemented a MeterFilter that checks if metrics of type HTTP_SERVER_REQUESTS_SECONDS lack an exception tag, and if so, adds "None".

GlobalMetricsConfiguration Uses a static initializer to register a MeterFilter very early in the application lifecycle, even before the CDI context is ready.

Config parameters in application.properties Tested the following parameters to try to get the default metric to add exception as a parameter in logging:

• quarkus.micrometer.binder.http-server.enable-exception-tag=true
• quarkus.micrometer.binder.http-server.exceptions=true
• quarkus.micrometer.binder.http-client.enable-exception-tag=true
• quarkus.micrometer.binder.http.server.recording-exceptions-enabled=true

None of the above parameters are recognized or accepted by quarkus 3.15.3.

How do you get the logging that occurs via the default Quarkus Micrometer/Prometheus metric to add exeption as a parameter?

I can add that in my pom.xml I have the following dependencies:

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-micrometer-registry-prometheus</artifactId>
</dependency>
<dependency>
   <groupId>.apache.camel.quarkus</groupId>
   <artifactId>camel-quarkus-micrometer</artifactId>
</dependency>

UPDATE:

I have partially solved the problem now. I got MetricInitializer to instantiate so that metric logging always contains exception, setting the value 'None' for HTTP 200. This at least ensures that I don't lose exceptions when they go through my custom metric class.

The problem that still remains is when the route loses the concept and the general metric handling is triggered. That logging is now lost because the 'metric template' set at startup should contain exception. I've created a MetricsConfiguration class where I'm trying to modify the metric logging when it's created at runtime, which looks like this:

@ApplicationScoped
@Priority(1) 
public class MetricsConfiguration {
    
    private static final String EXCEPTION_CONST = "exception";
    
    @Inject
    MeterRegistry registry;
    
    @PostConstruct
    public void init() {
        

        MeterFilter filter = new MeterFilter() {
            @Override
            public Meter.Id map(Meter.Id id) {
                if (id.getName().equals(CustomMetrics.HTTP_SERVER_REQUESTS_SECONDS)) {
                            
                    if (id.getTag(EXCEPTION_CONST) == null) {
                        return id.withTag(Tag.of(EXCEPTION_CONST, "None"));
                    }
                }
                return id;
            }
        };
        
        
        registry.config().meterFilter(filter);
        
    }

For some reason, this is not triggered. I don't know if Camel is causing issues in some way.