PostgreSQL 的审计还是要借助PostgreSQL的扩展pgaudit 来进行。有些熟悉PG的同学可能说，不是可以log_statement = all 来记录所有的语句吗，干嘛那么麻烦，自己去查日志不就好了。实际上如果公司有审计部门的情况下，这样是过不了关的，需要一个与商业数据功能相差无几的方式来面对审计部门的“亲和力”。
安装很简单，如果熟悉extension的话，当然pgaudit需要加载链接库中
与大部分的audit 的方式不同pg_audit记录在标准的PostgreSQL日志中。Pgaudit通过在模块加载时注册自身并为executorStart、executorCheckPerms、processUtility和object_access提供挂钩来工作。因此，pgaudit与另一种audit-trigger不同支持读取(SELECT、COPY)。一般来说，使用pgaudit，我们可以有两种操作模式，或者将它们结合使用:
session 模式或object 模式。
其中可以进行监控的方式
- READ (select, copy from)
- WRITE (insert, update, delete, truncate, copy to)
- FUNCTION (function calls and DO blocks)
- ROLE (grant, revoke, create/alter/drop role)
- DDL (all DDL except those in ROLE)
- MISC (discard, fetch, checkpoint, vacuum)
从上面可以审计监控的东西来说，还是很全面的。
下面我们可以来做一个测试
我们创建一个表，而这个表应该被audit 日志来记录，我们看看audit 日志是否记录了。从下图可以看到
在日志中已经添加了audit 的记录。
说明这个东西还是蛮好用的。日志的格式
- AUDIT_TYPE - 告知你目前的audit 的方式是 session 还是 object
- STATEMENT_ID - 主语句的会话ID
- SUBSTATEMENT_ID - 主语句中每个子语句的顺序ID。
- Operation type 操作的方式是DDL DCL DML
- COMMAND - 操作的命令
- OBJECT_TYPE - 操作的OBJECT 类型
- OBJECT_NAME - 操作的OBJECT 类型的名字，例如表名，存储过程名等等
- STATEMENT - 执行的语句
- PARAMETER - 相关的参数
此时有人可能提出，这个设计的不好，为什么不能设计到插入到表中，个人觉得有两点，既然叫审计日志，1 他是提供审计的 2 他是日志
如果日志在某些情况下爆发增长，怎么办，塞满整个表的存储空间，从多方面考虑，让日志存储在适当的地方，其实是一个比较规范的做法。
下面我们来做几个尝试来看看审计日志是否能帮助我们，记录相关的操作，下图是PG相关的audit 选项。
相关的一些设置设什么意思
pgaudit.log
指定会话审计日志记录哪些语句类。
可以设置的类别 read , write ,function,role ,ddl,misc , All 等
pgaudit.log_catalog
指定当一条语句中的所有关系都位于pg_catalog中时，应该启用会话日志记录。禁用此设置将减少来自psql和PgAdmin等工具的日志噪音，这些工具会大量查询目录。
pgaudit.log_relation
指定会话审计日志记录是否应该为SELECT或DML语句中引用的每个关系(表、视图等)创建单独的日志条目。对于不使用对象审计日志记录的穷举日志记录，这是一个非常有用的快捷方式。
例如我们要记录 ddl ，role , functiton,以及更改系统配置 方面的操作记录
当然，这样的操作记录也不是没有缺点的，例如我想知道是那个账户做的某件事，这点还是没有做到，仅仅是知道在什么时间做了什么。
