Skip to content
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

Conversation

rodrigodiez
Copy link
Contributor

@rodrigodiez rodrigodiez commented Jun 9, 2018

What does this PR do?

Added duration filter for logs

Motivation

Fixes #3455

More

  • Added/updated tests
  • Added/updated documentation

Additional Notes

First PR so please be gentle 😄 I guess there may be some debate about naming

@rodrigodiez

This comment has been minimized.

@rodrigodiez

This comment has been minimized.

Copy link
Contributor

@m3co-code m3co-code left a 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?

@@ -159,6 +161,13 @@ format = "json"
# Default: false
#
retryAttempts = true

# duration keep access logs when request took more than the specified duration
Copy link
Contributor

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...

Copy link
Contributor

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 :-)

@@ -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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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"`
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@rodrigodiez rodrigodiez left a 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 👍

@@ -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) {
Copy link
Contributor Author

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

Copy link
Contributor

@m3co-code m3co-code left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice job 👏

@rodrigodiez
Copy link
Contributor Author

thanks! And please keep adding begginer tasks, they are so valuable!

Copy link
Contributor

@dtomcej dtomcej left a 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
Copy link
Contributor

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

Copy link
Contributor Author

@rodrigodiez rodrigodiez Jun 11, 2018

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)

Copy link
Contributor

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 :)

Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same coment as above :)

Copy link
Contributor

@dtomcej dtomcej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
:shipit:

@mmatur mmatur added this to the 1.7 milestone Jun 11, 2018
@ldez ldez requested a review from mmatur June 11, 2018 14:49
Copy link
Member

@mmatur mmatur left a 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 👏

@mmatur mmatur added kind/enhancement a new or improved feature. status/3-needs-merge labels Jun 11, 2018
@traefiker traefiker merged commit 1fbf5b8 into traefik:master Jun 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants