[アップデート] Aurora PostgreSQL 互換のログを CloudWatch Logs に出力できるようになりました!

Aurora PostgreSQL 互換でも CloudWatch Logs が利用可能になりました。
2019.08.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Aurora PostgreSQL 互換をお使いの皆さま。待望のアップデートが来ましたよ!

これまで Aurora MySQL 互換や、RDS for PostgreSQL は CloudWwatch Logs に対応していましたが、ついに Aurora PostgreSQL 互換でも利用可能になりました。

何が嬉しいのか

CloudWatch Logs に出力することで以下のようなことが実装しやすくなります。

  • ログイベントを検出して通知したり、Lambda と連携して何かアクションを行う
  • Kinesis Data Firehose と連携して S3 へログを保存
  • CloudWatch Logs Insights を使ってログの調査

制限

  • 執筆時点で確認したかぎりでは、エンジンバージョン 10.7 のみ対応

やってみる

Aurora クラスターの作成

それでは早速ためしてみましょう。RDS 管理コンソールから Aurora PostgreSQL 互換(エンジンバージョン 10.7)の作成を行います。[追加設定]を開くと[ログのエクスポート]という項目が増えていますね。[Postgresql ログ]にチェックをいれて作成します。

クラスタパラメータグループの変更

log_statement はデフォルトで none になっていますので必要な情報を取得できるように変更してください。

また、監査ログについては執筆時点の公式ガイドでは以下のように記載されています。

An alternative way to publish audit logs to CloudWatch Logs is by enabling advanced auditing and setting the cluster-level DB parameter server_audit_logs_upload to 1. The default for the server_audit_logs_upload parameter is 0.

PostgreSQL 互換のクラスターパラメータグループを探しても server_audit_logs_upload は見当たりません。コレは MySQL 互換のコピペではなかろうか…。

PostgreSQL 互換の場合、 pgaudit を利用することになるかと思います。

pgaudit の設定は、以下 RDS PostgreSQL のドキュメントですが、Aurora PostgreSQL 互換においても同様の手順で設定可能ですので、コチラを参考にしながら設定しました。

今回は検証のため以下のように設定しています。ログが出やすい設定にしていますので、実環境の場合は適切に絞りこんでください。

パラメータ 設定値
log_min_duration_statement 1
log_statement all
pgaudit.log all
pgaudit.role rds_pgaudit
shared_preload_libraries pgaudit

確認

CloudWatch Logs を確認すると、以下の形式のロググループが作成されています。 Aurora DBクラスターの新しいロググループはcluster-name、DBクラスター名とlog_typeログタイプを表す次のプレフィックスの下に自動的に作成されます。

/aws/rds/cluster/{cluster-name}/{log_type}

ちゃんとログが出ていることが確認できました!

ログフィルター

PostgreSQL では log_statementpgaudit も同じログファイルに出力されてしまうのですが、CloudWatch Logs であれば簡単にフィルタすることが出来るので良いですね!

スロークエリ

pgaudit ログ

また、CloudWatch Logs Insights を使った分析も簡単にできるので、是非お試しください!

さいごに

これまで Aurora PostgreSQL 互換のログ管理はユーザー側で何らかの仕組みを容易する必要がありましたが、これからはマネージドサービスで管理できるというのは非常にうれしいですね。CloudWatch Logs 連携ができないことで、Aurora PostgreSQL 互換を断念していた方はこれを機に再検討してみては如何でしょうか!?

以上!大阪オフィスの丸毛(@marumo1981)でした!