Spring Boot logging and missing traces

[Cimballi]

test-spring-logging.zip
From spring-projects/spring-boot#27406

I think there is a bug / problem in the way Spring Boot configures logging with Logback.

Using Spring Boot 2.4.8 and Spring Cloud Aws 2.31, I created a minimalist Spring Boot application with a dependency on "spring-cloud-starter-aws-parameter-store-config" using paramstore.

If I do not set any AWS credentials, the AWS SDK cannot connect, so there is an error. But Spring Boot only logs :

ERROR | org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter              | report                                   | 

***************************
APPLICATION FAILED TO START
***************************

I also added a test class without Spring Boot, using Logback and a similar AWS call, and the logs contain :

DEBUG | com.amazonaws.auth.AWSCredentialsProviderChain                                   | getCredentials                           | Unable to load credentials from WebIdentityTokenCredentialsProvider: To use assume role profiles the aws-java-sdk-sts module must be on the class path.
DEBUG | com.amazonaws.auth.AWSCredentialsProviderChain                                   | getCredentials                           | Unable to load credentials from com.amazonaws.auth.profile.ProfileCredentialsProvider@5ce4369b: Unable to load credentials into profile [default]: AWS Access Key ID is not specified.
WARN  | com.amazonaws.internal.InstanceMetadataServiceResourceFetcher                    | handleException                          | Fail to retrieve token 
com.amazonaws.SdkClientException: Failed to connect to service endpoint: 

So, as you can see all, those AWS logs are missing when using Spring Boot.
test-spring-logging.zip

[maciejwalkowiak]

Thanks for reporting. As Andy explained in linked Spring Boot issue, AWS logs are not printed as the logging subsystem isn't ready yet. We cannot though use DeferredLog as this is a 3rd party package. We can make the logging message more self explanatory though.

Currently when I run your sample, I am getting following error message:

***************************
APPLICATION FAILED TO START
***************************

Description:

Config data resource '[AwsParamStoreConfigDataResource@758705fa context = '/config/application/', optional = false]' via location 'aws-parameterstore:' does not exist

Action:

Check that the value 'aws-parameterstore:' at class path resource [application.yml] - 13:15 is correct, or prefix it with 'optional:'

which gets resolved through ConfigDataNotFoundFailureAnalyzer. The actual cause of this exception is:

com.amazonaws.SdkClientException: Unable to find a region via the region provider chain. Must provide an explicit region in the builder or setup environment to supply a region.

We could make it more self explanatory in AwsParamStoreConfigDataLoader and instead of simply throwing ConfigDataResourceNotFoundException, make a special case for SdkClientException when region or credentials cannot be resolved.

[Lucas3oo]

It would also be helpful if the execution message adds all context is can find.
Like which profiles are active etc.
I get this weird issue only in Fargate and not locally that the parameter store path is appended with the "default" profile.
E.g. /config/application_default

I don't have any spring profile settings defined (but I can't be 100% since the log is not there during startup.)

[maciejwalkowiak]

@Lucas3oo "default" profile is the profile that is active when no other profile is active, perhaps this is where its coming from.

Have you considered using spring.config.import= instead?

[Lucas3oo]

But the thing is it didn't act like this in previous version of Spring AWS cloud.
And why using spring.config.import= when the existing setup worked very well (until someone changed it)
I am not happy to change some setup that works. With spring.config.import= you still have to configure which "context" to read from so I don't see that way is any better.

[maciejwalkowiak]

In merged PR i enabled logging for both spring.config.import and bootstrap so once 2.3.4 is released you should be able to see exactly which contexts are looked up in parameter store and which properties are loaded from this property source.