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

Add access log filter for retry attempts #3042

Merged
merged 4 commits into from Mar 23, 2018

Conversation

mjeri
Copy link
Contributor

@mjeri mjeri commented Mar 18, 2018

This PR implements #3020.

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.

Hi @marco-jantke,

Thanks for your PR 👏

Few comments in the review.

@@ -357,6 +357,17 @@ func TestNewLogHandlerOutputStdout(t *testing.T) {
},
expectedLog: `TestHost - TestUser [13/Apr/2016:07:14:19 -0700] "POST testpath HTTP/0.0" 123 12 "testReferer" "testUserAgent" 23 "testFrontend" "http://127.0.0.1/testBackend" 1ms`,
},
{
Copy link
Member

Choose a reason for hiding this comment

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

If I add this test case

{
	desc: "Default config",
	config: &types.AccessLog{
		FilePath: "",
		Format:   CommonFormat,
		Filters:  &types.AccessLogFilters{},
	},
	expectedLog: `TestHost - TestUser [13/Apr/2016:07:14:19 -0700] "POST testpath HTTP/0.0" 123 12 "testReferer" "testUserAgent" 23 "testFrontend" "http://127.0.0.1/testBackend" 1ms`,
},

The default response has changed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That is right. Now when you specify Filters but nothing inside it will remove everything. Isn't that the kind of logical behavior? The filters are OR-connected and when you specify multiple (status codes and retry attempts) than the result is more than when you specify only one of those. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for your response @marco-jantke
When we specify nothing in Filters, we need to keep all access logs. And when something is specified in Filters we need to keep only access logs matching at least one filter

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As said before I think that's not logical. And "optimizing" for a use-case where someone would specify an empty filters config doesn't make too much sense. However, I implemented it now as you requested in 6ca142b. PTAL and let me know what you think. I didn't see a nicer option for detecting an empty configuration except validating each config value one by one to check whether it's the zero value. Note that with this approach we have to extend this method each time a new option gets added. I'm open to improvement ideas.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for your correction @marco-jantke

I am pretty agree with you but I think that it is not the aim of this PR to change the default behavior. To me you have choose the best option to detect an empty configuration.

We should maybe do an other PR to improve this method to avoid to extend it every time we add a new option

test := test
testName := fmt.Sprintf("%q contains %d", test.strBlocks, test.statusCode)
t.Run(testName, func(t *testing.T) {
httpCodeRanges, err := NewHTTPCodeRanges(test.strBlocks)
Copy link
Member

Choose a reason for hiding this comment

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

Could you please run these test cases in parallel

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, fixed.

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.

LGTM 👏

Thanks for your time @marco-jantke. I will be happy to work with you on a new PR to improve the keepAccessLog function

Copy link
Contributor

@nmengin nmengin left a comment

Choose a reason for hiding this comment

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

@marco-jantke Many thanks for this PR 👏

I just have one suggestion.

#
# Optional
# Default: []
#
statusCodes = ["200", "300-302"]

# retryAttempts keep access logs when at least one retry happened
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a specify that this option will keep keep access logs when at least one retry happened even if the status code is not in the statusCodes ranges.
Thus users can understand that filters are OR-connected 😉

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@nmengin I added now a sentence at the beginning of the segment, so that we don't have to repeat that sentence on every filter we have :D

Can you have a look and let me know whether it would have helped you?

Copy link
Member

@juliens juliens left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@nmengin nmengin left a comment

Choose a reason for hiding this comment

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

LGTM 🗞️ 👏

@traefiker traefiker merged commit c762b9b into traefik:master Mar 23, 2018
@ldez ldez changed the title add access log filter for retry attempts Add access log filter for retry attempts Mar 24, 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.

None yet

6 participants