【実務・中級編】ログ出力と監視の基礎 – PostgreSQL

PostgreSQLの「声」を聞こう！ログ出力と監視の基本、これでバッチリ！

やあ！PostgreSQLの世界へようこそ。この記事では、データベースの「健康診断」とも言えるログ出力と監視の基本について、現場で役立つ実践的なポイントを先輩エンジニアの視点から、分かりやすく解説していくよ。

「ログ？監視？なんか難しそう…」って思ったかもしれないけど、心配しないで！これらはデータベースを安定運用するために、めちゃくちゃ大事なことなのに、実はそんなに複雑じゃないんだ。むしろ、これらをしっかり理解しておくと、トラブルシューティングのスピードが劇的に変わるし、パフォーマンス改善のヒントもたくさん見つかるんだ。

よし、早速、PostgreSQLの「声」を聞くための第一歩を踏み出そう！

なぜログと監視がそんなに大事なのか？

まず、なんでわざわざログを見たり、監視したりする必要があるのか、その理由を軽くおさらいしておこう。

トラブルシューティングの生命線: 何か問題が起きたとき、ログは「何が」「いつ」「どのように」起きたのかを教えてくれる、まさに証拠。これがないと、原因特定に時間がかかりすぎて、ビジネスに大きな影響が出ちゃうこともある。
パフォーマンスのボトルネック発見: ログや監視データを見ることで、普段は気づかない処理の遅延や、リソースの無駄遣いを発見できる。「なんか最近重いな〜」なんていう漠然とした感覚を、具体的なデータで裏付けられるのは大きいよね。
セキュリティの強化: 不審なアクセスや、意図しない操作の痕跡もログに残る。これをチェックすることで、セキュリティリスクを早期に発見し、対策を打つことができる。
将来のキャパシティプランニング: 過去の利用状況を分析して、将来どれくらいのリソースが必要になるかを予測するのに役立つ。

つまり、ログと監視は、データベースを「健康」に保ち、さらに「強く」していくための、なくてはならないツールなんだ。

ログ出力の基本：PostgreSQLは何を語るのか？

PostgreSQLは、その活動の大部分をログに出力してくれる。これをどう設定して、どう活用するかが最初のステップだ。

ログレベルの設定：どのくらい詳しく知りたい？

ログには「レベル」があって、どのレベル以上のメッセージを出力するかを設定できる。これが結構重要で、闇雲に全部出力させるとログが肥大化しすぎるし、逆に情報が少なすぎると、いざという時に役立たない。

よく使われるレベルはこんな感じだよ。

`ERROR`: エラーが発生したときに記録される。これは最低限必須だね。
`WARNING`: 潜在的な問題や、非推奨の機能を使っている場合などに記録される。これも見ておくと良い。
`NOTICE`: ユーザーに知っておいてほしい情報。例えば、テーブルの自動解析が行われたときなど。
`INFO`: 比較的情報量の多いメッセージ。
`LOG`: サーバーの起動・停止、チェックポイントなどの管理情報。
`DEBUG1`～`DEBUG5`: デバッグ用の詳細な情報。通常運用では使わないことが多いかな。

具体的な設定方法

ログレベルは、`postgresql.conf`ファイルで設定するんだ。`postgresql.conf`は、PostgreSQLのインストールディレクトリの中にあることが多いんだけど、場所が分からない場合は、以下のSQLで確認できるよ。

SHOW config_file;

`postgresql.conf`ファイルを開いて、`log_min_level` という行を探して、好きなレベルに変更しよう。例えば、エラーと警告、通知だけ欲しいなら、こんな感じ。

log_min_level = ‘WARNING’

もし、より詳細な情報が必要で、かつディスク容量に余裕があるなら、`NOTICE`や`LOG`あたりまで上げてみるのもアリだ。

【現場からのワンポイントアドバイス】
初心者のうちは、まずは `WARNING` あたりから始めて、様子を見るのがおすすめ。で、何か問題が起きたら、一時的に `NOTICE` や `LOG` まで上げて、原因を特定したら元に戻す、という運用が現実的かな。`DEBUG` 系は、本当に原因特定のために一時的にしか使わない方が良いよ。ディスクを食い潰しちゃうからね！

ログファイルの場所：どこに宝は埋まっている？

ログファイルがどこに出力されるかも、知っておくべき重要な情報だ。これも`postgresql.conf`で設定するんだけど、`log_directory` と `log_filename` という設定項目がある。

`log_directory`: ログファイルの出力先ディレクトリを指定する。
`log_filename`: ログファイルの名前のパターンを指定する。

もし、これらの設定が明示的にされていない場合、PostgreSQLはデータディレクトリ内の`log`サブディレクトリに出力することが多い。

こちらも、SQLで確認できるよ。

SHOW log_directory;
SHOW log_filename;

【現場からのワンポイントアドバイス】
ログファイルは、サーバーのOS上で確認することになる。SSHでサーバーにログインして、`log_directory` で指定されたパスに移動して、`log_filename` のパターンに合ったファイルを探すんだ。ファイル名に日付が入るように設定しておくと、日ごとにログを管理できて便利だよ。例えば、`log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log’` のようにしておくと、タイムスタンプ付きのファイル名になる。

ログのローテーション：ログファイルが巨大化しないように

ログファイルがずっと増え続けると、ディスク容量を圧迫してしまう。そこで、ログファイルを定期的に新しいファイルに切り替える「ログローテーション」という仕組みが重要になる。

PostgreSQL自体にも、`log_rotation_age` や `log_rotation_size` といった設定があって、一定時間経過したり、ファイルサイズが大きくなったりしたら自動でローテーションしてくれる。

`log_rotation_age`: 新しいログファイルを作成するまでの時間（例: `1d` で1日ごと）。
`log_rotation_size`: 新しいログファイルを作成するまでのサイズ（例: `10MB`）。

ただ、これらの設定は、OSのログローテーションツール（`logrotate`など）と組み合わせて使うのが一般的かな。OSレベルで管理する方が、より柔軟で強力なローテーション設定ができるからね。

サーバーの状態を「覗き見」！基本的な監視ビュー

ログは「過去の出来事」を教えてくれるんだけど、今この瞬間のデータベースの状態を知るためには、「監視ビュー」が役立つんだ。

PostgreSQLには、サーバーの内部状態をSQLで参照できる便利なビューがたくさん用意されている。その中でも、特によく使うのが `pg_stat_activity` だ。

`pg_stat_activity`：今、何が起きてる？

このビューは、現在実行中の全てのプロセス（バックエンドプロセス）の情報を表示してくれる。これを見れば、

どのクライアントが接続しているか
どんなクエリが実行されているか
クエリはどのくらい時間がかかっているか
クエリの状態（実行中、待機中など）

といったことが一目でわかるんだ。

SELECT
pid,
datname,
usename,
client_addr,
client_port,
backend_start,
state,
query_start,
query
FROM
pg_stat_activity
WHERE
state != ‘idle’
ORDER BY
query_start;

このクエリを実行すると、アイドル状態ではない（つまり、何か処理をしている）アクティブなプロセスの一覧が表示される。`query` の部分に実行中のSQLが表示されるから、何が動いているのか、すぐに把握できるはずだ。

【現場からのワンポイントアドバイス】
`pg_stat_activity` は、パフォーマンスチューニングの時に「このクエリ、なんでこんなに時間かかってるんだ？」とか、「なんか怪しいクエリが動いてないかな？」って確認するのにめちゃくちゃ使う。状態が `active` になっているのに `query_start` がすごく昔だったら、それは長時間のクエリで、もしかしたら止まっているか、すごく遅い処理の可能性が高い。あとは、`wait_event_type` や `wait_event` っていうカラムもあるんだけど、これを見ると「何待ち」なのかがわかるんだ。例えば、`Lock` 待ちだったり、I/O待ちだったり。これが分かると、原因究明の糸口になることが多いよ。

その他の便利な監視ビュー

`pg_stat_activity` 以外にも、知っておくと便利なビューがいくつかある。

`pg_stat_statements`: 実行されたクエリの統計情報（実行回数、合計実行時間、平均実行時間など）を記録してくれる。
注意: この機能は、`postgresql.conf` で `shared_preload_libraries = ‘pg_stat_statements’` のように設定し、PostgreSQLを再起動する必要がある。さらに、各データベースごとに `CREATE EXTENSION pg_stat_statements;` を実行する必要もある。
これを使えば、どのクエリが一番重いのか、よく実行されているのかを特定できる。パフォーマンスチューニングの超定番だ。

`pg_locks`: 現在、データベース内で取得されているロックの情報を確認できる。
ロック競合が原因で処理が遅くなっている場合、このビューで原因を特定できることがある。

`pg_stat_database`: データベースごとの統計情報（トランザクション数、ブロックの読み書き回数など）を提供する。
データベース全体の負荷状況を把握するのに役立つ。

まとめ：ログと監視は「対話」の第一歩

どうかな？PostgreSQLのログ出力と監視の基本、イメージできたかな？

ログはPostgreSQLが「話していること」に耳を傾けるためのもので、監視ビューは「今、どうしている？」と問いかけて、その「返事」を聞くようなもの。この二つをうまく使いこなせるようになると、データベースとの付き合い方がぐっと楽になるし、より深く理解できるようになるはずだよ。

最初は `postgresql.conf` の設定に戸惑うかもしれないけど、まずは `log_min_level` を `WARNING` に設定して、ログファイルがどこに出力されるかを確認するところから始めてみよう。そして、時々 `pg_stat_activity` を `psql` で覗いてみる。それだけでも、データベースの「調子」を掴む感覚が養われてくるはずだ。

これらは、あくまで「基本のキ」。もっと高度な監視ツールや、ログ分析ツールもあるけれど、まずはこの標準機能で十分、いや、むしろこれらをしっかり理解していることが、どんなツールを使うにしても土台になるんだ。

これからも、PostgreSQLのいろいろな「声」に耳を澄ませて、データベースを健やかに、そしてパワフルに育てていこう！何か分からないことがあったら、いつでも聞いてくれよな！