导出、截图与日志

导出、截图、日志这三类问题经常表面看起来像一个问题，实际上分别可能卡在代理超时、渲染资源、日志库配置、调试方式选择等不同层面。这页先把高频排障路径理清楚。

应用集市导出数据或 PDF 时提示 Gateway Time-out，先查哪里？

先查代理层超时，不要一上来就怀疑导出功能本身坏了。

如果部署前面有 Nginx 之类的代理，优先检查：

• proxy_connect_timeout
• proxy_send_timeout
• proxy_read_timeout
• send_timeout

如果页面提示的超时时间和代理配置里的超时时间一致，通常就是代理先把请求掐掉了。

如果代理超时时间已经调大，导出还是提前 timeout 呢？

这时就不能只盯 Nginx 了。

高频原因还包括：

• WAF 或中间安全设备有更短的超时策略
• 上层网关或 LB 有独立超时限制
• 中间网络层把长请求截断

也就是说，“页面导出 timeout”不一定是 HENGSHI 本身先超时，链路里的任意一层都可能先断。

导出日志时报 Connections could not be accquired from the underlying database，通常意味着什么？

高频原因是：日志数据库配置有问题，并不一定是 metadb 有问题。

先检查：

• conf/hengshi-sense-env.sh
• 其中的 HS_SYSLOG_* 相关配置
• 对应用户名、密码、库权限是否真的可连通

如果你们把日志数据库和 metadb 分开配了，这类问题更常见。

实时调试导出和历史日志导出，应该用哪个？

按场景选：

场景	更适合
准备复现一个问题，希望从现在开始抓日志	实时调试导出
问题已经发生过，想回头导出某个时间段	历史日志导出

如果你是在排“刚刚发生的一次异常”，通常应该先把实时调试级别和时长设置好，再复现问题。

为什么开了实时调试，却导不出想要的日志？

最常见的原因不是系统没记，而是开启前日志级别没配好，或者太早退出了实时调试。

建议顺序：

1. 先设置各模块日志级别
2. 再开启实时调试
3. 复现问题
4. 立刻导出

如果你已经退出实时调试，再想补导，只能回头看历史日志里有没有对应时段。

日志是不是越多越好？

不是。

DEBUG / TRACE 虽然更利于排障，但也会：

• 增加日志量
• 占更多存储
• 拉高定位成本

所以更好的做法是：排障时短时间开启高等级日志，结束后及时关闭，并定期清理运行日志。

系统日志为什么还要专门清理？

因为系统运行时会持续产生大量日志，如果不清理，会占用大量存储并拖累运行。

系统支持：

• 每天定时自动清理
• 手动清理

关键不是“有没有清理功能”，而是你们要不要把“保留最近多少天日志”作为正式运维策略。

截图 / 导出 / 日志问题，排障时第一优先该收集什么？

通常先收集这三类信息：

1. 浏览器里具体报错时间和报错提示
2. 代理层 / 网关层是否有 timeout 或拦截记录
3. 系统调试日志或导出的服务器端历史日志

如果没有这些材料，很多“导不出来”类问题很容易在产品、网络、数据库之间来回甩锅。

进一步阅读：

• 系统调试
• 运行日志清理
• 应用发布