Environment Report when running with -Ddebug=true

[twicksell]

Similar to the autoconfig report, it would be very helpful to print the output of the Environment actuator when the debug flag is set.

This would help to debug failures related to invalid or missing properties, particularly in a setup where properties come from dynamic sources such as the Spring Cloud Config Server.

[philwebb]

I'm worried this might be a bit overwhelming, but it could be a good opt-in setting.

[twicksell]

Agreed, and when I'm facing a property issue its generally pretty obvious so opting in would be simple. There is a certain beauty to having all debug info displayed via a single property, but equally important to avoid information overload.

[snicoll]

@twicksell would #10030 a way to mitigate this problem?

[twicksell]

I think it would solve it for some cases, but still miss others. Imagine an app with a startup failure around not being able to connect to the database. I might have a different jdbc url configured for each profile, as well as override values coming out of a remote config server. All of the values could be considered "valid", but I would still have no way of verifying which value was being selected at startup time.

It looks like #10030 would be a useful shortcut to diagnosing one type of problem, but for what I'm experiencing I believe I'd still need the full output of the environment. We should also consider the case where property reading is not happening in @ConfigurationProperties. These startup failures can stem from user code as well.

[judomu]

@philwebb @snicoll Where would be the right place to implement such an enhancement? The similiar functionality for the autoconfiguration report is part of spring-boot-autoconfigure. Would it be suitable to put it in org.springframework.boot.logging? But unfortunately the functionality would have a strong overlap with EnvironmentEndpoint

[snicoll]

@julmuell thanks for the delay. I don't know really but reviewing this issue made me wonder why @twicksell was mentioning the actuator. The auto-configuration report is a "core" (i.e. non actuator feature) and adding the environment as an extra piece in the logs would also be actuator-independent.

ConditionEvaluationReport is the component that tracks condition evaluations and ConditionEvaluationReportLoggingListener is the component that triggers the log.

Adding the environment in there would bring a few challenges:

• There are potential sensible information so we need to apply the sanitizer (yet this is an actuator feature)
• The complete environment is not strictly related to condition evaluations so dumping everything feels unrelated to me

If we have an opt-in flag, that could be a completely separate concern (and therefore could be a proper answer for those two items). I just don't know how to name that. If you want to spike on it based on this feedback, I am happy to guide you (we're on Gitter as well).