连接日志看似只是几行文本，却直接影响数据库审计、故障排查和连接池调优。PostgreSQL 18 为连接相关日志带来了更细粒度的控制，重点落在 log_connections、log_disconnections 和 log_hostname 这几个 GUC（Grand Unified Configuration）参数上。
这意味着管理员可以更明确地回答三个问题：谁建立了连接，谁断开了连接，以及日志里是否需要把客户端地址解析成主机名。
三个 GUC 分别负责什么
log_connections：记录连接建立
启用 log_connections 后，PostgreSQL 会在客户端连接建立阶段写入日志。它适合观察连接峰值、认证问题，以及连接池是否出现了异常的连接创建行为。
在使用 PgBouncer 或应用侧连接池时，这个参数尤其有价值：如果每个请求都创建新连接，日志通常会暴露出明显的连接 churn；如果连接池工作正常，连接建立次数应该远低于业务请求数。
log_disconnections：记录连接结束
log_disconnections 记录客户端断开连接的信息，并可以帮助定位连接生命周期过短、应用频繁重启或网络不稳定等问题。将它和 log_connections 配合使用，可以粗略还原某个连接的开始与结束。
长时间启用详细断连日志前，需要估算日志量。高并发系统中，连接数和日志写入量可能一起增长，日志轮转与保留策略不能缺席。
log_hostname：把地址解析为主机名
log_hostname 控制日志是否尝试记录客户端主机名，而不是只记录 IP 地址。主机名在多节点环境中更容易阅读，但反向 DNS 查询会带来额外开销，也可能让日志出现等待或解析失败的情况。
如果日志消费者依赖稳定、快速的字段解析，IP 地址通常更可预测。只有在 DNS 配置可靠、主机名确实有助于运维识别时，才值得开启这个选项。
PostgreSQL 18 的变化意味着什么
PostgreSQL 18 的重点不是让所有环境默认记录更多内容，而是提供更清晰的连接日志控制粒度。运维人员可以根据环境选择组合：
- 排查连接建立失败时，临时打开
log_connections。 - 分析连接泄漏或连接池行为时，同时打开
log_connections和log_disconnections。 - 需要按机器名称阅读日志时，再评估是否启用
log_hostname。 - 生产环境长期运行时，结合日志轮转、采集过滤和容量监控控制成本。
连接日志不能替代数据库审计。它主要描述连接生命周期，不能自动提供完整的业务操作上下文，也不应被当作记录 SQL 变更的唯一依据。
一个可复制的配置实践
下面的示例适合在测试环境中验证参数效果。把配置文件路径替换为实际实例路径；如果使用容器或托管 PostgreSQL，则应通过对应的参数配置入口修改。
# 查看当前值
psql -d appdb -c "SHOW log_connections;"
psql -d appdb -c "SHOW log_disconnections;"
psql -d appdb -c "SHOW log_hostname;"
# 测试环境：开启连接建立和断开日志
psql -d appdb -c "ALTER SYSTEM SET log_connections = on;"
psql -d appdb -c "ALTER SYSTEM SET log_disconnections = on;"
# 只有在 DNS 解析可靠且确实需要主机名时才开启
psql -d appdb -c "ALTER SYSTEM SET log_hostname = on;"
# 重新加载配置
psql -d appdb -c "SELECT pg_reload_conf();"
# 测试连接生命周期
psql -d appdb -c "SELECT current_user, inet_client_addr();"
运行前请确认执行命令的角色拥有修改系统配置所需的权限，并确认日志目录、采集器和轮转策略已经配置好。参数生效后，可以断开并重新建立一个客户端连接，再检查 PostgreSQL 日志。
如果要撤销测试配置，可以执行：
psql -d appdb -c "ALTER SYSTEM RESET log_connections;"
psql -d appdb -c "ALTER SYSTEM RESET log_disconnections;"
psql -d appdb -c "ALTER SYSTEM RESET log_hostname;"
psql -d appdb -c "SELECT pg_reload_conf();"
与连接池和日志平台配合
连接日志最容易产生误判的地方，是把数据库连接数等同于用户请求数。连接池会复用连接，而某些部署方式会让连接建立集中发生在应用发布、扩容或故障恢复阶段。因此，分析时应把日志时间线和以下指标放在一起：
- 应用实例数量与扩缩容事件。
- 连接池的创建数、活跃数和等待数。
- PostgreSQL 的
pg_stat_activity快照。 - 数据库日志写入量和磁盘使用率。
日志平台也应尽量保留结构化字段，例如时间、进程号、用户、数据库、客户端地址和连接事件类型。若只能消费文本日志，至少要固定日志格式，避免因为主机名解析或多语言环境导致下游解析规则不稳定。
上线前检查清单
- 明确启用连接日志要解决的具体问题。
- 先在测试环境验证参数和日志格式。
- 估算高峰期的日志增量，并检查轮转与保留策略。
- 判断
log_hostname的 DNS 开销是否可接受。 - 将连接日志和连接池、部署、网络指标关联分析。
- 排查结束后关闭不再需要的高频日志。
PostgreSQL 18 的细粒度连接日志适合做成一组按需启用的诊断开关，而不是永久打开的“万能审计”。把三个 GUC 的职责分开理解，再根据故障场景组合使用，才能在获得连接生命周期证据的同时控制性能和存储成本。