trafficcontrol
trafficcontrol copied to clipboard
apache
Increase TP Logging
Currently TP only logs requests to static files and 404s in access.log, there is no logging for other errors, such as 401s, that can be useful for determining the cause of issues.
This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:
- Traffic Portal
Current behavior:
Minimal logging
New behavior:
Increase the amount of logging TP does
Why? Your browser already logs all of your own interactions with the TP server, and TO already logs all its API requests/responses.
Consider the scenario where you, an operator, want to know the IP addresses of users who are requesting a certain endpoint through Traffic Portal. Looking at the Traffic Ops logs, you would see the user agent of that user's browser but the IP address of Traffic Portal. Traffic Ops does not even know the IP address of the user AFAIK (or what IP address they last authenticated with or used to register), so that is either something that TP would need to log by itself or pass on to TO.
Also, if someone is DOSing TO through TP, you'd need to know their IP address if you wanted to block it
That's true. I think it would be more useful to have the IP passed along to Traffic Ops, to make it easier to correlate an IP with actual requests.
I think it would be more useful to have the IP passed along to Traffic Ops, to make it easier to correlate an IP with actual requests.
Only if we find a way to log it in addition to TP's IP address. We don't want logs to lose track of the fact that the request is coming through TP, because listing only the client IP address in the logs could make SSL or connection issues between TP and TO difficult to track down. But if we did somehow log both the user's IP address and TP's, it would likely change and complicate the TO log format.
Adding a TP log for requests does not seem redundant, since that request~IP address association is not logged elsewhere. And since the vast majority of requests are still automated and go straight to TO, the TP log would probably not be so big.
Logging API requests at the TP server doesn't solve the issue of not knowing the actual IP address of the client that makes a particular request to Traffic Ops. You would need to go look at a separate log for a different server and try to find similar events occurring at roughly the same time and then hazard a guess that they're related. If we just instead tell TO what the IP address of the actual requesting client is in e.g. an HTTP header like TC-TP-Client-IP then TO can accurately associate requests for its log messages. Which, of course, would in no way involve obscuring TP's IP address.
But we don't want the TP user's IP address in the TO logs. If a lot of requests are coming in from TP to TO (for example, if someone is mistakenly trying to use TP as if it was TO), that is something we would want to notice by a large number of requests coming in from TP IP addresses.
I don't understand what about what I said precludes you from doing exactly that
If we just instead tell TO what the IP address of the actual requesting client is in e.g. an HTTP header like
TC-TP-Client-IPthen TO can accurately associate requests for its log messages. Which, of course, would in no way involve obscuring TP's IP address.
Example of a log mesage that includes both IP addresses?
idk something like
INFO: routing.go:263: 2022-08-24T18:08:32.122673472Z: 192.0.2.0 (192.0.2.1): GET /api/4.0/cdns/CDN-in-a-Box/snapshot? handling (reqid 9779)
where TP's address is 192.0.2.0 and the client's actual IP is 192.0.2.1
Yeah that could work. We'll need to make sure the changelog and release notes mentions this change to log format and maybe drop a note on the mailing list, as this could break existing log scraping
Was this closed by @shamrickus in https://github.com/apache/trafficcontrol/pull/7386
