Enhance accesslogs with InstanceId for better debugging #293
Conversation
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
|
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
6 tasks
|
Thank you @thomas-kaltenbach ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A short explanation of the proposed change:
Log out the instanceId at accesslogs for debugging and correlation of different log entries. Similar to Enhance registry logs with appId, instanceId and domainSans #291
An explanation of the use cases your change solves
We face currently some issues (x509: certificate is valid for <instance_guid>, not <instance_guid>) during landscape update. We would like to correlate exactly the access logs with some other logs i.e. gorouter error logs or runtime logs (BBS,REP,CC). This change enable us to see exactly what happens at instance. So, we can find all accesslogs, the starting/stopping/crashing containers and also the endpoint-(un)registration logs of the gorouter (with PR Enhance registry logs with appId, instanceId and domainSans #291) .
This would help us a lot.
Instructions to functionally test the behavior change using operator interfaces (BOSH manifest, logs, curl, and metrics)
Deploy the change and have a look at the logs.
Expected result after the change
GET / HTTP/1.1" 302 0 0 "-" "-" "-" "10.1.1.65:8443" x_forwarded_for:"-" x_forwarded_proto:"https" vcap_request_id:"<vcap_id>" response_time:0.015406 gorouter_time:0.000088 app_id:"<app_id>" app_index:"1" instance_id:"<instance_id>" x_cf_routererror:"-" ...
Current result before the change
GET / HTTP/1.1" 302 0 0 "-" "-" "-" "10.1.1.65:8443" x_forwarded_for:"-" x_forwarded_proto:"https" vcap_request_id:"<vcap_id>" response_time:0.015406 gorouter_time:0.000088 app_id:"<app_id>" app_index:"1" x_cf_routererror:"-" ...
Links to any other associated PRs
Enhance registry logs with appId, instanceId and domainSans #291
I have viewed signed and have submitted the Contributor License Agreement
I have made this pull request to the
mainbranchI have run all the unit tests using
scripts/run-unit-tests-in-dockerfrom routing-release.I have build an routing release and deployed it on our devlandscape
(Optional) I have run Routing Acceptance Tests and Routing Smoke Tests on bosh lite
(Optional) I have run CF Acceptance Tests on bosh lite