Forum Discussion
Gregory_Gerard_
Nimbostratus
Nimbostratusaccess_log equivalent for a virtual server
Hi,
We have a VS that chooses a pool from the URI which contains the customer (each customer has their own backend servers but access through a common URL scheme so there's only one SSL certificate involved and it works well for us).
https://www.example.com/cust1/foo/bar/baz
https://www.example.com/cust2/foo/bar/baz
However, since all these are going towards many machines on the backend, I'd like to consolidate my logs at the VS level rather than trying to harvest from N backends (especially if the backend was sick, the request had to be routed to another machine mid-flight because of backend problems, etc.).
Anyone have a performant recipe for this? I'm currently using a log statement at the top of my iRule and putting the data into local3.info. Can this be done better?
I haven't found a logging feature for virtual servers but would love to see a future release have such a thing since F5 can make this part of request processing and faster than Tcl script.
thanks,
greg
2 Replies
- No, currently the log statement is probably your best bet.
We will consider your request for adding a logging capability on the virtual, but since that does have the ability to produce copious amounts of output, we would be very leary of doing that.
We are also contemplating adding the ability to log directly from a rule to another host, bypassing the local host's syslog. This would improve efficiency somewhat as it wouldn't involve extra configuration or an extra hop through the host OS. 
Gregory_Gerard_Thanks for the response. Both work for me. Since I'm already using a syslog that dumps to disk, both are the same to me, too.
The advantage to direct disk support would be the common log formats out there and the harvesting tools built up around those formats.
I'd imagine that if you made this part of the core traffic engine, the logging operations would not be synchronous so mostly the issue would be how much memory you could spare to buffer the logging statements until they could be sent to disk or to a networked syslog.
If you made the option at the VS level, I'd ask for the ability to hold off new connections until the log is flushed or slow the connections down so the client can't send new requests as quickly. Things would be fine in a bursty scenario because the buffer might fill but would quickly fall. Sustained throughput would be problem, though. In my use cases, I require absolute logging, even at the expense of not accepting new connections as quickly. Other sites might like to get content traffic through at the expense of logging.
