上周有个做支付系统的老同事来找我说他们线上某张账户配置表被人改了一行业务侧对不上账想知道是谁在什么时间动的。结果我们俩在服务器上翻了两个小时 PostgreSQL 的日志除了一堆 checkpoint、autovacuum 和慢查询记录能用的线索只有一条孤零零的 ERROR。这事儿我碰到过太多次了——绝大多数团队装完 PostgreSQL开着默认配置就觉得出事能查真到了要出审计结论、要交合规材料的时候才发现日志里根本没有谁、什么时候、对哪张表、改成了什么这条链。PostgreSQL 的审计日志说白了就是把数据库当成一个有门禁、有监控、有出入登记的房间来管。它要回答的问题比普通运行日志苛刻得多谁数据库用户、来源 IP、应用名、在什么时间、从哪个会话、执行了什么操作、影响的哪张表哪一行、改之前是什么、改之后是什么、成功还是失败。这套东西在 PostgreSQL 里没有一键开启的开关得靠内置日志参数、pgaudit 扩展、触发器审计表三套机制拼出来而且每一套都有自己的性能代价和盲区。下面我把自己在几套生产环境里踩过的路完整写一遍从方案选型、参数配置、容量估算到留存 180 天怎么落地、常见故障怎么排查尽量给到能直接抄的程度。刚接触 PostgreSQL 的朋友也能看懂因为我会把每个参数为什么这么设讲清楚。1. 先把需求拆开你到底要审计什么1.1 审计日志和运行日志不是一回事很多人的第一反应是日志不就是日志吗但 PostgreSQL 里这两类东西的目标完全不同。运行日志也叫错误日志、服务器日志服务的是运维排障连接失败、死锁、检查点太频繁、复制断流这些信息密度低、格式松散、保留几天到几周就够了。审计日志服务的是事后追责和合规举证它要求记录完整、不可抵赖、可检索、能长期保存通常要留 6 个月也就是 180 天左右。这两个目标放在同一个文件里会互相打架。运行日志追求别太多审计日志追求一条都别少运行日志可以随手清审计日志清早了就是合规事故。我一般建议在物理上就分开审计日志走独立的 pgaudit 输出通道或者独立的审计 schema物理目录也尽量落在不同的磁盘或者不同的挂载点上后面第 4 节会讲具体怎么分。还有一个认知误区是把 PostgreSQL 的日志当成数据库操作记录。默认配置下log_statement none意思是业务发过来的 SQL 一条都不记。你看到的那点日志都是系统自己产生的。所以默认就有审计能力这个前提本身是错的。1.2 三个层级的审计需求对应三套方案我把实际项目里遇到的需求归成三类方案选择完全不一样。需求层级典型场景推荐方案代价连接级谁在什么时候连上来的、登录成功还是失败、来源 IPlog_connections/log_disconnections几乎为零语句级谁执行了哪些写操作和 DDL、影响哪些表pgaudit扩展中等写入量增加行级某一行数据改前改后的具体值触发器审计表高写入放大明显连接级是最便宜的两个参数打开就完事但它只能告诉你有人进来了进来说了什么做了什么完全看不到。语句级是绝大多数合规场景的甜点区pgAudit 能覆盖 DDL、写入、角色变更这些关键类别而且不侵入业务代码。行级审计才是真正的改前改后代价也最大——一条UPDATE影响 100 万行触发器就得往审计表里插 100 万条记录。我的建议是分层配置所有库都开连接级核心业务库开语句级只有真正的敏感表资金、权限、配置才上触发器行级审计。一上来全库全表行级审计基本上第二周就会因为磁盘和性能问题被叫停。1.3 为什么我不建议一上来就log_statement alllog_statement all是最容易想到的做法改了 reload 一下立刻生效什么都能看到。但它在生产环境里几乎必然翻车原因有三个。第一是量太大。一个中等业务库每秒 1000 个语句不算多每条语句加上前缀平均 300 字节一天就是 24 GB 左右的原始文本180 天下来 4 TB 以上还没算索引和解析开销。第二是噪音淹没信号。所有 SELECT 都被记进去之后真正的告警反而看不见了。我经历过一次事故排查运维同事在 30 GB 的日志里找一条 DDLgrep 跑了小十分钟。第三是log_statement有个容易被忽略的细节它记录的是语句文本绑定参数默认不展开。也就是说你用预编译语句批量插入日志里只有INSERT INTO t (a, b) VALUES ($1, $2)看不到实际值。很多人以为开了all就能看到数据结果发现看不到白付了性能代价。要看参数值得靠log_min_duration_statement输出的 DETAIL 行那个受log_parameter_max_length控制默认只截 1 kB。2. PostgreSQL 内置日志能力到底能覆盖多少2.1 四个必须搞明白的语句级参数内置的语句日志主要由四个参数控制理解它们的语义差异比记住名字重要得多。log_statement取值none/ddl/mod/all。ddl只记 DDLmod记 DDL 加上会改数据的语句INSERT、UPDATE、DELETE、TRUNCATE、COPY FROMall全记。注意SELECT只有在all里才有。log_min_duration_statement设为0表示记录所有语句及其执行耗时设为-1关闭设为正数则是慢查询阈值。它的副产品是会把绑定参数的值打到 DETAIL 里这正是它能当穷人版参数审计用的原因。log_min_error_statement默认error意思是错误级别达到 error 的语句会连带 SQL 文本一起记录下来。权限拒绝、约束冲突都在这个范围内这块内容在审计里价值很高别关。log_duration只记耗时不计语句单独用意义不大容易和log_min_duration_statement重复。一个常见的组合是log_statement ddl配log_min_duration_statement 200。DDL 全量留痕写入类语句靠慢查询兜底量能压到很低。缺点也很明显快的那部分写入就查不到了。这属于性能优先的取舍做合规审计是不够的。2.2log_line_prefix决定日志能不能用这是我在很多环境里见过被忽略得最严重的一个参数。默认值是%m [%p] 只有时间戳和进程号。这样的日志你能看出发生了什么但看不出是谁干的。审计场景下我会把它设成这样log_line_prefix %m [%p] %q%u%d/%a %h 逐段解释一下。%m是带毫秒的时间戳写审计就一定要到毫秒几十毫秒内的操作顺序靠秒级时间戳是分不出来的。%p是后端进程 PID用来串联同一条连接的多个日志行。%q是个占位暂停符只在会话进程里解析后面的内容后台进程走到这里就停住不加它在后台进程日志里会多出一堆空字段。%u是数据库用户名%d是数据库名%a是 application_name这三个是审计的骨架。%h是客户端地址PostgreSQL 12 之后才有之前是%r带端口的主机名形式。这里有个坑必须提醒log_hostname默认是off如果开了PostgreSQL 会对每个连接做反向 DNS 解析。在 DNS 不稳的环境里这会让连接建立时间从毫秒级涨到秒级我见过一次因为它导致连接池超时的。审计要的是 IP不是主机名所以保持off。还有一个更隐蔽的坑当log_destination里包含csvlog时log_line_prefix会被完全忽略。因为 CSV 日志用的是固定的列结构用户名、数据库名、应用名这些都有专门的列不需要前缀拼字符串。我第一次切 CSV 格式的时候以为前缀配置丢了导致审计信息全没了查了半天才发现是这个原因。2.3 CSV 和 JSON 格式为后期分析留后路纯文本日志适合人看不适合机器分析。PostgreSQL 提供了两种结构化输出csvlog9.0 起和jsonlog15 起。审计日志强烈建议用结构化格式原因只有一个——后期要能导入数据库做关联查询。CSV 格式可以直接COPY进一张表PostgreSQL 官方文档里就给了建表语句和导入命令我把它整理成可以直接执行的版本CREATE TABLE public.postgres_log ( log_time timestamp(3) with time zone, user_name text, database_name text, process_id integer, connection_from text, session_id text, session_line_num bigint, command_tag text, session_start_time timestamp with time zone, virtual_transaction_id text, transaction_id bigint, error_severity text, sql_state_code text, message text, detail text, hint text, internal_query text, internal_query_pos integer, context text, query text, query_pos integer, location text, application_name text, backend_type text ); COPY public.postgres_log FROM /pgdata/log/postgresql-2026-06-01_000000.csv WITH (FORMAT csv);导进表之后审计就变成了普通的 SQL 查询按user_name分组统计操作次数、找出非工作时间执行 DDL 的账号、定位某个 IP 在某张表上的全部写操作。这套做法比 grep 高效太多而且可以做二次告警。代价是导入过程本身有开销不要在主库上导大文件拉到从库或者独立的分析实例上做。2.4 内置日志的三个硬伤说了这么多内置能力也得说清楚它做不到什么否则选型会跑偏。第一它不知道改前改后。log_statement mod只记录 SQL 文本UPDATE t SET status 2 WHERE id 100你能看到但原来的 status 是几日志里没有。第二它不区分角色切换。%u记录的是连接时的认证用户如果应用在连接里执行了SET ROLE切换到业务角色日志里的用户名不会变。要看出这层切换只能靠log_statement all把SET ROLE语句本身也记下来。第三也是最重要的一点内置日志对超级用户完全不设防。任何有 superuser 权限的账号都可以执行ALTER SYSTEM SET log_statement none;然后SELECT pg_reload_conf();接着再把自己的操作做掉最后改回来。整个过程只留下两行 reload 记录。所以内置日志在公司内部的运维误操作追溯场景够用在真正需要防内部人员作恶的场景下必须配合外部采集这个后面第 5 节展开。3. pgaudit把谁做了什么补完整3.1 安装路径与版本匹配pgAudit 是 PostgreSQL 生态里事实标准的审计扩展它通过钩子挂进执行器输出走的是和内置日志同一套日志通道所以格式兼容、采集链路不用改。安装分三步。第一步确认扩展包。Debian/Ubuntu 系一般是postgresql-16-pgaudit这种命名RHEL 系走 PGDG 仓库的pgaudit_16。国产 Linux 发行版或者某些精简镜像上往往没有现成包得源码编译# 确保 postgresql-server-dev 或对应的 devel 包装好了pg_config 在 PATH 里 git clone https://github.com/pgaudit/pgaudit.git cd pgaudit git checkout REL_16_STABLE make USE_PGXS1 make install USE_PGXS1USE_PGXS1是关键不加的话 Makefile 会去找 PostgreSQL 源码树编译直接失败。pgAudit 的版本号这两年直接跟随 PostgreSQL 主版本号了16.x 对应 PostgreSQL 16装之前先对一下跨版本装虽然偶尔能跑但行为不保证。第二步改配置。这一步必须重启光 reload 不行shared_preload_libraries pgaudit第三步重启后在库里执行一次扩展登记CREATE EXTENSION IF NOT EXISTS pgaudit;这一步在 pgAudit 上主要是确认链路性质——真正的开关在 GUC 和 preload 上但执行它能验证扩展的控制文件是不是装到了SHAREDIR/extension目录下。如果这里报could not open extension control file说明包没装对位置别急着怀疑配置。3.2pgaudit.log的六档粒度怎么选pgaudit.log是审计范围的总开关可以逗号分隔多选我按实际价值排个序。类别覆盖内容我的建议writeINSERT、UPDATE、DELETE、TRUNCATE、COPY 到表必开ddl所有 CREATE、ALTER、DROP必开roleGRANT、REVOKE、CREATE/ALTER/DROP ROLE必开miscVACUUM、SET、FETCH、CHECKPOINT、DISCARD 等按需readSELECT、从表读取的 COPY谨慎量大function函数调用和 DO 块谨慎量大生产环境我最常用的组合是pgaudit.log write, ddl, role。这三个类别覆盖了数据篡改、结构变更、权限提升三类高危操作日志量又能控制在可接受范围。read只在少数场景开比如某张表涉及个人隐私数据需要记录谁查过。misc里的SET其实挺有价值因为SET ROLE和SET search_path都归它管。如果你担心应用通过切换 schema 绕过某些控制可以把它单独加上。3.3 三组容易被忽略的细粒度开关pgaudit.log_catalog默认是on意思是针对系统表pg_catalog 下的表的语句也会记录。这个默认值坑过不少人随便一个建表操作pgAudit 会往日志里写七八行全是它自己去查pg_class、pg_attribute产生的。生产上我一般设成off只留业务表的记录日志量能降一大截。pgaudit.log_parameter默认off开了之后绑定参数的值会以parameter: $1 ...的形式附加在审计行后面。开了之后日志量会明显上涨而且有个严重的安全问题——日志里会出现明文敏感数据比如手机号、身份证号甚至某些应用错误地把密码拼进了参数。我建议保持关闭需要参数值的场景用会话级的临时开关或者由应用侧通过application_name和业务流水号做关联。pgaudit.log_relation默认off开了之后每条审计记录后面会补一行RELATION: public.orders说明涉及的表。做行级溯源时它很有用但同样会显著增加行数。我的做法是只在排查期间临时打开。3.4 一条真实的审计输出长什么样配置生效后一条更新操作在日志里大致是这样2026-06-11 14:32:07.418 CST [28471] app_userordersdb/order-service 10.20.3.51 AUDIT: SESSION,1,1,WRITE,UPDATE,TABLE,public.orders, UPDATE orders SET status PAID WHERE id 88213按逗号切开看SESSION表示这是语句级审计两个1是语句编号和子语句编号WRITE是类别UPDATE是命令TABLE是对象类型public.orders是对象名最后是语句原文。配合前缀里的用户名、数据库名、应用名和来源 IP一条完整的审计记录就齐了。如果开了pgaudit.log_relation同一个语句会多出一行RELATION: public.orders如果有子查询涉及别的表还会有更多 RELATION 行。这也是它日志量大的原因。3.5 按角色精细控制审计范围ALTER ROLE ... SET可以让不同账号走不同的审计策略这个能力在做分级审计时非常好用-- 应用账号只审计写入和 DDL ALTER ROLE app_user SET pgaudit.log write, ddl; -- 数据分析账号额外审计读取 ALTER ROLE analyst SET pgaudit.log read, write, ddl; -- 运维账号关注结构变更和权限变更 ALTER ROLE dba_ops SET pgaudit.log ddl, role, misc;这样高危账号记录详细普通账号记录精简整体日志量能压到全开的三分之一以下。要注意的是角色级的设置对超级用户不生效——超级用户可以用SET pgaudit.log none在自己的会话里关掉。真要防这个得靠把超级用户的数量压到最低、用ALTER ROLE ... SET加锁再加上外部采集缺一不可。4. 行级审计触发器方案怎么做得不那么痛4.1 什么时候真的需要触发器pgAudit 解决的是语句级问题它记不下来原来的值是什么。行级审计只有一条路写触发器。适用的表其实很少——资金流水、账户余额、权限配置、风控规则、系统参数这类表通常不超过几十张。如果你的清单超过一百张表我建议先回头审视一下需求很可能把日志审计和数据版本管理两件事混在一起了后者应该用别的手段解决。触发器方案的最小可用结构大概是这样CREATE SCHEMA IF NOT EXISTS audit; CREATE TABLE audit.log_change ( id bigserial PRIMARY KEY, ts timestamptz NOT NULL DEFAULT clock_timestamp(), txid bigint NOT NULL DEFAULT txid_current(), schema_name text NOT NULL, table_name text NOT NULL, op char(1) NOT NULL, db_user text NOT NULL DEFAULT session_user, app_name text, client_addr inet, before_row jsonb, after_row jsonb ) PARTITION BY RANGE (ts); CREATE OR REPLACE FUNCTION audit.if_modified_func() RETURNS trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ DECLARE v_old jsonb; v_new jsonb; BEGIN IF TG_OP INSERT THEN v_new : to_jsonb(NEW); ELSIF TG_OP UPDATE THEN v_old : to_jsonb(OLD); v_new : to_jsonb(NEW); ELSE v_old : to_jsonb(OLD); END IF; INSERT INTO audit.log_change (schema_name, table_name, op, app_name, client_addr, before_row, after_row) VALUES (TG_TABLE_SCHEMA, TG_TABLE_NAME, left(TG_OP, 1), current_setting(application_name, true), inet_client_addr(), v_old, v_new); RETURN NULL; END; $$; CREATE TRIGGER trg_audit_orders AFTER INSERT OR UPDATE OR DELETE ON public.orders FOR EACH ROW EXECUTE FUNCTION audit.if_modified_func();函数用SECURITY DEFINER是有讲究的触发器函数默认以调用者身份执行如果业务账号对auditschema 没有 INSERT 权限触发器就会报权限错误导致业务失败。用SECURITY DEFINER让它以函数属主身份写入业务账号就不需要任何审计表的权限相当于把审计通道和业务通道隔离开。4.2 三个必须处理好的细节大字段必须排除。to_jsonb(NEW)会把整行都转成 JSON如果表里有text、bytea、jsonb类型的大字段一条审计记录可能几 MB。我踩过一次一张存合同附件的表开了审计bytea转成十六进制字符串后膨胀了两倍多一天写了 40 GB。解决办法是在函数里减掉这些键v_new : to_jsonb(NEW) - content - attachment - raw_data;jsonb - text是删键操作可以链式叠加很直观。要能过滤掉无意义的更新。很多表有updated_at字段任何一次更新都会变。如果不想让这些噪音污染审计可以在触发器上加WHEN条件CREATE TRIGGER trg_audit_orders AFTER UPDATE ON public.orders FOR EACH ROW WHEN (OLD.* IS DISTINCT FROM NEW.*) EXECUTE FUNCTION audit.if_modified_func();IS DISTINCT FROM在 PostgreSQL 行比较里是能用的配合WHEN条件可以把内容没变的空更新直接挡掉。这个优化在批量更新场景下能省掉大量无效记录。TRUNCATE 要单独处理。行级触发器不覆盖 TRUNCATE得额外加一个语句级触发器CREATE TRIGGER trg_audit_orders_trunc AFTER TRUNCATE ON public.orders FOR EACH STATEMENT EXECUTE FUNCTION audit.if_truncated_func();别小看这个我见过一次表里数据莫名没了的事故查了半天才发现是 TRUNCATE而审计日志里干干净净什么都没记。4.3 审计表本身的设计取舍审计表有几个设计原则和业务表是反的。第一不要建除主键和时间之外的索引。审计表是只写少读索引越多写入越慢180 天后的清理也更痛苦。如果确实要按表名查考虑 BRIN 索引而不是 B-tree代价小得多。第二按月分区清理用 DROP PARTITION。DELETE FROM audit.log_change WHERE ts now() - interval 180 days这种语句在十亿行级别上是灾难会产生巨量死元组、触发 autovacuum 长跑、把 WAL 撑爆。按月分区之后清理就是DROP TABLE audit.log_change_2026_01;秒级完成磁盘空间立刻回收。第三审计表绝对不能是 UNLOGGED 表。UNLOGGED 表不写 WAL崩溃或异常关机后数据会被清空这在审计场景下是致命的。同理也不要给审计表建外键和级联删除。第四审计 schema 的权限要给死。业务账号只通过SECURITY DEFINER函数间接写入不给直接的 DML 权限查询权限单独授予审计人员账号不给改和删的权限。这样连业务账号自己都删不掉审计记录。4.4 写入放大的真实代价触发器审计的性能影响得说清楚。它带来的不是多一次插入这么简单而是每次 DML 都要多写一行 JSON、多产生一份 WAL。在批量场景下这个放大很吓人一次UPDATE影响 50 万行业务侧写 50 万次审计侧再写 50 万条带 JSON 的记录WAL 量差不多翻倍。我们做过一次对比测试在同样硬件上跑 50 万行批量更新不开触发器 12 秒开行级审计 31 秒慢了 1.5 倍以上。所以批量维护脚本、数据订正脚本这类操作我一般会临时ALTER TABLE ... DISABLE TRIGGER做完再打开同时在脚本日志里留一条人工说明。这个操作有风险必须有流程约束否则就成了绕过审计的后门。5. 留存 180 天轮转、压缩、清理、检索5.1 内置轮转机制的三个参数先说清楚一个容易误解的点log_rotation_age和log_rotation_size只在logging_collector on时生效而且它们只负责切新文件不负责删旧文件。logging_collector on log_destination csvlog log_directory /data/pglog log_filename postgresql-%Y-%m-%d_%H%M%S.csv log_rotation_age 1d log_rotation_size 200MB log_truncate_on_rotation on这里有个关键陷阱。log_truncate_on_rotation的语义是当新文件名和已有文件重名时截断旧文件重用。用%Y-%m-%d_%H%M%S这种带秒级时间戳的命名文件名永远不会重名所以log_truncate_on_rotation实际上永远不会触发文件只会一直堆下去。我见过一个环境跑了一年没清理日志目录 2 TB磁盘告警了才发现。如果你希望 PostgreSQL 自己回收文件得用固定命名模式比如log_filename postgresql-%a.csv log_truncate_on_rotation on这样每周一到周日各一个文件下一周同名文件会被截断重用。代价是最长只能留 7 天而且日志被覆盖了没法做合规归档。要留 180 天就别指望它自己回收老老实实上外部清理。5.2 外部清理别用 logrotate 搬正在写的文件这是我最想强调的一条经验。很多人习惯性地写一个 logrotate 配置去切 PostgreSQL 的日志配置长这样/data/pglog/*.csv { daily rotate 180 compress delaycompress missingok notifempty copytruncate }copytruncate是先复制再清空原文件不会挪动 inode。这个方式在 append 模式下是能工作的我们在几个环境验证过写入正常。但它的风险在于复制和截断之间有个极短的时间窗这期间写入的日志可能丢失而且这个行为没有强保证PostgreSQL 换版本或者换文件系统就可能变。如果去掉copytruncate用默认的重命名再新建模式问题就大了PostgreSQL 的 syslogger 进程还拿着原来的文件句柄在写它会继续往已经被改名的文件里写内容而 logrotate 新建的那个空文件没人写。表现就是日志看起来停了磁盘上新增的文件永远是 0 字节。这个坑我踩过一次排查了两个小时。所以我的建议是轮转交给 PostgreSQL 自己log_rotation_age/log_rotation_size外部只负责压缩和删除。用一个独立的清理脚本思路很简单# 压缩 3 天前的日志 find /data/pglog -name postgresql-*.csv -type f -mtime 3 \ ! -name *.gz -exec gzip -9 {} \; # 删除 180 天前的日志 find /data/pglog -name postgresql-*.csv.gz -type f -mtime 180 -delete# 对应的 logrotate 只做压缩和计数不搬文件 /data/pglog/postgresql-*.csv.gz { monthly rotate 6 maxage 180 missingok notifempty nocreate }这里nocreate和不匹配活文件是关键。脚本里用-name *.csv.gz只匹配已压缩文件就不会碰到 PostgreSQL 正在写的那个.csv。5.3 容量估算动手算一遍容量这件事必须提前算不然一开审计就被磁盘教做人。我拿一个具体场景算给你看。假设业务库平均每秒 1000 个语句其中写操作和 DDL 占比约 8%也就是每秒 80 条需要审计的语句。pgAudit 一条审计记录的实际长度含前缀、AUDIT 行、可能的 RELATION 行按平均 400 字节算每秒80 × 400 32,000 字节约 31 KB每天31 KB × 86,400 ≈ 2.68 GB180 天2.68 × 180 ≈ 482 GB开启 gzip 压缩文本日志压缩比通常在 5:1 到 8:1约 60 到 96 GB这个量级是完全可控的。反过来看log_statement all的情况1000 条全部记录每秒1000 × 300 300,000 字节约 293 KB每天293 KB × 86,400 ≈ 24.1 GB180 天约 4.3 TB同样是审计量差了 9 倍。这就是为什么选类别比什么都重要。还有一个隐形成本要算进去峰值。虽然平均值 31 KB/s但批量任务跑起来的时候瞬时可能到几十 MB/s一分钟就能写几 GB。所以日志目录所在的磁盘至少留 3 到 5 倍日常余量或者干脆单独挂一块盘。5.4 冷热分层与检索方案180 天的留存如果全放本地 SSD成本不低。我一般做三层时间范围存储位置检索方式成本0 到 30 天本地盘不压缩或轻压缩grep / 导入表查询高31 到 90 天本地盘gzip 压缩zgrep / 批量导入分析库中91 到 180 天对象存储标准或低频层按需拉取恢复低检索这块短周期内 grep 配合 zgrep 就够用zgrep -h AUDIT: /data/pglog/postgresql-2026-*.csv.gz \ | awk -F, $6 app_user {print} \ | head -50但要注意 CSV 里字段本身可能含逗号awk 按逗号切会错位。稳妥做法还是导进表用 SQL 查。如果是长期方案建议把审计日志送到集中日志平台做统一采集和检索本地只做缓冲这样既解决了防腐问题——日志实时外发之后本地被删也留了一份也解决了跨节点检索的问题。6. 性能影响与灰度控制手段6.1 实测数据不同配置的代价性能数据必须自己测我只给一组我们压测环境的结果做参考。环境是 8 核 16 GB、SSD、PostgreSQL 16pgbench 用 tpcb-like 模型32 并发跑 5 分钟配置TPS平均延迟每小时日志量基线不开语句日志86203.71 ms约 40 MBlog_statement ddl85603.74 ms约 46 MBpgaudit.log write, ddl, role79104.08 ms约 1.9 GBlog_statement all62805.23 ms约 6.4 GBpgaudit 行级触发器含大字段41507.9 ms约 11 GB结论很清楚只开 DDL 基本无感pgAudit 写审计的代价在 8% 左右完全在可接受范围全量语句日志掉 27%行级审计加重后掉到一半。这些数字和硬件、语句长度强相关你的环境可能差一倍但相对趋势是稳定的。6.2 采样性能不够时的折中如果实测下来性能压力确实大PostgreSQL 提供了采样机制12 起log_statement_sample_rate控制按比例记录语句log_min_duration_sample控制超过阈值才纳入采样池。比如log_min_duration_statement 500 log_min_duration_sample 20 log_statement_sample_rate 0.1意思是超过 500 ms 的全部记录超过 20 ms 的按 10% 采样。这样既能保住慢查询的完整证据链又能大幅降低日志量。但采样在审计场景下要慎重因为审计的核心诉求是完整性采样就意味着 90% 的操作查不到。我的原则是运行诊断可以采样合规审计不采样。如果审计侧压力大去找别的地方省比如关掉pgaudit.log_catalog、缩小审计类别、把日志写盘跟数据盘分开、用更快的盘。6.3 三个具体的性能控制手段把审计日志写到独立磁盘。log_directory支持绝对路径指到另一块盘上日志的顺序写和业务的随机写就不会互相抢 IO。log_directory /data/audit_log控制 syslogger 的背压风险。日志最终由 syslogger 进程落盘如果日志量超过了它的处理能力缓冲区写满之后后端进程会阻塞在写日志这一步——表现出来是业务 SQL 突然集体变慢而且是间歇性的很难定位。缓解方向有三个降低日志量关log_catalog、缩小类别、提高落盘速度换 SSD、目录独立、缩短单条记录长度不开log_parameter、不开log_relation。会话级开关做灰度。不要一次性全库打开。先在预发环境跑一周把日志量统计出来生产上先对单个业务库开观察一天确认无异常再推开。会话级的临时开关在排查时也好用SET LOCAL pgaudit.log all; -- 或者只针对当前事务关掉 SET LOCAL pgaudit.log none;SET LOCAL的作用域是当前事务事务结束自动失效比SET安全得多不会因为忘记恢复而留下长期裸奔的会话。7. 常见问题与排查实录7.1 装了 pgaudit 却一条日志都没有这是最高频的问题我按检查顺序列一遍。第一确认pg_available_extensions里能看到 pgaudit看不到就是包没装对。第二确认shared_preload_libraries生效用这条查SELECT name, setting, source, pending_restart FROM pg_settings WHERE name shared_preload_libraries;pending_restart是true说明改了配置但没重启pgAudit 必须重启才能生效reload 一律无效。第三确认pgaudit.log不是默认的noneSELECT current_setting(pgaudit.log);第四也是很多人卡住的地方——pgaudit.log_client默认off意思是审计记录只写服务器日志不返回给客户端。如果你在 psql 里执行操作后盯着屏幕等日志出现那是永远等不到的。临时打开它可以在客户端看到SET pgaudit.log_client on;排查完记得关掉。7.2 配置改了不生效这个坑的根源是 PostgreSQL 有多个配置文件。用SHOW config_file;和SHOW hba_file;看清实际路径。另外ALTER SYSTEM写的是postgresql.auto.conf它的优先级高于postgresql.conf如果你在postgresql.conf里改了pgaudit.log但之前用ALTER SYSTEM设过前者会被覆盖。SELECT name, setting, source, sourcefile, sourceline FROM pg_settings WHERE name LIKE pgaudit% OR name LIKE log_%;sourcefile和sourceline会告诉你这个值最终是从哪个文件哪一行来的这比盲猜快得多。7.3 日志时间比业务时间差 8 小时日志时间戳用的是log_timezone和timezone是两个独立参数。默认log_timezone GMT所以如果服务器在 UTC8你会发现日志时间比北京时间早 8 小时审计人员一看就懵。log_timezone Asia/Shanghai改完 reload 就生效。改之前产生的日志还是老时区分析历史数据时得手工换算这个要在交接文档里写清楚否则后面追溯会算错时间。7.4 日志把磁盘写满了怎么应急先降量再清理顺序不能反。降量用 reload 生效最快ALTER SYSTEM SET log_statement none; ALTER SYSTEM SET pgaudit.log none; SELECT pg_reload_conf();然后清理。别用rm删正在写的文件会导致句柄悬空。删已轮转的历史文件用find按时间过滤。清完之后立刻复盘是日志量估算错了还是某个批量任务突然放量还是外部清理脚本挂了。第三种最常见我现在的做法是给清理脚本配一个独立的监控告警——脚本超过 48 小时没成功执行就报警这比等磁盘满了再处理强太多。7.5 审计日志被业务账号读到了审计日志里往往包含敏感数据权限必须收紧。日志目录权限设成0700属主是数据库进程用户不要把日志目录挂到 Web 可访问路径下用 NFS 做集中存储时注意挂载权限no_root_squash这种配置会让其他机器上的 root 直接读到。另外一个容易忽略的点pg_read_file和pg_ls_dir这类函数是超级用户才能用的但如果你的应用账号被误授了超级用户权限那就全泄了。所以审计日志安全和数据库权限管理是同一件事不能用它替代后者。7.6 连接池把审计信息搞失真了这个坑比较隐蔽。用了 PgBouncer 的事务级连接池之后数据库看到的一直是连接池的账号session_user永远不变application_name也可能被复用审计日志里所有人的操作都挂在同一个身份下完全没有追溯价值。解决办法有两个。一是让应用通过application_name传递真实身份在连接参数里带上业务标识二是让应用在每个事务开头执行一次身份标记SET LOCAL application_name order-svc:user_88213;SET LOCAL的作用域是当前事务不会污染连接池里的其他使用者。这个改动对应用侵入很小但审计质量提升非常明显。7.7 问题速查表现象最可能的原因处理方式完全没有 AUDIT 行pgaudit.log为 none或 preload 未重启查pg_settings的 source 和 pending_restart只有连接日志没语句日志log_statement为 none 且未开 pgaudit二选一开启日志文件不更新被外部工具重命名句柄悬空改回 PG 自带轮转外部只压缩删除日志量远超估算log_catalog或log_relation开着关掉这两个缩小审计类别审计里用户名都一样连接池复用会话用 application_name 传递身份时间戳差 8 小时log_timezone为 GMT改成 Asia/Shanghai 后 reload批量任务后磁盘暴涨行级触发器放大检查是否有大字段未排除8. 一套可以直接抄的落地配置8.1 单机生产环境的标准配置把前面的内容串起来这是我目前用得最顺的一套配置# ---------- 日志基础 ---------- logging_collector on log_destination csvlog log_directory /data/audit_log log_filename postgresql-%Y-%m-%d_%H%M%S.csv log_rotation_age 1d log_rotation_size 200MB log_truncate_on_rotation on log_file_mode 0600 log_timezone Asia/Shanghai # ---------- 连接审计 ---------- log_connections on log_disconnections on log_hostname off # ---------- 语句日志轻量兜底 ---------- log_statement ddl log_min_duration_statement 1000 log_min_error_statement error log_error_verbosity default log_parameter_max_length 0 # ---------- pgaudit ---------- shared_preload_libraries pgaudit pgaudit.log write, ddl, role pgaudit.log_catalog off pgaudit.log_parameter off pgaudit.log_relation off pgaudit.log_client off pgaudit.log_level log几个参数值得单独说。log_file_mode 0600保证只有数据库用户能读日志。log_parameter_max_length 0表示不在慢查询 DETAIL 里输出绑定参数值这是防敏感数据泄露的关键一条——如果排查需要临时改成1024再改回来。log_error_verbosity保持defaultverbose会输出源码位置等调试信息对审计没用还占空间。8.2 主从与集群环境要注意什么集群环境下pgAudit 需要在每个节点都配一遍包括shared_preload_libraries和各类审计参数。因为审计是各节点独立落盘的从库上执行的操作只读查询只有在从库上也装了 pgaudit 才记录得到。实际部署时我建议把审计相关配置抽成独立的conf.d/audit.conf用include_dir引入这样主从两边的配置管理能统一避免手工同步出错。日志采集侧要在log_line_prefix或者采集 agent 的标签里带上节点标识主机名或角色否则多个节点的日志汇总到一起之后分不清来源。还有个容易忽略的点是主备切换。切换之后原来的从库升主如果它的log_directory指向的挂载点没准备好日志就写不进去了。这个要在切换演练里覆盖到。8.3 容器环境下的三个差异Docker 里跑 PostgreSQL 有几个默认行为不一样。官方镜像默认logging_collector off、log_destination stderr日志交给容器运行时收集docker logs能看到但日志文件在容器里不落盘容器一删就没了完全谈不上 180 天留存。要改造的话用启动参数覆盖services: postgres: image: postgres:16 command: - postgres - -c - logging_collectoron - -c - log_destinationcsvlog - -c - log_directory/var/lib/postgresql/audit - -c - shared_preload_librariespgaudit volumes: - ./data:/var/lib/postgresql/data - ./audit:/var/lib/postgresql/audit environment: TZ: Asia/Shanghai第二个差异是时区。容器默认 UTC日志时间会对不上一定要显式设TZ同时配置里的log_timezone也要改两个都改才不会出问题。第三个差异是shared_preload_libraries需要重启容器才生效docker restart或者docker compose up -d --force-recreate别指望 reload。另外自定义镜像编译 pgaudit 的时候记得在构建阶段装postgresql-server-dev-16和build-essential运行阶段可以删掉不然镜像会大很多。8.4 上线前的检查清单按这个顺序走一遍能挡掉九成的问题SHOW shared_preload_libraries;确认包含 pgauditpending_restart为 false。SELECT current_setting(pgaudit.log);确认不是 none。手工执行一条UPDATE和一条CREATE TABLE确认日志里有对应的 AUDIT 行。检查日志目录权限是 0700、属主是数据库进程用户。确认磁盘余量能撑住峰值至少留 3 倍余量。跑一遍清理脚本确认它只碰已压缩的历史文件。用SELECT pg_reload_conf();测一次配置重载确认不报错。模拟一次批量更新观察日志量峰值和业务延迟变化。最后再分享一个我在多个环境里都用过的小技巧给审计日志目录单独做一个磁盘水位监控阈值设在 70%不要等到 85% 才告警。因为审计日志的清理有滞后性要压要删要等 cron70% 的时候你有充足时间从容处理85% 的时候通常就只剩紧急降量加手动删这一条路了。我在一个客户那里就是因为阈值设得晚某个月底批量任务放量日志盘三小时从 60% 冲到 97%业务直接报错那次之后所有环境都改成了 70% 预警。