使用 log_fdw 扩展通过 SQL 访问数据库日志 - Amazon Relational Database Service
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

使用 log_fdw 扩展通过 SQL 访问数据库日志

RDS for PostgreSQL 数据库实例支持 log_fdw 扩展,您可以使用该扩展通过 SQL 界面访问数据库引擎日志。此 log_fdw 扩展提供了两个新函数,便于创建数据库日志的外部表:

  • list_postgres_log_files – 列出数据库日志目录中的文件,以及文件大小 (以字节为单位)。

  • create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text) – 针对当前数据库中的指定文件构建外部表。

log_fdw 创建的所有函数均归 rds_superuser 所有。rds_superuser 角色的成员可以将这些函数的访问权限授予其他数据库用户。

默认情况下,日志文件由 Amazon RDSstderr(标准错误)格式生成,如 log_destination 参数中指定。此参数只有两个选项,即,stderrcsvlog(逗号分隔值,CSV)。如果您为参数添加 csvlog 选项,Amazon RDS 会同时生成 stderrcsvlog 日志。这可能会影响数据库集群的存储容量,因此您需要了解影响日志处理的其它参数。有关更多信息,请参阅 设置日志目标(stderr、csvlog)

生成 csvlog 日志的一个优势是 log_fdw 扩展允许您构建将数据整齐地拆分为多个列的外部表。为此,您的实例需要与自定义数据库参数组关联,以便您可以更改 log_destination 的设置。有关如何执行此操作的更多信息,请参阅在 RDS for PostgreSQL 数据库实例上使用参数

以下示例假设 log_destination 参数包含 cvslog

使用 log_fdw 扩展
  1. 安装 log_fdw 扩展。

    postgres=> CREATE EXTENSION log_fdw; CREATE EXTENSION
  2. 创建日志服务器,作为外部数据包装器。

    postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw; CREATE SERVER
  3. 选择日志文件列表中的所有文件。

    postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;

    示例响应如下所示。

    file_name | file_size_bytes ------------------------------+----------------- postgresql.log.2023-08-09-22.csv | 1111 postgresql.log.2023-08-09-23.csv | 1172 postgresql.log.2023-08-10-00.csv | 1744 postgresql.log.2023-08-10-01.csv | 1102 (4 rows)
  4. 为所选文件创建包含单个“log_entry”列的表。

    postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log', 'log_server', 'postgresql.log.2023-08-09-22.csv');

    除了告知现在存在表格外,响应不提供详细信息。

    ----------------------------------- (1 row)
  5. 选择日志文件的示例。以下代码检索日志时间和错误消息描述。

    postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;

    示例响应如下所示。

    log_time | message ----------------------------------+--------------------------------------------------------------------------- Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0 Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578 Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0 Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1 (7 rows)