-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Skip stacktrace in info log for s3 region loading issue #131587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Skip stacktrace in info log for s3 region loading issue #131587
Conversation
The stacktrace is rather excessive given the level of the log message. The information provided in the exception message should be sufficient for taking actions. Also adjust the wording to better match the contribuation guide for logging messages.
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I think we need all the inner detail sometimes. But you're right that it'd be best not to emit this when starting the node since many nodes will not need this detail. Instead, I would rather we captured the exception here and then only emit the log message (once per node run) if org.elasticsearch.repositories.s3.S3Service#getClientRegion
falls through to trying to use the default region.
The stacktrace is something like the followings
I don't see how they are useful other than the part that is preserved in this PR, i.e.:
Info logs are meant to be read by end-users. I'd think we don't want to burden them with the stacktrace which does not really add more value for them taking actions? |
I suspect there may sometimes be more detail in some inner exceptions.
Exactly, that's why I think we shouldn't log anything unless there's actually some action to take, which would only be because ETA: I opened ES-12449 to track this work. |
The stacktrace is rather excessive given the level of the log message. The information provided in the exception message should be sufficient for taking actions. Also adjust the wording to better match the contribuation guide for logging messages.