You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
This change reduces the amount of logging we do for an HTTP response in non-error cases by moving those logs to debug instead of info.
In particular we generate a TON of logs for for asynchronous operations where the API is being polled at 1 second intervals by the CLI. Since it's hitting the operation status endpoint, the status code is always 200 and not especially meaningful.
This change simplifies the logging by applying the following rules:
Non-2XX status codes continue to be logged at info level.
2XX status code are now logged at debug level (off by default).
My motivation for this change is to make the logs more readable by making the more significant events visible. Right now it's hard to find significant events in our logs because there is a flood of "responded with 200" type events due to the nature of async operations. When an async operation is taking a long time to process, the relevant information might be 100s of lines back in the history.
I've been testing this out locally for a few days of work and I feel like it's really improved my ability to diagnose issues.
Type of change
This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:
An overview of proposed schema changes is included in a linked GitHub issue.
A design document PR is created in the design-notes repository, if new APIs are being introduced.
If applicable, design document has been reviewed and approved by Radius maintainers/approvers.
A PR for the samples repository is created, if existing samples are affected by the changes in this PR.
A PR for the documentation repository is created, if the changes in this PR affect the documentation or any user facing updates are made.
A PR for the recipes repository is created, if existing recipes are affected by the changes in this PR.
This change reduces the amount of logging we do in non-error cases by moving those logs to debug instead of info.
In particular we generate a TON of logs for for asynchronous operations where the API is being polled at 1 second intervals by the CLI. Since it's hitting the operation status endpoint, the status code is always 200 and not especially meaningful.
This change simplifies the logging by applying the following rules:
- Non-2XX status codes continue to be logged at info level.
- 2XX status code are now logged at debug level (off by default).
Signed-off-by: Ryan Nowak <[email protected]>
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.
rynowak
temporarily deployed
to
functional-tests
GitHub Actions
Inactive
Description
This change reduces the amount of logging we do for an HTTP response in non-error cases by moving those logs to debug instead of info.
In particular we generate a TON of logs for for asynchronous operations where the API is being polled at 1 second intervals by the CLI. Since it's hitting the operation status endpoint, the status code is always 200 and not especially meaningful.
This change simplifies the logging by applying the following rules:
My motivation for this change is to make the logs more readable by making the more significant events visible. Right now it's hard to find significant events in our logs because there is a flood of "responded with 200" type events due to the nature of async operations. When an async operation is taking a long time to process, the relevant information might be 100s of lines back in the history.
I've been testing this out locally for a few days of work and I feel like it's really improved my ability to diagnose issues.
Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable: