-
Notifications
You must be signed in to change notification settings - Fork 589
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
[CORE-96]: admin/server fix set_log_level handling of overlapping expirations #18397
Merged
michael-redpanda
merged 5 commits into
redpanda-data:dev
from
andijcr:fix/trace_logging_stacked_deactivation
May 13, 2024
Merged
[CORE-96]: admin/server fix set_log_level handling of overlapping expirations #18397
michael-redpanda
merged 5 commits into
redpanda-data:dev
from
andijcr:fix/trace_logging_stacked_deactivation
May 13, 2024
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
_log_level_resets is a map<str, level_reset>, we want to extract the next expiring level_reset to rearm the _log_level_timer. previously we would extract the min_element based on the key (the logger name) so this sequence of actions set log-level kafka trace 10 set log-level raft trace 10 only kafka would be expired, because once expired the next run would pick again kafka, see that there is no expiration, and not rearm the timer.
the test shows that this sequence of actions set log-level admin-api-server trace 10 set log-level raft trace 10 works and both logger are reset after the expiry period
previously, this sequence of actions set log-level raft trace 10 set log-level raft error 0 would result in raft logging at error level for only 10 seconds, despite the legit request to expire never. this is because in the code, the second request would not correctly reset the expire field if a previous name-level_reset was already in the map used for this operation
test that set log-level admin_api_server trace 10 set log-level admin_api_server error 0 never resets the logger to the info level
andijcr
force-pushed
the
fix/trace_logging_stacked_deactivation
branch
from
May 10, 2024 16:33
48db97d
to
84748a8
Compare
andijcr
requested review from
a team,
pgellert and
oleiman
and removed request for
a team
May 10, 2024 16:34
oleiman
approved these changes
May 10, 2024
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.
LGTM. Thanks for fixing those 😅
pgellert
approved these changes
May 13, 2024
/backport v24.1.x |
/backport v23.3.x |
/backport v23.2.x |
Failed to create a backport PR to v23.2.x branch. I tried:
|
This was referenced May 13, 2024
Closed
Merged
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.
This PR fixes this two behaviors
overlapping expiration of different loggers
before
one logger expiration could shadow another logger expiration
log-level set kafka -l trace -e 30
log-level set raft -l trace -e 30
.. 30+ secs later
log-level get kafka -> info
log-level get raft -> trace
<- not being resetwith this pr
both loggers are reset correctly
log-level set kafka -l trace -e 30
log-level set raft -l trace -e 30
.. 30+ secs later
log-level get kafka -> info
log-level get raft -> info
<- correctly resetexpire-never request not being honored, if overlapping a previous request
a logger expiration could influence a subsequent request to set a level without expiration
note: this case in practice is probably never triggered, since the only level that shows anomalous behavior is
error
andwarn
, and they are not levels that are normally usedbefore
log-level set raft -l trace -e 30
log-level set raft -l error -e 0
<- 0 is for expire-never... 30+ secs later
log-level get raft -> info
<- reset to a default levelwith this pr
log-level set raft -l trace -e 30
log-level set raft -l error -e 0
<- 0 is for expire-never... 30+ secs later
log-level get raft -> error
<- keeps its valueFixes CORE-96
Backports Required
Release Notes
Bug Fixes