The logs are really usefull during the installation of a web application when things should work but they don't. Then it is important to collect the maximum information in order to identify the source of the problem.
In the following example, an instance of Dotclear is served with NGINX and PHP-FPM on a NetBSD system. In the server section of the NGINX configuration, both access_log and error_log are configured to serve logs to Syslog through a Unix Domain Socket (UDS). The path of the UDS file is /var/run/log. By default, NGINX generates syslog messages using local7 facility. A tag is added to the message to identify the emitting program. Here the hostname is not added to the message because it is just useless. The hostname of the emitting host can be usefull in the case of logs emitted from several hosts in a network. In this case, it only consists in local log messages.
In addition to access and error logs, logs on url rewriting can also be produced by enabling rewrite_log. These logs are generated at notice level. Then it is necessary to configure the error_log parameter to emit messages until this level.
server {
access_log syslog:server=unix:/var/run/log,tag=dotclear,nohostname;
error_log syslog:server=unix:/var/run/log,tag=dotclear,nohostname notice;
rewrite_log on;
}
Another program that is likely to produce logs about dotclear is PHP-FPM. PHP-FPM is requested by NGINX and serves it PHP interpreted files. The access requests transmitted to PHP-FPM can also be logged to a file as in the configuration file fragment below.
[dotclear]
access.log = /var/log/dotclear/php-fpm.log
user = dotclear
group = dotclear
The configuration file /etc/syslog.conf must be tuned to redirect the message stream concerning Dotclear to dedicated files. The lines below the one starting by !dotclear apply on the dotclear program namely the messages emitted by NGINX with the tag "dotclear". For the local7 facility, three lines redirect messages for each level in err, info and notice to a dedicated file in the direction /var/log/dotclear. After !*, messages of all programs can be handled.
!dotclear
local7.err /var/log/dotclear/error.log
local7.info /var/log/dotclear/access.log
local7.notice /var/log/dotclear/rewrite.log
!*
It is unnecessary to store tons of log files. To avoid a directory /var/log growing indefinitely, newsyslog can be configured to periodically rotate the log files. The configuration file fragment below defines how the archived files must be build: which user and group? dotclear:dotclear. Which permission? 644, read/write for the user, read for the others. Which maximum size? 250 kilobytes. Which format? X for xz.
/var/log/dotclear/access.log dotclear:dotclear 644 5 250 * X
/var/log/dotclear/error.log dotclear:dotclear 644 5 250 * X
/var/log/dotclear/php-fpm.log dotclear:dotclear 644 5 250 * X
/var/log/dotclear/rewrite.log dotclear:dotclear 644 5 250 * X
With this approach, most of the logs which can be produced for Dotclear are reached and redirected to dedicated files in order to help in the very first instants of the application deployment when it should work but something is wrong.