This page covers various problems associated with current Unix logging, both in the stock Unix syslogd daemon and in common log file rotation practices. A modern logging daemon like syslog-ng can solve the problems outlined below.
Stock syslogd Limitations
- Configuration file format and log file creation.
- Limited configuration.
- What host sent the log?
- No logging via Transmission Control Protocol (TCP).
Some variants of syslogd require tabs in the /etc/syslog.conf configuration file, though this is a minor problem that usually only trips up the rare system administrator. Newer syslogd daemons often support spaces or tabs between the specification and the destination.
mail.info /var/log/maillog
*.emerg *
Also, some syslogd implementations may not log anything should the logfile in question not exist at daemon startup time. This may result in lost logs, and be surprising to system administrators not familiar with such behavior. In contrast, syslog-ng can be configured to create any logfile needed on the fly.
Most syslogd have only limited configuration possible, though some vendors have added support for application-specific log routing and log entry format changes into their custom syslogd. For instance, running syslogd on FreeBSD with the -v -v options logs the important facility and priority data associated with log records. However, these improvements are vendor specific, and offer less than what syslog-ng can provide.
Stock syslogd also traditionally do not log the year with log entries, making long-term log parsing and archival problematic. What year was the following log entry made? (Hint: it came from the file /var/log/messages.9.)
Apr 15 15:06:50 server sshd[58101]: Connection closed by 192.0.2.151
Also, what time zone was the above log created under? Even if the time zone is mandated by site policy, what if the company merges or needs to share logs with a company using a different time zone?
If relaying through a proxy syslogd server, for example from a private cluster network through a cluster log server and then to a central loghost, the stock syslogd will change the hostname to be the name of the proxy server instead of the cluster node itself. If a failing disk is reported by log watching software running on the central loghost, the logs on the proxy must be consulted to determine whether the proxy or the node is the source of the problem.
Modern log daemons allow the original hostname to be preserved, or even to chain hostnames to determine the path a log entry took across the network.
Regardless of logging software, ensure the fully qualified hostname is used for logging server.example.org instead of the short server name, which is not unique, and could lead to log analysis problems if server.example.com beings logging to the same destination.
The traditional syslogd only logs over User Datagram Protocol (UDP). UDP has less overhead, though log messages will be dropped if the network is congested or the loghost busy. Modern logging daemons usually offer logging over both TCP and UDP, allowing a loghost to support both high volume logging from firewalls or routers where lost log entries are not a primary concern and more reliable logging for systems such as mail servers.
Log File Rotation Problems
Traditional log file rotation may cause various problems, including the “send HUP signal and hope” versus “just copy and truncate” approaches used by external rotation utilities, the difficulty of backing up frequently renamed files, the difficulty in referencing logs from a certain number of days ago in rotated logs, and additional problem should a host be offline for several days.
See the syslog-ng notes on setting up an improved logging infrastructure.
