Create metrics API proof of concept

[jvz]

Related to #1344, this demonstrates a proof of concept metrics API to begin using. This implements the metric added in #1927, though I think we should be defining several more metrics beyond that. Before going too far into this idea, here's the gist of what I've come up with so far. API is loosely based on Micrometer which will be added as an implementation (probably its own module; this is effectively a plugin).

[rgoers]

This PR has me very confused. I do see the new metrics package but the vast majority of this PR seems to have nothing to do with metrics. Could you please separate out the builder improvements into their own PR?

[jvz]

The builder updates are related to adding dependency-injected values. I did not include any concrete implementations of the metrics API yet, but I updated some areas that are supposed to export metrics.

[jvz]

Or to be more specific, instead of creating yet another global variable, I had to refactor some code to apply inversion of control a little bit. If we were adapting Log4j to work via Spring beans, we'd still have to do the exact same thing.

[jvz]

What sort of event would be published here that could correspond to a counter? That's a push-based mechanism itself.

[jvz]

Looking through https://opentelemetry.io/docs/specs/otel/logs/ and OTel in general, it seems like we should have support for some of this directly. I don't think we need to implement all the APIs (like metrics and traces, though they might be natural logging APIs to include in the future). The alternative is a dependency stack larger than Log4j 2.x with optional dependencies in practice.

[ppkarwasz]

What sort of event would be published here that could correspond to a counter? That's a push-based mechanism itself.

For me an event is just any kind of object: in this case long is an event. ;-) So stripped to the bone we need methods that return long and methods that consume Supplier<Long>.

[ppkarwasz]

@jvz,

I think we could choose an approach similar to RxJavaHooks to provide instrumentation hooks without affecting the performance of our application.

For 2.x we could create an InstrumentationService to give users the possibility to wrap our most important services:

public interface InstrumentationService {

    ReliabilityStrategy instrumentReliabilityStrategy(ReliabilityStrategy strategy);

    MessageFactory instrumentMessageFactory(MessageFactory factory);

    LogEventFactory instrumentEventFactory(LogEventFactory factory);

    AsyncQueueFullPolicy instrumentQueueFullPolicy(AsyncQueueFullPolicy policy);

    Appender instrumentAppender(Appender appender);
}

The default implementation would of course return the argument unchanged. What do you think?

For 3.x I believe that users can use the DI system to post-process these services.

Can we close this PR?

[jvz]

I think that's a good idea.