Forum Discussion
Hello Daniel!
Firs of all, thank you so much for your information!
Let me explain a little bit more.
Today, we have 2 remote servers with booth of them are receiving the logs of our F5 Appliances. We are working to future desable the local logs of our appliances for only make troubleshooting with our 2 remote servers that are receiving this logs internal only. The problem is, we're sending to every alert/block the "query_string" field, but in some cases, the field "query_string" don't show anything, the field are there, but without any information, we detected that some type of signatures like XSS and SQL do not send this values of the exacly query string that match with the attack signature, but if we see it in our local log in F5 we can see the string that matches with the Attack Signature.
Best Regards,
Victor.
If you try to log literally everything remotely, you will probably always run into length issues.
Remote logging in my opinion is meant to be selective.
Something that could work (but I've never done it myself) is to set multiple remote logging profiles to overcome the length limitations. For example one for your "standard" log with whatever log fields you typically need as your standard "access log". Then a second profile with only support ID (so you can identify the log entry) and request (to have as much of the full HTTP request as possible). And a third profile with only support ID and violation_details (again ID to match and then as much as possible of the violation_details field). And you can send those to the same or different log destinations.
All in all, I'm not convinced it's a good idea to try to completely move away from the local log of the bigip. I don't think you will get the same quality and user-friendliness with remote logging.