PGSQL Phriday #010：日志分析

PGSQL Phriday #010：日志分析

摘要：本文讨论了 PostgreSQL 日志分析方法，重点介绍了作者使用 SQL 和外部数据包装器（FDW）而非 pgBadger 的方法。虽然认可 pgBadger 是生产环境监控的有用工具，但作者解释了为什么在排查特定数据库问题时更倾向于使用基于 SQL 的灵活方法进行深入分析。

原文链接

日志设置

我一直建议客户在 PostgreSQL 日志记录方面要"贪婪"一些。获取的信息越多，对正在发生的事情的判断就越准确。

以下是我推荐的典型配置：

• log_destination：csv。你需要 CSV 格式提供的灵活性。此外，它会自动为你提供一行日志应该具备的所有元数据。
• • logging_collector：on。如果你想记录日志。对于 CSV 格式这是必需的。
• • log_min_duration_statement：对于 OLTP 工作负载，我推荐 250ms，但如果这会产生太多慢查询，就设置一个更高的值，解决最慢的查询，然后逐步降低这个参数。对于 OLAP 工作负载，该值可以在 1 到 5 秒之间。
• • log_autovacuum_min_duration：0。你想看到所有自动清理启动，不论其持续时间多长。
• • log_checkpoints：on。你想记录所有检查点。
• • log_connections：on。你想查看所有连接（或连接尝试）。
• • log_disconnections：on。如果没有连接池，这将有助于理解你的事务。即使使用连接池，我仍然建议将此参数设置为 on。
• • log_lock_waits：on。你想记录查询等待锁释放的情况。
• • log_temp_files：0。你希望所有临时文件能够对work_mem设置值进行良好的分析。

日志分析

那么，我是如何分析日志的，为什么 Badger 不能为我做这些？我通常的做法是使用 CSV 格式输出日志，并创建一个简单的 FDW（外部数据包装器）来查询日志，就像查询数据库中的表一样。

我首先做的事情与 Badger 相同：

• 统计日志中 PANIC、FATAL、ERROR 消息的数量
• 统计连接/断开连接的数量
• 检查检查点的频率
• ……

但是随后，我可以获取已识别工作负载峰值期间的相同指标。如果你想在 Badger 中做到这一点，你需要隔离要分析的文件部分，然后重新运行分析。而在这里，我只需调整 WHERE 条件即可。

此外，对于某些指标（如临时文件），我希望能获得更细粒度的信息。例如，我想知道临时文件使用情况的百分位数。如果发现某个查询使用了非常大的临时文件，我喜欢将它单独拿出来，对其他查询重新运行分析，以找到合适的work_mem值。

当我需要查看慢查询时，我也喜欢 SQL 提供的灵活性。使用 SQL 可以获得更高的精度。

Badger 作为生产环境的日志分析器

这就是我不使用 Badger 的原因。再说一遍，Badger 不是一个糟糕的工具，我鼓励每天在生产环境工作的人安装它并使用它进行离线分析，以获取实例整体运行情况的报告。此外，我鼓励生产环境的 DBA 关注他们获得的各个仪表板的演变。

如果你需要深入研究数据库中的某些特定活动，那么使用 SQL 吧，你将获得所需的所有灵活性！

标签：PGSQL Phriday PostgreSQL