SYSLOG_FACILITY ignored in backend.c logger

[janeczku]

While setting up syslog rules on a new server, i noticed that some sniproxy syslog messages ended up in the user.log instead of where they were supposed to go. I almost went mad over this, thinking something with my syslog config was amiss.

Issue: Syslog messages emitted in backend.c are always send to Syslog's default log.user facility and not the SYSLOG_FACILITY defined in sniproxy.h.

Cause: openlog() is initialized AFTER the init_server(config) call in sniproxy.c

As a side note, some log granularity control would be nice to have in the sniproxy.conf.

[dlundquist]

Sorry about that. Logging is item 7 on the TODO list, although it can be bumped up a bit.

The reason for the openlog being initialized late had to do with when I was closing all socket in daemonize(), this was finally removed in 37606b9. While profiling the libev branch I found access logging was a significant bottle neck. Different users will have different logging requirements, so this is definitively needs to be a configuration item.

I've given the access logging some thought. For my intended application (reverse proxy for a number of IPv6 only web servers) I need to be able to collect bandwidth and performance data for each back end, so when a connection a connection will be logged as a single line when it is closed. The line will include: timestamp when connection opened, source IP and port, requested hostname, back end server and port, how connection was terminated, duration and bytes transferred each direction.

As for the configuration of logging I'm still trying to figure that out. I can see plenty of cases where someone might want a single access log for multiple listeners, and others where they might want to separate the access log per listener. I don't think there is too much value is separating out the error logs; failed connections will still be logged in access log.

We could do something like this:

user nobody

pidfile /tmp/sniproxy.pid

error_log syslog local3 notice

# Maybe also support error logging to a file?
#error_log file /var/log/sniproxy/error.log

# Maybe even support a global access_log for listeners which do not specify their own
#access_log file /var/log/sniproxy/access.log

listen 80 {
        proto http
        table vhosts
        access_log file /var/log/sniproxy/access.log
}

listen 443 {
        proto tls
        table vhosts
        access_log file /var/log/sniproxy/access.log
}

table vhosts {
#    <backend servers>
}

But is seem repetitive to duplicate the access file path. We could make each log destination its own named block like tables with a number of parameters like listeners, but this seems like overkill for most applications.

@janeczku What are your thoughts?

[janeczku]

If you want to go with the separate access logs, a named block would IMO be best practice as well as being consistent with configuration logic already implemented. I don't like to enter the same information twice or even more often. I prefer to be able to invoke shared configurations. Also, there maybe in the far future more options for the logging (like custom log format) which would justify a named block for access log even more.

That said, i don't necessarily think that separate logs are a critical feature (but not bad either!). Unlike virtual hosting on Nginx/Apache, there are only so many listeners one would have on a single hardware node. Of course there might be a need to separate accounting even when running only two listeners - but why not do it when parsing the log files? If one would want to do accounting of the connections, one would have to parse the logs with some application in the first place. So as long as you include listener name, table/backend name, etc. there is plenty of options for accounting aggregation/separation.

Last, did you think about how to go with access log formatting ? I think its important to be universal / easily parseable. Maybe you could use (or at least mimic) the common log format used by Apache/Nginx? This might allow for people to analyze the logs with stock log analyzers / accounting software.

Cheers!

[dlundquist]

Closing issue. access logging remains on the TODO list.