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

Failover requests should take create a new request logger #99

Open
rahulreddy opened this issue Jan 18, 2017 · 3 comments
Open

Failover requests should take create a new request logger #99

rahulreddy opened this issue Jan 18, 2017 · 3 comments
Assignees

Comments

@rahulreddy
Copy link
Collaborator

No description provided.

@rahulreddy rahulreddy self-assigned this Jan 18, 2017
@ghost
Copy link

ghost commented Jan 18, 2017

I'm not exactly convinced by this: We're still processing the same request (and the request uids are here to help tracking how one requests fares)
Generating a new ID may complexify things here, including for investigations.

Now, if you're talking about a sub-request id, that may be a possibility, but still generated quite a bit of complexity in understanding the logs.

@rahulreddy
Copy link
Collaborator Author

Yes, I meant the sub-request id since the request logger would be created using the req_id from S3.

I was helping @msegura debug an issue why certain requests were failing at sproxyd level and it was hard to track the individual failover requests at the nginx level as all the requests had the same "sub" request_id.
So instead of creating logger only once, for example right now at the beginning of a PUT operation, it could be moved over to_failover so that we get a different request_id combo for each failover request.
The following example is more easy to debug at nginx level

Failover#1 a7ea4c3151407e76b10e:7a6691a0746cb6785797
Failover#2 a7ea4c3151407e76b10e:99bc9f79c649553d84c3
Failover#3 a7ea4c3151407e76b10e:4472d440c6546a7cdfd8
Failover#4 a7ea4c3151407e76b10e:d4e4f926ace52cf1651f
Failover#5 a7ea4c3151407e76b10e:1e62081125aaad441594

@ghost
Copy link

ghost commented Jan 18, 2017

I see, so it's more to be able to easily track at the next layer. I understand and support the request :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant