Allow customization of log levels

[turing85]

Is your feature request related to RFC7807? Please describe.
No.

Describe the solution you'd like
Currently, the ProblemLogger logs everything to log level INFO when the response is < 500 and everything >=500 on level ERROR.

It would be nice to:

• have a way to turn off logging completely (without setting the min-level for http-problem to FATAL),
• be able to define a default log level, and
• to be able to define a log level per response code and/or response code range (e.g. 401 and 403 on level WARN, everything else < 500 on level INFO, everything >= 500 on level WARN)

Additional information
This is slightly related to #512, but #512 focuses on stack traces, while this issue focuses on the log level.

[turing85]

I have some ideas to implement this feature. I am willing to send a PR if you give me the go-ahead.

[melloware]

@turing85 i would say submit your PR

[lwitkowski]

@turing85 I have to admit that the current choice of log levels is not ideal. In particular, 2xx and 3xx responses probably should not be logged at INFO; that decision was rather arbitrary.

And your request makes a lot of sense. Including #512

Before discussing implementation details, I think we should first settle on the developer-facing configuration API. Something along these lines could work, with the following defaults:

# or it should be disabled by default? hmm
quarkus.http-problem.logging.enabled=true

# aligned with quarkus.log.category.<loggername>.level=??
quarkus.http-problem.logging.logger-name=http-problem

# that would be a breaking change, but maybe worth it?
quarkus.http-problem.logging.level.2xx=DEBUG
quarkus.http-problem.logging.level.3xx=DEBUG
quarkus.http-problem.logging.level.4xx=DEBUG # or INFO?
quarkus.http-problem.logging.level.5xx=ERROR

quarkus.http-problem.logging.include-stack-trace=5xx

And below some specific overrides:

quarkus.http-problem.logging.level.4xx=WARN
quarkus.http-problem.logging.level.5xx=FATAL

# specific response code
quarkus.http-problem.logging.level.301=WARN

# enable stack traces for certain families/codes
quarkus.http-problem.logging.include-stack-trace=5xx,403,401,418,301

I’m very open to discussion, though. My personal preference would be to keep this simple and local: no 400-420 range syntax, no rule engine, just status classes such as 4xx/5xx plus exact status-code overrides.

Another decision to be made is whether this can stay as build-time config - as of today, we no longer have any runtime configuration in this extension, and I'd like to keep it that way unless there's strong reason not to. This feature might be such a reason, I would need your input on how you intend to use it? Set it once and for all (build time) or override it per deployment/environment (runtime)?
One strong indication all the above should be a runtime config is quarkus.log.category.* being runtime configs.

[melloware]

@lwitkowski your proposal sounds great to me balancing nice config without going crazy.

[modax]

Hi!

@lwitkowski I would vote for runtime configuration if possible. But probably build time is still acceptable.

The problem we also face is that it is not possible to customize logging per ExceptionMapper (unless we drop ExceptionMapperBase completely). At this time, we cannot do this either programmatically or declaratively.

1. postProcessorsRegistry is static. Maybe it should be possible to supply a manually created instance via an additional constructor.
2. It is impossible to remove the default ProblemLogger from postProcessorsRegistry or customize how it is constructed.

As far as I can tell, your proposal is more about declarative configuration of the "default" instance rather than being able to have multiple variants of it. So I believe both approaches should be possible. Programmatic customization gives a lot flexibility so declarative configuration can be simpler.

[lwitkowski]

Hey @modax, thanks a lot for the input!

The problem we also face is that it is not possible to customize logging per ExceptionMapper (unless we drop ExceptionMapperBase completely). At this time, we cannot do this either programmatically or declaratively.

1. postProcessorsRegistry is static. Maybe it should be possible to supply a manually created instance via an additional constructor.

That's not fully accurate, you can easily define your own PostProcessor, have a look at this section of the readme.

3. It is impossible to remove the default ProblemLogger from postProcessorsRegistry or customise how it is constructed.>

Well, you can achieve this by setting logger category http-problem to OFF. Not super clean solution, but should help getting what you need.

As far as I can tell, your proposal is more about declarative configuration of the "default" instance rather than being able to have multiple variants of it. So I believe both approaches should be possible. Programmatic customization gives a lot flexibility so declarative configuration can be simpler.

Yes, my proposal is to make built-in logging configurable, including disabling it completely with dedicated boolean flag. Or even making it opt-in (disabled by default).

[modax]

Hey @lwitkowski!

That's not fully accurate, you can easily define your own PostProcessor, have a look at this section of the readme.

Yep, I'm aware of CDI stuff but it is still global rather than per-mapper specific.

But as I see I'm probably hijacking this issue at this point. Do you think this programmatic per-mapper customization/freedom is an option? I could go straight to PR on it.

Your original proposal is still very useful.

[lwitkowski]

Ah yes, that's true, it's not possible per-mapper, and I don't see how we could add this with reasonable effort to be frank.

[modax]

Ah yes, that's true, it's not possible per-mapper, and I don't see how we could add this with reasonable effort to be frank.

I published my take on "programmatic per-mapper customization" in the PR.

[lwitkowski]

@modax we need to move this discussion to separate issue, it has basically nothing to do with the topic.

[melloware]

@modax yes i would open a new ticket with your requirements