PG日志审计
日志审计的几种方式
- PostgreSQL自带的日志审计，实现语句级别，数据库级别，用户级别的审计。
弊端是审计颗粒度太大。
http://blog.163.com/digoal@126/blog/static/16387704020132208241607/
- 通过事件触发器审计数据库或限制数据库的DDL操作。
弊端是目前只能审计DDL操作。
http://blog.163.com/digoal@126/blog/static/16387704020132131361949/
- 使用pg_log_userqueries模块审计用户级或数据库级的数据库操作。
弊端是颗粒度太大。
http://blog.163.com/digoal@126/blog/static/1638770402012019112218804/
- 使用hstore和触发器跟踪表级别的数据操作。
弊端是性能开销大。
http://blog.163.com/digoal@126/blog/static/163877040201252575529358/
- 使用hstore和触发器跟踪表级别的数据操作，并实现flashback query。
弊端是性能开销大，不适合频繁DML操作的表。
http://blog.163.com/digoal@126/blog/static/1638770402014728105442434/
- 修改数据库默认的命令级别，GetCommandLogLevel@src/backend/tcop/utility.c，定制日志输出。
弊端是需要修改源码。
http://blog.163.com/digoal@126/blog/static/163877040201421702248430/
- pg_audit 9.5的插件
其实也是颗粒度较大的，审计没有细化到行级别，要做行级别的审计，还是需要用触发器。
优势：
- 可以记录嵌套级别的SQL，例如一个on line code, 或者函数调用，里面的SQL也可以被记录下来。
- 支持对象审计，这种审计方法比较奇特，例如我要审计某个表的INSERT操作，那么首先在数据库中创建一个审计角色，把这个表的INSERT权限赋予给这个审计角色，那么任何人对这个表执行INSERT都会被审计。
http://blog.163.com/digoal@126/blog/static/163877040201541595510867/
https://my.oschina.net/yonj1e/blog/1506620
自带的基础log相关配置
logging_collector
是否开启日志收集开关，默认off，开启要重启DB
log_destination
日志记录类型，默认是stderr，只记录错误输出
log_directory
日志路径，默认是$PGDATA/pg_log
log_filename
日志名称，默认是postgresql-%Y-%m-%d_%H%M%S.log
log_connections
用户session登陆时是否写入日志，默认off
log_disconnections
用户session退出时是否写入日志，默认off
log_rotation_age
保留单个文件的最大时长,默认是1d
log_rotation_size
保留单个文件的最大尺寸，默认是10MB
pg_statement
参数值是none，即不记录，可以设置ddl(记录create,drop和alter)、mod(记录ddl+insert,delete,update和truncate)和all(mod+select)。
log_min_duration_statement
来记录超过该时长的所有SQL，对找出当前数据库的慢查询很有效。 比如log_min_duration_statement = 2s,记录超过2秒的SQL，改完需要reload
log_duration
记录每个已完成语句的持续时间。默认值是off。只有超级用户可以改变这个设置。对于使用扩展查询协议的客户端，语法分析、邦定、执行每一步所花时间都分别记录。
log_checkpoints
看系统一天之类发生了多少次checkpoint，以及每次checkpoint的一些详细信息，比如buffer,sync等，就可以通过设置log_checkpoints，该参数默认值是off，修改log_checkpoints = on
log_lock_waits
数据库的锁通常可以在pg_locks这个系统表里找，但这只是当前的锁表/行信息，如果你想看一天内有多少个超过死锁时间的锁发生，可以在日志里设置并查看，log_lock_waits 默认是off，可以设置开启。这个可以区分SQL慢是资源紧张还是锁等待的问题。
log_file_mode = 0600
日志文件权限
log_error_verbosity = verbose
控制记录的每条消息写到服务器日志里的详细程度。有效的值是TERSE,DEFAULT和VERBOSE，逐个向显示的消息里增加更多的字段。TERSE包含 DETAIL的记录, HINT,QUERY和CONTEXT错误消息。 VERBOSE输出包含SQLSTATE错误代码 (参见附录 A)以及源代码文件名称，函数名称，以及产生错误的行数。只有超级用户可以改变这个设置。
log_min_error_statement (enum)
控制在服务器日志里输出哪一条导致错误条件的SQL语句。所有导致一个特定级别(或者更高级别)错误的 SQL 语句都要被记录。有效的值有DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL和PANIC。缺省是ERROR，表示所有导致错误、日志信息，致命错误、恐慌的SQL语句都将被记录。设置为PANIC表示把这个特性关闭。只有超级用户可以改变这个设置。
log_min_messages (enum)
控制写到服务器日志里的消息的详细程度。 有效值是DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL和 PANIC。 每个级别都包含它后面的级别。越靠后的数值发往服务器日志的消息越少。缺省是WARNING。 需要注意的是这里的LOG和client_min_messages里的级别不同。只有超级用户可以修改这个设置。
参考资料
https://blog.csdn.net/czp11210/article/details/39896985
http://blog.163.com/digoal@126/blog/static/163877040201541595510867/
https://my.oschina.net/yonj1e/blog/1506620