Server logging
The Barefoot server has support for logging many different types of information, including traffic data, server status and debug information.
Server logging
The logging done by the server is controlled via keywords in the server configuration file.
Logfiles
Two logfile keywords are supported by Barefoot: logoutput and errorlog. The former controls how all syslog-type messages should be logged, regardless of severity, while the latter will only be used for logging warnings, errors, etc. If both are specified, warnings will be written to both files, while debug and information level messages are only written to the logoutput logfile.
Both keywords take the name of the file to which messages should be written, or one of the keywords syslog[/facility], stdout or stderr.
The following example shows how to enable general log output to a file and logging of warnings or errors to syslog:
errorlog: syslog logoutput: /var/log/sockd.log
Debug logging
The debug keyword can be used to enable debug logging, and will cause a large amount of debug information to be written, as specified by the logoutput keyword:
debug: 1
The supported argument values are as follows:
- debug: 0 - No debug logging.
- debug: 1 - Some debug logging.
- debug: 2 - Verbose debug logging.
Debug logging can also be enabled via the -d command line option when starting the Barefoot server. The command line option will override any value set in the configuration file.
Per-rule logging
Traffic related logging can be enabled on a per-rule basis, allowing different amounts of information to be logged for different types of traffic. The log keyword is used for this purpose and can be specified in any client rule.
The following arguments can be given to the log keyword to enable logging of various types of information:
- connect - Information about accepted client connections.
- disconnect - Information about disconnecting clients.
- ioop - Logging of each data transfer operation.
- data - Logging of the actual data transferred.
- tcpinfo - Logging of information obtained via the TCP_INFO socket option, on platforms where this information is available.
The default is for no logging to be done, unless debugging has been enabled, in which case several of the above types of data might be logged.
SIGINFO/SIGUSR1 based logging
Upon reception of a SIGINFO/SIGUSR1 signal, the Barefoot server will write various types of status information to the files specified by the logoutput keyword. This includes an overview of the server status, such as the number of handled clients, the number of running processes, etc., as well as a list of all currently active sessions.
Logging of traffic related failure warnings
Some types of network related problems can be reported by the system to the Barefoot server during forwarding of data traffic. This includes routing errors, connection refused errors and DNS failures.
When the Barefoot server is used to pass traffic from internal hosts to any external host on the Internet, these types of errors will typically be uninteresting, as connectivity to external hosts may come and go according to routing changes far away.
When Barefoot is instead used as a reverse proxy, forwarding traffic only to a small number of internal servers, or used as a gateway for internal hosts to a small number of high-quality target servers (e.g., servers for stock exchange information), the previously mentioned types of failures should generally never occur. If they do occur, it will likely indicate that there is a problem with the network between the Barefoot server and the target servers, or with the target servers themselves. By having support for logging of warnings in these situations, Barefoot can potentially warn the operator when the errors occur, assuming there is relevant client traffic passing through Barefoot.
Logging of routing failure related warnings (such as EHOSTUNREACH) can be enabled with the no-route keyword:
external.log.warning.error: no-route #enable warnings on external interface internal.log.warning.error: no-route #enable warnings on internal interface
By default, the no-route warnings are not enabled, but the above lines can be set in the server configuration file to enable logging of the warnings for either of the internal or external sides of the Barefoot server (i.e., on the client side, server side, or both).
These warnings will be logged in the following format:
warning: could not DNS-resolve "NOSUCHDNSNAME": Name or service not known
These warnings can be enabled as follows:
#enable warnings for traffic on the external interface external.log.warning.error: dns-any
The no-route and dns-any are Barefoot-specific values that match multiple system errors.
It is also possible to specify the system error values directly, using the symbolic errno name for system calls, and the symbolic EAI_xxx error value for DNS-related errors.
For example, if client connections are forwarded to a target host that is currently reachable via the network, but where the target server application has crashed, the target host/kernel the target server is running on will normally return a TCP RST when Barefoot attempts to connect to the target server. Logging of this type of error can be enabled with the ECONNREFUSED keyword, corresponding to the errno value with the same name, giving the following type of log output:
warning: connect to host 10.0.0.1.80 failed: Connection refused
The following example shows how logging can be enabled when ECONNREFUSED is returned by the kernel or EAI_AGAIN is returned during DNS lookup:
#enable warnings for traffic on the external interface external.log.warning.error: ECONNREFUSED EAI_AGAIN
For configurations where these types of warnings are useful, the traffic monitoring functionality in Barefoot might also provide tools that can usefully be used for detecting potential network problems.