@Gauge of SmallRye Metrics not working in API Rest Beans - not managed by CDI

[RayanArgolo03]

Describe the bug

``

public final class AuthenticationResource {

public static final String RESOURCE_PATH = "/api/v1/auth";

@Inject
AuthenticationService authenticationService;

@Inject
KeycloakService keycloakService;

@Inject
MailerService mailerService;

@Inject
ClientService clientService;

@Inject
Logger log;

@Inject
UriInfo uriInfo;

//Receives exception
@GET
@PermitAll
@Gauge(name = "auth.testing", absolute = true, unit = MetricUnits.GIGABYTES)
@Path("/free-memory")
public Response getFreeMemory() {
    return Response.ok(clientService.getFreeMemory())
            .build();
}

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

19

Output of java -version

17

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @Ladicek (arc,smallrye), @ebullient (metrics), @jmartisk (metrics,smallrye), @manovotn (arc), @mkouba (arc), @phillip-kruger (smallrye), @radcortez (smallrye)

[Ladicek]

Could you please paste the full stack trace? The snippet doesn't even show who is trying to obtain an instance of the bean while the request context is not active.

[jmartisk]

Mixing a Gauge into a REST API is wrong and you should split out the gauge into a separate application-scoped bean. A gauge also can only return a numeric value (long or double), not a Response.

[RayanArgolo03]

Mixing a Gauge into a REST API is wrong and you should split out the gauge into a separate application-scoped bean. A gauge also can only return a numeric value (long or double), not a Response.

Perfect, I understand. Now, the code loses readability by separating the metrics into different layers, resources (Timed, Metered) and beans/services (Gauge), for example. How to do it?

[ebullient]

Note that there are already request-bound metrics for http requests coming directly from the micrometer extension http-*, as noted in the docs: https://quarkus.io/guides/telemetry-micrometer#automatically-generated-metrics

What you're adding here is redundant and unnecessary as well as unsupported (as I explained in your other issue/discussion and @jmartisk has reiterated).

I think your understanding of how to provide a gauge is also not quite right. You're measuring something on a clientService. Tying that gauge to a rest method doesn't make a lot of sense: you've got the concern in the wrong place.

To Jan's point about using another bean as the gauge: If you want that rest method to be able to observe the current value of that gauge, there are a few different ways to look up the associated/generated gauge bean to return what the most current observed value is.