GBase 8c 审计和日志，别等磁盘打满了再回头补

我最近看 GBase 8c 这块资料时，一个感受越来越明显：很多团队其实不是没有日志，也不是没有审计，而是这些东西一开始开得很随意，后面又没人持续治理。结果往往很典型——要么出了问题找不到关键证据，要么日志越堆越多，最后先把磁盘吃紧；更麻烦一点的场景，是为了“查问题”一下子把审计和慢 SQL 跟踪全开，线上先被日志量和额外开销反过来拖慢。

我自己理解下来，GBase 8c 的日志、慢 SQL 跟踪、审计，这三块最好别混着看。它们都能帮助排障，但解决的是不同层面的问题：

• 运行日志 更偏实例运行、异常、工具操作和故障定位。
• 慢 SQL / Full SQL 跟踪 更偏性能观察和历史回溯。
• 审计日志 更偏安全、对象操作、DML 行为和责任追踪。

真正落到现场时，我更关注的不是“要不要开”，而是下面这几个更实际的问题：

1. 现在到底要解决性能追踪，还是安全留痕。
2. 哪些项应该长期打开，哪些项只适合短期开。
3. 日志和审计文件怎么控量，避免查问题时把系统再拖慢一遍。

很多数据库现场最后变乱，不是因为没能力，而是因为没有把“采集、保留、查询、清理”当成一条完整链路去设计。

我一般先把日志类问题分成这几类

现场现象	我优先怀疑的点	第一动作
想查谁改了对象、谁做了 DML，但没有证据	审计项没提前开，或者开得不对	先看 audit_enabled 和具体审计项
慢 SQL 能感觉到，但历史不好追	慢 SQL 跟踪未开启或保留时间太短	看 enable_stmt_track、log_min_duration_statement
节点磁盘突然变紧	审计/日志清理策略不完整	先看目录占用和保留参数
只知道系统慢，不知道慢在哪个时间段	Full SQL / Slow SQL 没留够	先查 dbe_perf 视图和保留窗口
开了很多日志后系统反而更重	采集粒度过高、保留时间过长	先做分层治理，不要一把梭

从落地角度看，我更倾向于先把“性能日志”和“安全审计”拆开治理。因为这两类东西虽然都叫日志，但目标完全不一样。

一、先把这三类能力分清楚，不然后面很容易开错

我最近整理下来觉得，GBase 8c 现场里最容易混淆的，就是审计、慢 SQL 跟踪、普通运行日志。

1）运行日志更适合看实例和系统问题

GBase 8c 管理文档里把日志分成了系统日志、操作日志、Trace 日志、黑匣子日志、审计日志、WAL 日志、性能日志等几类。这个分类本身就很有用，因为它提醒我们：不是所有问题都要去翻同一种日志。系统运行异常、工具执行轨迹、性能外部资源访问、本来就不是一层问题。 我自己做排障时，如果是“节点异常、实例报错、工具改过参数、OM 操作历史”这类事，通常先看运行日志和工具日志，不会一上来先查审计。路径上也会先从实例运行目录、工具日志目录、性能日志目录这几类地方下手。部署方式不同目录会有差异，但按官方文档和社区常见场景，数据库节点运行日志、工具日志、性能日志、审计目录本身都是分层管理的。

2）慢 SQL 跟踪更适合做性能回看

慢日志这块，我个人更愿意把它理解成“性能观察窗”。它不一定帮你回答“谁干了这件事”，但很适合回答“什么时间开始慢、慢了多久、那段时间有哪些 SQL 最可疑”。

GBase 8c 社区里关于慢日志配置的内容已经把相关参数拆得很细了，比如：

• enable_stmt_track
• track_stmt_stat_level
• log_min_duration_statement
• instr_unique_sql_count
• track_stmt_details_size
• track_stmt_retention_time

这里我比较认同的一点是：慢 SQL 跟踪不只是一个阈值参数，而是一整套采集粒度 + 记录数量 + 保留窗口的组合。

3）审计更适合做责任留痕和行为回放

审计功能这块，GBase 8c 支持总开关和分项开关。也就是说，不是只有“开”和“关”两种粗粒度状态，而是可以按登录注销、对象操作、权限授予回收、DML、SELECT、函数执行、事务信息等项细分。 我自己理解下来，这就决定了审计不应该默认全量粗暴打开，而应该结合业务场景做有边界的配置。

二、我更习惯把日志治理拆成“长期常开”和“短期临时”两层

这个点我个人比较在意。很多团队一开始为了怕漏信息，把一堆能力全开，结果后面维护成本很高；还有一些团队相反，平时啥都不开，等出问题了再去补，最后发现关键窗口已经过去了。

所以我现在更倾向于这样拆：

层次	更适合长期常开	更适合短期开启
运行日志	实例日志、工具日志、基础告警相关日志	Trace、黑匣子增强信息
慢 SQL 跟踪	温和阈值的慢 SQL 记录	全量 SQL、较细粒度跟踪
审计	登录注销、权限变更、关键对象操作	指定表 DML、SELECT 审计、指定用户全量审计

这种拆法的好处很实际：

• 平时就有基础证据，不至于完全盲排。
• 真遇到问题时，可以再把粒度临时加细。
• 不至于把审计和 Full SQL 长期开到过重。

三、审计这块，我通常不会上来就全开

GBase 8c 的审计相关参数里，我最常关注的是下面这些：

参数	我更关心它解决什么问题	我一般怎么理解
audit_enabled	审计总开关	先确认总开关是否生效
audit_login_logout	登录、退出留痕	建议长期保留
audit_database_process	数据库启动、停止、恢复、切换	运维排障价值高
audit_grant_revoke	授权和回收权限	权限变更必须能追
audit_system_object	CREATE / ALTER / DROP 等对象操作	对象治理很关键
audit_dml_state	指定表 DML 审计	不建议无边界乱开
audit_dml_state_select	SELECT 审计	更要控制范围
full_audit_users	指定用户全量审计	更适合短期定位
no_audit_client	不纳入审计的客户端/IP	排除噪音用
audit_xid_info	在审计中记录事务信息	对串联事务排查有帮助

我自己更倾向于这样一套思路：

• 基础安全留痕长期保留：登录注销、权限授予回收、数据库进程事件、关键对象变更。
• 业务行为审计按需打开：某张表被误改、某个账号操作异常、某段时间需要追责，再开更细的 DML / SELECT。
• 指定用户全量审计只做短期定位：别把它当常态。

一个我更常用的查看方式

先看总开关和关键分项：

show audit_enabled;
show audit_login_logout;
show audit_database_process;
show audit_grant_revoke;
show audit_system_object;
show audit_dml_state;
show audit_dml_state_select;
show full_audit_users;
show no_audit_client;
show audit_xid_info;
show audit_directory;

如果只是临时追某类对象变更，我一般会先做相对克制的配置，而不是全开：

gs_guc reload -N all -I all -c "audit_enabled = on"
gs_guc reload -N all -I all -c "audit_system_object = 67121159"
gs_guc reload -N all -I all -c "audit_grant_revoke = 1"
gs_guc reload -N all -I all -c "audit_dml_state = 1"

这里要特别注意一点：开启 DML 或 SELECT 审计，不等于应该长期开着。 真正落地时，这种参数更适合在明确目标对象、明确时间窗口的前提下使用。

四、慢 SQL 和 Full SQL 这块，最怕的不是没开，而是开得没边界

GBase 8c 社区对慢日志参数已经给过比较清楚的配置思路。我自己现在处理这块，通常先不纠结“要不要抓”，而是先问：

1. 抓的是慢 SQL，还是全量 SQL。
2. 只抓概况，还是要更细粒度。
3. 想保留多久。
4. 允许系统里累计多少 unique SQL 条目。

下面这几个参数，是我更常盯的：

参数	作用	我更在意的点
enable_stmt_track	是否启用 Full/Slow SQL 捕获	总开关，先看它
track_stmt_stat_level	控制全量和慢 SQL 跟踪级别	粒度不要无脑拉满
log_min_duration_statement	慢 SQL 阈值	先用能反映业务体感的阈值
instr_unique_sql_count	unique SQL 条目数量控制	防止记录膨胀
track_stmt_details_size	单条 SQL 记录大小	超长 SQL 现场很重要
track_stmt_retention_time	Full / Slow SQL 保留时间	直接关系追溯窗口

我自己更愿意用“分层采集”这个思路：

场景	我更倾向的配置
日常观察	开启慢 SQL 跟踪，阈值相对温和
问题复现窗口	保持慢 SQL，适度拉长保留时间
重大性能排障	临时打开 Full SQL 或更高粒度
业务高峰期	控制保留窗口和唯一 SQL 数量，别把采集本身变成负担

一个相对常见、也比较容易落地的配置示意可以写成这样：

gs_guc reload -Z coordinator -N all -I all -c "enable_stmt_track = ON"
gs_guc reload -Z coordinator -N all -I all -c "track_stmt_stat_level = 'OFF,L0'"
gs_guc reload -Z coordinator -N all -I all -c "log_min_duration_statement = 1000"
gs_guc reload -Z coordinator -N all -I all -c "instr_unique_sql_count = 200000"
gs_guc reload -Z coordinator -N all -I all -c "track_stmt_retention_time = '3600,10800'"

这里我自己有个习惯： 先开慢 SQL，再决定要不要补 Full SQL。 因为慢 SQL 主要解决“先找到嫌疑对象”，Full SQL 解决的是“把窗口里所有语句都捞出来看”。两个层次不一样，没必要长期混用。

五、查询手段也要分层，不然日志明明开了也不好用

光开参数还不够，真正落地时，能不能方便查出来更关键。

1）查审计记录

如果要回看某个时间段的审计动作，我一般先用：

select *
from pg_query_audit('2026-04-01 09:00:00','2026-04-01 11:00:00');

如果已经知道自己要找的是 DML 或对象操作，我通常会再加过滤条件，不然结果太散：

select time,
       username,
       database,
       type,
       result,
       detail_info
from pg_query_audit('2026-04-01 09:00:00','2026-04-01 11:00:00')
where type in ('dml_action', 'dml_action_select')
  and detail_info like '%orders_fact%';

2）查慢 SQL 和全量 SQL

这部分我更常用 dbe_perf 相关视图：

select *
from dbe_perf.get_global_slow_sql_by_timestamp(
  '2026-04-01 09:00:00'::timestamp with time zone,
  '2026-04-01 10:00:00'::timestamp with time zone
);

如果现场需要看某个窗口的完整 SQL 历史，再去查全量：

select *
from dbe_perf.get_global_full_sql_by_timestamp(
  '2026-04-01 09:00:00'::timestamp with time zone,
  '2026-04-01 09:10:00'::timestamp with time zone
);

3）查目录和文件占用

只靠数据库视图还不够。日志治理最后一定会回到 OS 层面，所以我排查时通常也会顺手看目录占用：

du -sh /var/log/gbase/gbase/pg_log
du -sh /var/log/gaussdb/gbase/pg_audit

find /var/log/gaussdb/gbase/pg_audit -type f | wc -l
ls -lh /var/log/gbase/gbase/pg_log | tail

如果是 gs_om 方式部署，审计日志目录在社区资料里有比较明确的说明；但我自己的建议是，不要死记路径，先 show audit_directory，再去落 OS 路径验证，这样更稳。

六、日志留得住不等于治理到位，真正麻烦的是控量

我最近整理这块内容时，越来越觉得“会开”和“会管”其实是两回事。很多现场不是不会开日志，而是不会做保留策略。

审计日志这块，社区文章里提到的几个参数我觉得特别实用：

参数	我更关注的点	默认值信息
audit_directory	审计文件存储目录	社区文中给出默认目录
audit_resource_policy	使用空间策略还是其他策略	默认是 on
audit_space_limit	审计文件总空间上限	1GB
audit_file_remain_time	最小保留时间	90
audit_file_remain_threshold	最大文件数量上限	1048576

这个地方我个人更在意的不是“默认值是多少”，而是默认值是否适合你现场。 比如：

• 审计开得比较细，但磁盘本来就紧，那 audit_space_limit 就不能继续放默认思路。
• 现场合规要求高，需要更长留存期，那就不能只看空间，不看保留时间。
• 某些环境 SQL 特别碎，慢 SQL 与审计一起开，文件数量上涨会很快，这时文件数量阈值和清理频率就很关键。

我更习惯的一套治理思路

治理目标	更合适的动作
怕磁盘被打满	先收紧保留窗口和空间上限
怕事后追不回来	给关键项保留更长时间，不是所有项都一视同仁
怕日志太碎不好查	统一时间窗口、统一归档策略
怕线上受影响	临时增强采集，问题结束后回退

配套的归档动作，我一般会建议运维侧至少有这种最基础的脚本思路：

#!/bin/bash
set -e

AUDIT_DIR="/var/log/gaussdb/gbase/pg_audit"
ARCHIVE_DIR="/data/archive/pg_audit/$(date +%F)"

mkdir -p "${ARCHIVE_DIR}"

find "${AUDIT_DIR}" -type f -mtime +7 -name "*.log" -print0 | \
xargs -0 -I {} mv {} "${ARCHIVE_DIR}/"

tar -czf "${ARCHIVE_DIR}.tar.gz" -C "$(dirname "${ARCHIVE_DIR}")" "$(basename "${ARCHIVE_DIR}")"

这个脚本本身不复杂，但它能说明一个问题： 日志治理最终一定会落回“清理、归档、保留、复查”这些运维动作上。

七、我自己比较容易提醒团队的几个坑

1）把审计当成性能分析工具来用

审计能帮你追责和回放，但它不是纯粹的性能画像工具。性能问题优先看慢 SQL、Full SQL、执行计划和实例日志，别所有问题都先查审计。

2）把 SELECT 审计和 DML 审计长期粗暴打开

这类开关在定位问题时很好用，但长期无边界启用，代价通常不小。我更倾向于按表、按用户、按时间段使用。

3）只会开，不会收

很多现场出了问题先开一堆参数，问题过去了却不回退。过一阵子系统变重、磁盘变紧，又开始怀疑业务量。真正根因其实是采集策略没收回来。

4）只看数据库，不看 OS 层目录

数据库视图能帮你查记录，但磁盘占用、目录文件数、归档是否执行，还是要回到 OS 层检查。

5）把所有日志都留一样久

从治理角度看，这种做法最省事，但通常不是最优。登录注销、权限变更、对象变更、慢 SQL、全量 SQL，本来就不该完全同一套保留策略。

八、我现在更认可的一套落地顺序

如果让我现在给 GBase 8c 做一套更稳一点的日志与审计治理，我通常会按下面的顺序来：

1. 先定目标 是偏安全留痕，还是偏性能追踪，别混着开。
2. 再定长期常开项 登录注销、权限变更、关键对象操作、基础慢 SQL，优先做成长期能力。
3. 然后定短期增强项 指定表 DML、SELECT 审计、指定用户全量审计、Full SQL，更适合短期开启。
4. 再定保留和空间策略 空间上限、文件数量、最小保留时间、Full/Slow SQL 保留窗口，都要落具体值。
5. 最后补查询和归档动作 不只是“开了”，而是要能查、能归档、能回退、能复盘。

结尾收一下

我最近重新整理 GBase 8c 这块内容时，越来越觉得日志和审计这件事，最怕的不是没开，而是没有治理思路。平时全关，出事时全开，最后要么证据不够，要么系统又被采集本身拖慢，这两种情况我都见得不少。

从落地角度看，我个人更倾向于这样理解：

• 运行日志解决实例和系统问题；
• 慢 SQL / Full SQL 解决性能回看问题；
• 审计解决行为留痕和责任追踪问题；
• 保留、清理、归档，决定这套东西最后能不能长期用得住。

把这几层拆开以后，很多事情就没那么乱了。真正做得稳的环境，通常不是日志最多的环境，而是该留的留住、该收的收得回来、出了问题能在合理时间里把证据找出来的环境。

参考资料

[1] 南大通用GBase 8c审计功能简述
https://www.gbase.cn/community/post/4410

[2] GBase 8c维护审计日志（一）
https://www.gbase.cn/community/post/1964

[3] GBase 8c慢日志启用和查询
https://www.gbase.cn/community/post/3985

[4] 如何查看8c执行过的系统sql
https://www.gbase.cn/community/post/5544

[5] 日志参考
https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E6%8C%87%E5%8D%97/03%20%E8%BF%90%E7%BB%B4%E7%AE%A1%E7%90%86/%E6%97%A5%E5%BF%97%E5%8F%82%E8%80%83

[6] 管理数据库安全
https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E7%AE%A1%E7%90%86%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AE%89%E5%85%A8