How to Implement Syslog Logging Using JournalD in PostgreSQL

Logging to syslog is a well-established feature in PostgreSQL that has been available for many years. Despite its long-standing presence, only a handful of users use this capability. This realization has motivated me to develop a comprehensive introductory tutorial, which I am confident will prove valuable to a broad audience. The primary goal of this tutorial is to highlight this often-overlooked feature and provide detailed guidance on how to utilize it effectively.

Since most contemporary Linux distributions now default to journald for logging purposes, my tutorial will focus on integrating PostgreSQL's logging with journald. This approach will help streamline the logging process and enhance the overall management and analysis of log data. By the end of this tutorial, users should clearly understand how to configure and optimize syslog logging in PostgreSQL to better align with modern logging practices.

SYSLOG TERMINOLOGY

Syslog serves as the default logging standard on Unix-based systems. It operates through a syslog daemon, which is essentially a background process that receives log messages from various applications and services running on the system. Once received, the daemon processes these messages based on a predefined set of rules configured by the system administrator.

Each message processed by the syslog daemon is categorized by two key attributes: a facility and a severity. The facility code helps identify the type of program that generated the message. Common predefined facilities include kernel for messages originating from the operating system kernel, mail for mail server components, and security for security-related messages. Unfortunately, no predefined facility specifically exists for PostgreSQL or any other database systems. Instead, PostgreSQL must utilize one of the generic local0 through local7 facilities. These are designated for messages that don't fit into the more specific categories and are perfect for custom applications like database logging.

The severity level of a syslog message indicates the importance or urgency of the event being reported. This could range from debug-level messages, which are mostly informational and useful during troubleshooting, to critical messages that indicate serious issues that need immediate attention.

When configuring PostgreSQL to log to syslog, it's crucial to select an appropriate facility and to define the severity levels clearly. This ensures that the logs are not only correctly categorized but also filtered and processed in a manner that aligns with the system's overall logging strategy. By leveraging the local0 to local7 facilities, PostgreSQL can effectively integrate into the broader system logging framework, allowing for more efficient log management and analysis.

SYSLOG AND JOURNALD

These days, most Linux distributions rely on systemd for a variety of crucial system management tasks. This includes:

• Serving as the init process, which is designated as process 1 and is responsible for starting all other processes on the system.

• Automatically starting and managing system services, such as PostgreSQL, ensuring that these services are launched at boot and managed efficiently throughout the system's operation.

• Handling system-wide logging through a dedicated daemon known as journald.

The systemd's journald daemon is particularly significant because it implements the syslog API, allowing it to integrate seamlessly with various logging systems, including PostgreSQL. In this article, I will focus on how to configure PostgreSQL to log its activities using journald. Although the configuration steps are generally applicable to any syslog implementation, journald offers specific advantages for local logging on a single machine.

If your goal is to aggregate logs from multiple systems into a central repository, systemd provides robust tools for this purpose as well. This centralized logging is crucial for managing logs efficiently in environments where multiple servers need to be monitored and managed simultaneously.

CONFIGURING POSTGRESQL FOR SYSLOG LOGGING

Setting up the PostgreSQL side is simple: all you have to do is to edit postgresql.conf

log_destination = 'syslog'
# must be "on" only if PostgreSQL writes a log file
logging_collector = off
# "local0" is the default value
syslog_facility = 'local0'
# "postgres" is the default value
syslog_ident = postgres
# no point in logging the time or process ID
# (systemd logs these anyway)
# but logging user and database might be good
log_line_prefix = '%q%u@%d '

After making these changes, you should reload PostgreSQL to apply the new settings. If you have modified the logging_collector setting, a restart of the PostgreSQL service is necessary.

For environments where multiple PostgreSQL clusters are running on the same machine, consider assigning unique syslog_ident or syslog_facility values to each cluster. This configuration helps in segregating the logs for each cluster, making it easier to troubleshoot and maintain system integrity. This step is particularly beneficial for system administrators who manage multiple databases and need to ensure precise log management.

JOURNALD AND PERMISSIONS

The PostgreSQL log contains sensitive information, including SQL statements, their parameters, and potentially passwords. Therefore, it is crucial to restrict access to the PostgreSQL log to prevent unauthorized viewing. This can be effectively managed with journald: journalctl restricts log visibility to members of specific operating system groups. On my Fedora 39 Linux system, these groups include adm, systemd-journal, and wheel, although this configuration may vary across different distributions.

Additionally, it is essential to ensure that the directories where journald stores data are secure. On my system, these directories are located in /var/log/journal, and access is limited to users in the systemd-journal group.

PERFORMANCE AND SPACE MANAGEMENT WITH JOURNALD

It is widely recognized that logging can be a performance problem. This issue extends to syslog logging, where PostgreSQL sends all messages to the syslog daemon. However, journald mitigates this by limiting the number of messages it retains and will discard some if the volume becomes excessive. This approach helps reduce the impact of excessive logging.

Additionally, journald controls the expansion of log files effectively. Configuration options in /etc/systemd/journald.conf allow administrators to set limits on log file size, thus preventing logs from consuming excessive disk space.

This tutorial provides an introduction to configuring PostgreSQL for syslog logging, with a focus on integration with systemd's journald for efficient log management. It covers the basics of syslog, including how to set up PostgreSQL logging parameters, and explains the advantages of using journald, such as improved performance and space management. The guide also includes tips for viewing and securing logs, making it a comprehensive resource for enhancing PostgreSQL logging practices.

References:

SYSLOG LOGGING WITH JOURNALD IN POSTGRESQL

PostgreSQL Documentation