Provide a log server configuration providerl

[thompson-tomo]

Is your feature request related to a problem? Please describe.

I want to be able to use the logger actuator provided by steeltoe as a source of configuration for my application

Describe the solution you'd like

Able to register a configuration provider which polls the logger actuator to obtain back the configured loggers so that it can be used with third party logger frameworks

As part of the initialisation of the configuration provider a transformer can be specified.

The transformer is implemented via a public interface which contains a method to transform the response to a structure compatible with the logging providers

Describe alternatives you've considered

Provide data via config server

Additional context

Transformers needed to be available:

• Microsoft

Additional transformers for the future

• Serilog
• Nlog

[bart-vmware]

I want to be able to use the logger actuator provided by steeltoe as a source of configuration for my application

What problem does this solve?

Please bear in mind the loggers actuator exists for parity with Spring Boot Admin and Cloud Foundry. It enables to temporarily adjust minimum log levels on a single app instance for diagnosing a problem in production, without the need to restart that server first. Adjustments are stored in-memory and disappear on restart.

The typical scenario in production is increasing the minimum levels on a single app instance, then send a request, then reduce the levels again. Possibly first taking the instance out of the load balancer. This is because higher log levels typically cause severe degradation of performance.

It is not a system to centrally manage minimum levels over multiple app instances. IConfiguration should be used for that, which can read from various sources, including Config Server. Steeltoe v4 adds support for detecting changes in IConfiguration and updates the logger levels on change (unless locally overridden, obviously, then it applies the changed settings on reset). This is all implemented behind IDynamicLoggerProvider and unrelated to the implementation of the loggers actuator.

Given that multiple instances typically have different levels active in time, I don't think it makes sense to somehow merge them and send that back to a central configuration source.