データベースサーバのログ出力を/dev/null
に渡して単に破棄するのではなく、どこかに保存しておくことを推奨します。
問題の原因を究明する時にログ出力は貴重です。
しかし、ログ出力は(特により高いデバッグレベルの時に)巨大になりがちですので、際限なく保存したくはないでしょう。
新しいログファイルを開始させ、適切な期間を経過した古いログファイルを捨てるために、ログファイルを「回転」させる必要があります。
単にpostgres
のstderrをファイルに渡している場合、ログ出力を保持できますが、そのログファイルを切り詰めるためにはサーバを停止させ、再度起動させるしか方法がありません。
開発環境でPostgreSQLを使用しているのであればこれで構いませんが、実運用サーバでこの振舞いが適切となることはほぼありません。
サーバのstderrを何らかのログ回転プログラムに送信する方が良いでしょう。
組み込みのログ回転機能があり、postgresql.conf
のlogging_collector
設定パラメータをtrue
に設定することでこれを使用することができます。
このプログラムを制御するパラメータについては19.8.1. ログの出力先で説明します。
また、この方法を使用して、機械読み取りしやすいCSV(カンマ区分値)書式でログデータを取り込むことができます。
また、既に他のサーバソフトウェアで使用している外部のログ回転プログラムがあるのであれば、それを使用したいと考えるでしょう。
例えば、Apache配布物に含まれるrotatelogsをPostgreSQLで使用することができます。
これを行うには、単にサーバのstderrを目的のプログラムにパイプで渡してください。
pg_ctl
を使用してサーバを起動している場合はstderrは既にstdoutにリダイレクトされていますので、以下の例のようにコマンドをパイプする必要があるだけです。
pg_ctl start | rotatelogs /var/log/pgsql_log 86400
この他の実運用レベルのログ出力の管理方法は、syslogに送信し、syslogにファイルの回転を行わせることです。
このためには、postgresql.conf
のlog_destination
設定パラメータをsyslog
(syslogのみにログを出力)に設定してください。
そして、新しいログファイルへの書き込みを始めたい時に、syslogデーモンにSIGHUP
シグナルを送信してください。
ログ回転を自動化させたい場合は、logrotateプログラムを設定することで、syslogからのログファイルを扱うことができます。
しかし、多くのシステムではsyslogは特に巨大なログメッセージに関してあまり信頼できません。
必要なメッセージを切り詰めてしまったり、破棄してしまったりする可能性があります。
また、Linuxでは、syslogはメッセージごとにディスクに書き出すため、性能が良くありません。
(同期化を無効にするため、syslog設定ファイル内のファイル名の先頭に-
を使うことができます。)
上述の手法は全て、新しいログファイルを開始する周期を設定することができますが、古い、既に役に立たなくなったログファイルの削除は扱わないことに注意してください。 おそらく定期的に古いログファイルを削除するバッチジョブを設定することになるでしょう。 他に、回転用プログラムを設定して古いログファイルを周期的に上書きさせるという方法もあります。
pgBadgerという外部プロジェクトは洗練されたログファイルの解析を行います。 check_postgresは、通常ではない多くの状態の検出を行うのと同時にログファイルに重要なメッセージが現れた時にNagiosで警告する機構を提供します。