It is a good idea to save the database server's log output somewhere, rather than just discarding it via <filename>/dev/null</filename>. The log output is invaluable when diagnosing problems. データベースサーバのログ出力を/dev/nullに渡して単に破棄するのではなく、どこかに保存しておくことを推奨します。 問題の原因を究明する時にログ出力は貴重です。

Log output tends to be voluminous (especially at higher debug levels) so you won't want to save it indefinitely. You need to <emphasis>rotate</emphasis> the log files so that new log files are started and old ones removed after a reasonable period of time. ログ出力は（特により高いデバッグレベルの時に）巨大になる傾向があるので、際限なく保存したくはないでしょう。 適切な期間を経過した後に、新しいログファイルが開始され、古いログファイルが削除されるように、ログファイルをローテーションする必要があります。

If you simply direct the <systemitem>stderr</systemitem> of <command>postgres</command> into a file, you will have log output, but the only way to truncate the log file is to stop and restart the server. This might be acceptable if you are using <productname>PostgreSQL</productname> in a development environment, but few production servers would find this behavior acceptable. 単にpostgresのstderrをファイルに渡している場合、ログ出力を保持できますが、そのログファイルを切り詰めるためにはサーバを停止させ、再度起動させるしか方法がありません。 開発環境でPostgreSQLを使用しているのであればこれで構いませんが、実運用サーバでこの振舞いが適切となることはほぼありません。

A better approach is to send the server's <systemitem>stderr</systemitem> output to some type of log rotation program. There is a built-in log rotation facility, which you can use by setting the configuration parameter <varname>logging_collector</varname> to <literal>true</literal> in <filename>postgresql.conf</filename>. The control parameters for this program are described in <xref linkend="runtime-config-logging-where"/>. You can also use this approach to capture the log data in machine readable <acronym>CSV</acronym> (comma-separated values) format. サーバのstderrを何らかのログローテーションプログラムに送信する方が良いでしょう。 組み込みのログローテーション機能があり、postgresql.confのlogging_collector設定パラメータをtrueに設定することでこれを使用することができます。 このプログラムを制御するパラメータについては19.8.1で説明します。 また、この方法を使用して、機械読み取りしやすいCSV(カンマ区分値)書式でログデータを取り込むことができます。

Alternatively, you might prefer to use an external log rotation program if you have one that you are already using with other server software. For example, the <application>rotatelogs</application> tool included in the <productname>Apache</productname> distribution can be used with <productname>PostgreSQL</productname>. One way to do this is to pipe the server's <systemitem>stderr</systemitem> output to the desired program. If you start the server with <command>pg_ctl</command>, then <systemitem>stderr</systemitem> is already redirected to <systemitem>stdout</systemitem>, so you just need a pipe command, for example: また、既に他のサーバソフトウェアで使用している外部のログローテーションプログラムがあるのであれば、それを使用したいと考えるでしょう。 例えば、Apache配布物に含まれるrotatelogsをPostgreSQLで使用することができます。 これを行う一つの方法は、単にサーバのstderrを目的のプログラムにパイプで渡すことです。 pg_ctlを使用してサーバを起動している場合はstderrは既にstdoutにリダイレクトされていますので、以下の例のようにコマンドをパイプする必要があるだけです。

pg_ctl start | rotatelogs /var/log/pgsql_log 86400

You can combine these approaches by setting up <application>logrotate</application> to collect log files produced by <productname>PostgreSQL</productname> built-in logging collector. In this case, the logging collector defines the names and location of the log files, while <application>logrotate</application> periodically archives these files. When initiating log rotation, <application>logrotate</application> must ensure that the application sends further output to the new file. This is commonly done with a <literal>postrotate</literal> script that sends a <literal>SIGHUP</literal> signal to the application, which then reopens the log file. In <productname>PostgreSQL</productname>, you can run <command>pg_ctl</command> with the <literal>logrotate</literal> option instead. When the server receives this command, the server either switches to a new log file or reopens the existing file, depending on the logging configuration (see <xref linkend="runtime-config-logging-where"/>). PostgreSQL組み込みのログ収集機構により生成されるログファイルを集めるのにlogrotateを設定することで、上の方法を組み合わせることができます。 この場合、ログ収集機構はログファイルの名前と位置を定義する一方、logrotateは周期的にそのファイルをアーカイブします。 ログローテーションを開始する時に、logrotateはアプリケーションが以降の出力を新しいファイルに送ることを確実にしなければなりません。 通常これは、アプリケーションにSIGHUPシグナルを送るpostrotateスクリプトにより行なわれ、アプリケーションはその後ログファイルを再度開きます。 PostgreSQLでは、その代わりにpg_ctlにlogrotateオプションを付けて実行できます。 サーバはこのコマンドを受け取ると、ログ収集の設定に応じて新しいログファイルに切り替えるか、既存のファイルを再度開くかします(19.8.1を参照してください)。

Another production-grade approach to managing log output is to send it to <application>syslog</application> and let <application>syslog</application> deal with file rotation. To do this, set the configuration parameter <varname>log_destination</varname> to <literal>syslog</literal> (to log to <application>syslog</application> only) in <filename>postgresql.conf</filename>. Then you can send a <literal>SIGHUP</literal> signal to the <application>syslog</application> daemon whenever you want to force it to start writing a new log file. If you want to automate log rotation, the <application>logrotate</application> program can be configured to work with log files from <application>syslog</application>. この他の実運用レベルのログ出力の管理方法は、syslogに送信し、syslogにファイルのローテーションを行わせることです。 このためには、postgresql.confのlog_destination設定パラメータをsyslog（syslogのみにログを出力）に設定してください。 そして、新しいログファイルへの書き込みを始めたい時に、syslogデーモンにSIGHUPシグナルを送信してください。 ログローテーションを自動化させたい場合は、logrotateプログラムを設定することで、syslogからのログファイルを扱うことができます。

On many systems, however, <application>syslog</application> is not very reliable, particularly with large log messages; it might truncate or drop messages just when you need them the most. Also, on <productname>Linux</productname>, <application>syslog</application> will flush each message to disk, yielding poor performance. (You can use a <quote><literal>-</literal></quote> at the start of the file name in the <application>syslog</application> configuration file to disable syncing.) しかし、多くのシステムではsyslogは特に巨大なログメッセージに関してあまり信頼できません。 必要なメッセージを切り詰めてしまったり、破棄してしまったりする可能性があります。 また、Linuxでは、syslogはメッセージごとにディスクに書き出すため、性能が良くありません。 （同期化を無効にするため、syslog設定ファイル内のファイル名の先頭に「-」を使うことができます。）

Note that all the solutions described above take care of starting new log files at configurable intervals, but they do not handle deletion of old, no-longer-useful log files. You will probably want to set up a batch job to periodically delete old log files. Another possibility is to configure the rotation program so that old log files are overwritten cyclically. 上述の手法は全て、新しいログファイルを開始する周期を設定することができますが、古い、既に役に立たなくなったログファイルの削除は扱わないことに注意してください。 おそらく定期的に古いログファイルを削除するバッチジョブを設定することになるでしょう。 他に、ローテーション用プログラムを設定して古いログファイルを周期的に上書きさせるという方法もあります。

<ulink url="https://pgbadger.darold.net/"><productname>pgBadger</productname></ulink> is an external project that does sophisticated log file analysis. <ulink url="https://bucardo.org/check_postgres/"><productname>check_postgres</productname></ulink> provides Nagios alerts when important messages appear in the log files, as well as detection of many other extraordinary conditions. pgBadgerという外部プロジェクトは洗練されたログファイルの解析を行います。 check_postgresは、通常ではない多くの状態の検出を行うのと同時にログファイルに重要なメッセージが現れた時にNagiosで警告する機構を提供します。