HTTP filters or custom REST endpoint are not hit when non-application endpoints?

[ppatierno]

Hi,
trying to "intercept" the HTTP requests on the non-application /q/metrics endpoint but it seems that any @ServerResponseFilter or @ServerRequestFilter method is just skipped.
Is this on purpose?

[ppatierno]

Actually I decided to not using a filter but defining a REST endpoint for it. So the question now is ... is it possible to "override" the /q/metrics endpoint in order to have my code to be executed instead of the Quarkus built-in one?

[ppatierno]

Thanks @ebullient I think what's going on in the other discussion will meet our requirements.

[ppatierno]

@ebullient sorry to re-open this but ...

@ShubhamRwt implemented our "custom" registry the way you suggested here ...
ppatierno/strimzi-kafka-bridge@7888df3

and also we are now exposing the /q/metrics as /metrics (to take backward compatibility for our users), by using:
quarkus.micrometer.export.prometheus.path=/metrics

The problem is that we have this RestLoggingFilter which should be used for logging purposes but it doesn't kick in when we hit the /metrics (or /q/metrics endpoint).
https://github.com/ppatierno/strimzi-kafka-bridge/blob/road-to-quarkus/src/main/java/io/strimzi/kafka/bridge/quarkus/RestLoggingFilter.java

I can understand it's a non-application endpoint and maybe you want to avoid filter code doing something wrong.
What I can think of is creating a REST method in our API for the /metrics and calling the scrape on the Prometheus registry instance directly. Maybe you suggested that in the other discussion but we didn't get right?

While this should work, we should disable the /q/metrics endpoint. Is it possible?

[ebullient]

Non-application endpoints are not rest endpoints, they are handled by vertx directly. Rest filters will not be invoked on that path.

Are you trying to have all requests logged? have you tried using the Quarkus http access log? https://quarkus.io/guides/http-reference#configuring-http-access-logs

[ppatierno]

It's not so simple for us ... due to the Quarkus logging system we have already broken some backward compatibility on our Strimzi HTTP bridge for the users, which is pretty bad.
I don't see a way to use the HTTP access logs, unless users can configure to select a specific logging level for each REST endpoint (OpenAPI operation) this way:

quarkus.log.category."http.openapi.operation.healthy".level=WARN
quarkus.log.category."http.openapi.operation.ready".level=DEBUG

which already broke how it is done today with the following in a log4j2.properties file:

# HTTP OpenAPI specific logging levels (default is INFO)
# Logging healthy and ready endpoints is very verbose because of Kubernetes health checking.
logger.healthy.name = http.openapi.operation.healthy
logger.healthy.level = WARN
logger.ready.name = http.openapi.operation.ready
logger.ready.level = WARN

More details if you are interested in this discussion #32078

So I think a warkaround for us is declaring our own /metrics REST endpoint in order to scrape metrics but we need to disable /q/metrics to avoid having a duplication. Is it possible?

[ebullient]

You are so close now.. you can just remove the prometheus micrometer extension (and just include the base extension)..

You already have a meter registry producer (that will get picked up by the core micrometer extension)...

[ShubhamRwt]

We are currently using

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

so ,what you are suggesting is that we can use this instead

		<dependency>
			<groupId>io.quarkus</groupId>
			<artifactId>quarkus-micrometer</artifactId>
		</dependency>

right? If yes, then the other problem is that we are are extending PrometheusMeterRegistry which is coming through the Prometheus extension

[ShubhamRwt]

@ebullient ^^

[ebullient]

Correct. You need to bring in the prometheus registry explicitly:

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

You are already producing a PrometheusMeterRegistry. You may need to include this:

https://github.com/quarkusio/quarkus/blob/main/extensions/micrometer/runtime/src/main/java/io/quarkus/micrometer/runtime/export/PrometheusMeterRegistryProvider.java

[ShubhamRwt]

@ebullient I have done this step but I think that the \q\metrics endpoint is still enabled? Can't we disable it somehow?

[ppatierno]

@ebullient it's not clear how this would help to have our HTTP filter to kick in when the /metrics or /q/metrics endpoint is hit.
We tried but didn't work.
Or we are overlapping two different discussions?

[ShubhamRwt]

@ebullient Hi, Any suggestions/workarounds regarding this ?