Remove DEBUG-level default logging from actions #51459
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In 2bb31fe (v0.6.0!) we added DEBUG-level logging to the default config of action loggers "for easier debugging". This change to the default config lives on to this day. It does not obviously make debugging any easier any more, but it does result in a good deal of log noise sometimes. This commit removes this special case from the default config. Closes elastic#51198
DaveCTurner
added
>enhancement
>breaking
:Core/Infra/Core
|
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
|
NB opened against |
jasontedor
approved these changes
Jan 26, 2020
There was a problem hiding this comment.
Users of the RPM/Debian packages that have made modifications to their log4j configuration file won’t receive this change. It might be worth remarking that such users need to manually apply this change to their deployed configuration. Up to you.
Otherwise, LGTM.
DaveCTurner
added a commit
that referenced
this pull request
Jan 27, 2020
In 2bb31fe (v0.6.0!) we added DEBUG-level logging to the default config of action loggers "for easier debugging". This change to the default config lives on to this day. It does not obviously make debugging any easier any more, but it does result in a good deal of log noise sometimes. This commit removes this special case from the default config. Closes #51198
|
Thanks Jason. I'm ok with leaving implicit the impact on RPM/Debian users you mentioned. I've tried to be careful to talk only about the default config everywhere; if you're not using the default config then your fate is in your own hands. |
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Mar 24, 2020
Today we log `failed to execute pipeline for a bulk request` at `ERROR` level if an attempt to run an ingest pipeline fails. A failure here is commonly due to an `EsRejectedExecutionException`. We also feed such failures back to the client and record the rejection in the threadpool statistics. In line with elastic#51459 there is no need to log failures within actions so noisily and with such urgency. It is better to leave it up to the client to react accordingly. Typically an `EsRejectedExecutionException` should result in the client backing off and retrying, so a failure here is not normally fatal enough to justify an `ERROR` log at all. This commit reduces the log level for this message to `DEBUG`.
DaveCTurner
added a commit
that referenced
this pull request
Mar 24, 2020
Today we log `failed to execute pipeline for a bulk request` at `ERROR` level if an attempt to run an ingest pipeline fails. A failure here is commonly due to an `EsRejectedExecutionException`. We also feed such failures back to the client and record the rejection in the threadpool statistics. In line with #51459 there is no need to log failures within actions so noisily and with such urgency. It is better to leave it up to the client to react accordingly. Typically an `EsRejectedExecutionException` should result in the client backing off and retrying, so a failure here is not normally fatal enough to justify an `ERROR` log at all. This commit reduces the log level for this message to `DEBUG`.
DaveCTurner
added a commit
that referenced
this pull request
Mar 24, 2020
Today we log `failed to execute pipeline for a bulk request` at `ERROR` level if an attempt to run an ingest pipeline fails. A failure here is commonly due to an `EsRejectedExecutionException`. We also feed such failures back to the client and record the rejection in the threadpool statistics. In line with #51459 there is no need to log failures within actions so noisily and with such urgency. It is better to leave it up to the client to react accordingly. Typically an `EsRejectedExecutionException` should result in the client backing off and retrying, so a failure here is not normally fatal enough to justify an `ERROR` log at all. This commit reduces the log level for this message to `DEBUG`.
This was referenced Apr 1, 2020
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
May 29, 2020
In elastic#51459 DEBUG-level logging was removed from the default log4j configuration. However, our docker build has its own log4j configuration which was missed in that change. This commit removes the same from the docker log4j configuration. relates elastic#51459 relates elastic#51198
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In 2bb31fe (v0.6.0!) we added DEBUG-level logging to the default config of
action loggers "for easier debugging". This change to the default config lives
on to this day. It does not obviously make debugging any easier any more, but
it does result in a good deal of log noise sometimes. This commit removes this
special case from the default config.
Closes #51198