-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Added duration filter for logs #3463
Added duration filter for logs #3463
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Hi @rodrigodiez,
great to see your first PR on Traefk and thanks for the contribution! I left a couple of comments, the PR looks very good in general!
One general thing I wanted to suggest is that we re-name the parameter to minDuration
. I think that would make it more explicit what the parameter does. WDYT?
docs/configuration/logs.md
Outdated
@@ -159,6 +161,13 @@ format = "json" | |||
# Default: false | |||
# | |||
retryAttempts = true | |||
|
|||
# duration keep access logs when request took more than the specified duration |
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.
Nit-pick: can we add a :
after the filter name for this and the previous explanations? E.g. # duration: keep access logs..
.
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.
I'm not entirely sure but I think it should also be when a request took longer than ..
. Maybe @dtomcej can help out here :-)
middlewares/accesslog/logger.go
Outdated
@@ -322,6 +324,10 @@ func (l *LogHandler) keepAccessLog(statusCode, retryAttempts int) bool { | |||
return true | |||
} | |||
|
|||
if l.config.Filters.Duration > 0 && (parse.Duration(duration) > l.config.Filters.Duration) { |
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.
I think we can skip the first check on the Duration > 0
. If it's 0 the duration
will be larger anyway.
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.
This check is needed to ensure the filter has been set up. Otherwise the log will be kept 100% of the times since Duration zero value is 0
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.
Yes, you're right, now I got it. Thanks for explaining!
types/logs.go
Outdated
RetryAttempts bool `json:"retryAttempts,omitempty" description:"Keep access logs when at least one retry happened" export:"true"` | ||
StatusCodes StatusCodes `json:"statusCodes,omitempty" description:"Keep access logs with status codes in the specified range" export:"true"` | ||
RetryAttempts bool `json:"retryAttempts,omitempty" description:"Keep access logs when at least one retry happened" export:"true"` | ||
Duration parse.Duration `json:"duration,omitempty" description:"Keep access logs with response times above the specific duration" export:"true"` |
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.
Is it possible to use time.Duration
as type as well? I'm not so much into the flaeg
stuff. Maybe @ldez knows which type is best to use here. I saw time.Duration
as example in the flaeg README, but on other places we use flaeg.Duration
mostly. I'm not sure which one we should use.
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.
flaeg.Duration
is replaced by parse.Duration
.
parse.Duration
is the good type for the configuration.
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.
Hey @marco-jantke, thanks for reviewing and for your comments! They make total sense.
I wrote a response to one of your comments explaining why we need a > 0 check but other than that I've adressed everything 👍
middlewares/accesslog/logger.go
Outdated
@@ -322,6 +324,10 @@ func (l *LogHandler) keepAccessLog(statusCode, retryAttempts int) bool { | |||
return true | |||
} | |||
|
|||
if l.config.Filters.Duration > 0 && (parse.Duration(duration) > l.config.Filters.Duration) { |
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.
This check is needed to ensure the filter has been set up. Otherwise the log will be kept 100% of the times since Duration zero value is 0
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, nice job 👏
thanks! And please keep adding begginer tasks, they are so valuable! |
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.
Very close!
@@ -146,19 +148,26 @@ format = "json" | |||
|
|||
[accessLog.filters] | |||
|
|||
# statusCodes keep access logs with status codes in the specified range | |||
# statusCodes: keep access logs with status codes in the specified range |
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.
statusCodes: keep access logs with status codes within the specified range
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.
that description has not changed as result of this PR, should we block the feature because of it? Honestly asking. Sounds like a separate issue (bettering the existing doc)
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.
Ah, sorry, it's early here. You are correct :)
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.
I see! :D I was honestly asking, there may be a policy in place in the project to better things as they are spotted, did not know. Thx for your comments!
# | ||
# Optional | ||
# Default: [] | ||
# | ||
statusCodes = ["200", "300-302"] | ||
|
||
# retryAttempts keep access logs when at least one retry happened | ||
# retryAttempts: keep access logs when at least one retry happened |
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.
Same coment as above :)
# | ||
# Optional | ||
# Default: false | ||
# | ||
retryAttempts = true | ||
|
||
# minDuration: keep access logs when request took longer than the specified duration |
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.
I find confusing to use present form (takes longer) and past form (has ocurred) in the descriptions across filters.
We should probably attempt to get some consistency. Ideas?
# | ||
# Optional | ||
# Default: false | ||
# | ||
retryAttempts = true | ||
|
||
# minDuration: keep access logs when request took longer than the specified duration |
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.
I find confusing to use present form (takes longer) and past form (has ocurred) in the descriptions across filters.
We should probably attempt to get some consistency. Ideas?
# | ||
# Optional | ||
# Default: [] | ||
# | ||
statusCodes = ["200", "300-302"] | ||
|
||
# retryAttempts keep access logs when at least one retry happened | ||
# retryAttempts: keep access logs when at least one retry happened |
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.
Same coment as above :)
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
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.
Nice first PR.
LGTM 👏
What does this PR do?
Added duration filter for logs
Motivation
Fixes #3455
More
Additional Notes
First PR so please be gentle 😄 I guess there may be some debate about naming