SeaCat Server provides detailed logging with more than 350 log event types. Log events are well-structured to allow simple parsing and further processing of the log event stream. Log events can be stored in a file or forwarded to other system via syslog protocol. The logging subsystem is designed to be highly performing and reliable.

The logging is the single most important source of information for operational and security monitoring of the application. For this reason, we strongly suggest to implement proper logging procedures and integrations for any production system that utilizes SeaCat Server.

SeaCat Server provides a palette of different logging options that matches with broad spectrum of production and non-production deployment scenarios.

Logging to a standard error output (stderr)

A logging on a standard error output respective on a console is useful mainly for a debugging and fine-tuning of the configuration. It should be avoided in production systems.

SeaCat Server prints log events on a standard error output (aka stderr) when no -l command-line argument is specified.

Example of the log event format on stderr:

2017-04-28T13:19:26.680Z seacat-gw[14110] AUDIT: [t=5TYESSXK6PAI55Z2 a=REQ hm=POST hp=/app] Request to a backend

Logging to a file

A logging in a file provides a well-tested and established way of how to manage log files. It allows bulk yet non-realtime processing of the log events and it is suitable for smaller scale production deployments. We don’t recommend it for a highly security sensitive operations.

The parameter -l of the seacatd enables logging to a file if it specifies a location of the log file on the filesystem. The format of the log event is the same as in the stderr example above.

The example of the seacatd init script that enables SeaCat Server file logging:

/opt/seacat/bin/seacatd -l /opt/seacat/var/log/seacatd.log -p /opt/seacat/var/seacatd.pid ...

Log file rotation

The log rotation is an important mechanism that maintain log files to manageable sizes. The SeaCat Server is designed for a heavy traffic and as a such, it produces large amount of the log event data. We recommend to implement log rotation of any production system that runs SeaCat to prevent incidents originating at incomplete log file management, such as running out of disk space due to enormous log file sizes.

The log rotation is supported by a signal HUP. If seacatd process received a HUP signal, the specified log file is rotated. The log rotation is designed to work with logrotate and similar tools.

The example of a SeaCat logrotate configuration:

	rotate 365
		DATE=`date '+%Y%m%d'`
		/bin/kill -HUP `cat /var/run/seacatd.pid 2>/dev/null`
		/bin/gzip ${LOGF}-${DATE}

Logging to a syslog

The syslog mechanism provides a mechanism for processing of the log events in a real-time. It is suitable for production deployments of all sizes and also for systems with elevated security needs such as a 24/7 security monitoring via SIEM. More on this topic can be found in chapter about integration with Security Operation Centre.

The logging to a syslog is enabled when the parameter -l of the seacatd is set to syslog. The configuration file can provide detailed settings, such as a syslog format variant (RFC5424, RFC3164 or macOS-compatible), a syslog facility or address of the syslog network socket.

SeaCat Server supports only datagram-oriented syslog protocols such as UDP or datagram Unix sockets. Stream-oriented protocols are not yet supported. Local unix socket configuration is recommended for its high throughput.

The example of the seacatd init script that enables SeaCat Server syslog logging:

/opt/seacat/bin/seacatd -l syslog -c /opt/seacat/etc/seacat.conf ...

The example of seacat.conf that configures RFC5424 logging via local unix socket:


Configuration of syslog-ng

The recommended syslog implementation for SeaCat Server is syslog-ng.

Example of the receiving socket configuration:

source s_seacat_socket {
	unix-dgram("/opt/seacat/var/syslog.sock" flags(syslog-protocol));