Access log

[krizhanovsky]

Scope

While #537 requires significant TDB changes, we should implement at least minimal access log. Configuration option:

log_access <on|off>;

With on we should print into dmesg lines as close to the following format as possible

10.0.2.101 [27/Dec/2021:00:39:13 +0300] "tempesta-tech.com" "GET /css/main.min.css HTTP/1.1" 200 8550 "http://tempesta-tech.com/blog/mariadb-char-order-by-performance" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0;  Trident/5.0)"`

The columns are:

1. remote user IP
2. local time
3. vhost name
4. request line
5. response status
6. bytes sent
7. referer value
8. user-agent

TBD probably the best place to log the message is HTTP request freeing and using it's TfwPool. If req->resp != NULL, then we have a response and can print fields from it. Need to check whether in all redirects (e.g. statically defined) we fill req->resp. Also need to check whether underlying request and response skb data is accessible at the time of a request freeing. In either case the logging must not contend on CPUs, at least on the Tempesta layer.

Documentation

Please create a new page under https://github.com/tempesta-tech/tempesta/wiki/Configuration for logging description. Please follow the documentation guidelines.

It seems we need to limit the length of the records fields, so need to document the limitations.

Testing

Please make a functional test for this. The test must check:

1. valid (200) response
2. redirects
3. blocked request with block_action attack drop; configuration, e.g. on JS challenge rate limiting

[krizhanovsky]

Closed in #1567