解读

面试官通过对比两种日志，考察候选人对 CouchDB 内部诊断体系与合规审计体系的边界认知。_log 是节点运行时的“黑匣子”，侧重排障；audit_log 是安全合规的“证据链”，侧重追溯。两者在写入格式、字段规范、切割触发条件、保留周期上完全不同，混用会导致要么磁盘爆掉，要么审计缺失。国内金融、政务云项目招投标时，等保 2.0 明确要求审计日志必须独立存储、不可改写，因此必须答出“audit_log 支持不可变存储与外部 syslog 转发”这一刚性差异。

知识点

1. 存储格式

   • _log：纯文本，每行一条，字段顺序固定：
     [<Level>] [<Timestamp>] [<NodeName>] [<Module>] [<PID>] [<Msg>]
     时间戳为本地时区，无结构化字段，可直接 tail -f。
   • audit_log：JSON Lines，单条对象包含：
     {timestamp, user, db, doc_id, operation, result, peer_ip, session_id, …}
     时间戳强制UTC+0、ISO8601 格式，字段由audit_log_event 白名单控制，可扩展自定义字段，方便 ELK/ClickHouse 直接解析。

2. 轮转策略

   • _log：
     – 由 log/file 与 log/max_chunk_size 控制，按体积轮转，默认 100 MB；
     – 保留份数由 log/max_files，默认 10 份，循环覆盖；
     – 文件名 couchdb.log.N，不压缩，重启不强制 rotate。
   • audit_log：
     – 由 [audit] 段独立配置，支持按时间轮转（daily、hourly）或按体积轮转，可混合触发；
     – 保留策略支持按天数（audit_log_retention_days）或按份数（audit_log_max_files），超出后自动 gzip 压缩；
     – 文件名 audit-YYYY-MM-DD-HH.json[.gz]，永不覆盖，可配置只读文件系统挂载实现 WORM（一次写入多次读取），满足等保要求；
     – 支持实时推送 rsyslog，本地文件可设成零保留，降低本地磁盘占用。

3. 权限与隔离

   • _log：文件属主 couchdb:couchdb，权限 640，管理员可读；
   • audit_log：默认 600，仅 couchdb 用户可写，可配置 audit_log_group 让审计组只读，防止篡改。

答案

“_log”是运行日志，采用纯文本格式，字段为固定顺序的本地时间戳字符串，通过体积阈值循环轮转，默认保留 10 个 100 MB 文件，不压缩、可覆盖，主要用于排障。
“audit_log”是审计日志，采用JSON Lines格式，时间戳强制 UTC，字段完整描述用户行为与结果，支持时间+体积双维度轮转，保留周期可精确到天数，超出后自动 gzip 并禁止覆盖，还能同步到外部 syslog，满足国内等保 2.0 对审计数据不可篡改、独立存储的合规要求。两者在格式结构化程度、轮转触发条件、保留策略、压缩与防篡改机制上存在本质差异，线上环境必须分开挂载磁盘，避免相互影响。

拓展思考

1. 国内大型银行往往要求审计日志保存 7 年以上，CouchDB 原生 gzip 轮转后仍占用巨大空间，可结合 CouchDB 3.3 的 audit_log_filter 插件，只记录写操作（create/update/delete），把读操作直接丢弃，磁盘占用可降 70%。
2. 如果集群部署在 Kubernetes，可将 audit_log 目录挂成 hostPath + initContainer 设置 immutable bit，实现容器重建后日志依旧只读；同时用 Vector/Fluent-bit sidecar 实时转发到 Kafka，供风控系统秒级审计。
3. 面试加分点：提到 _log 也能通过 logger 模块动态调整级别，但审计日志一旦开启就无法动态关闭，这是为了防止管理员“抹痕迹”，体现 CouchDB 对**职责分离（SoD）**的设计思路。