Healthchecks.io 自托管版性能优化实践：解决高负载下的 Ping 日志查询问题

问题背景

在使用自托管版 Healthchecks.io 监控系统时，当将 ping 日志限制提高到 40,000 条后，系统开始出现严重的性能问题。主要表现为：

1. 包含大量 ping 记录的检查项加载缓慢甚至无法加载
2. 容器日志中出现 harakiri 错误（进程超时被终止）
3. 特定路由如 /checks/{check_id}/last_ping/ 和 /checks/{check_id}/log_events/ 响应时间过长

根本原因分析

经过深入排查，发现问题主要由以下几个因素导致：

1. 大数据量查询：当单个检查项的 ping 记录达到 40,000 条时，数据库查询变得非常耗时
2. 大请求体存储：部分 ping 请求体达到 50MB，远超过常规大小
3. 索引缺失：原始数据库表结构在某些查询场景下缺乏合适的索引
4. 内存限制：数据库缓冲池大小不足，无法有效缓存大量数据

优化方案

1. 数据库索引优化

针对慢查询添加了以下复合索引：

• api_ping.owner_id + api_ping.created：优化 /checks/{check_id}/last_ping/ 路由
• api_ping.kind + api_ping.n + api_ping.created：优化状态和日志事件查询
• owner_id + n DESC + created：进一步优化日志事件分页查询

这些索引显著减少了查询时间，从超时状态降低到可接受范围。

2. 请求体大小限制

对于包含大请求体的场景：

• 建议将 PING_BODY_LIMIT 从 100MB 降低到更合理的 1MB
• 考虑启用对象存储功能，将大请求体存储在 S3 等外部存储中，减轻数据库压力

3. 查询优化

开发团队实施了以下查询优化：

• 对于日志显示页面，只加载 ping 体的前 150 字节（UI 仅显示约 100 个字符）
• 避免不必要的大数据加载，减少网络传输和内存占用

4. 数据库配置调整

增加 MariaDB/MySQL 的缓冲池大小：

innodb_buffer_pool_size = 8G

这一调整显著提高了大表查询的性能。

5. 前端超时调整

虽然不建议作为长期解决方案，但可以临时调整前端 JavaScript 的刷新间隔：

• 默认每 3 秒刷新一次日志
• 可通过修改 adaptive-setinterval.js 中的参数延长间隔

实施建议

对于面临类似问题的管理员，建议按照以下步骤进行优化：

1. 首先分析慢查询，使用工具如 django-debug-toolbar 识别瓶颈
2. 添加适当的复合索引，特别注意 WHERE 条件和 ORDER BY 子句中使用的字段
3. 评估并限制最大 ping 体大小
4. 考虑启用对象存储功能
5. 根据服务器资源调整数据库内存配置
6. 最后考虑前端超时调整（仅作为临时措施）

总结

通过合理的数据库索引、查询优化和配置调整，Healthchecks.io 自托管版可以支持包含数万条 ping 记录的大规模监控场景。关键在于识别性能瓶颈，有针对性地进行优化，并在系统设计和配置上做出合理限制。对于特别大的监控负载，建议考虑分布式部署或专业级数据库解决方案。