---
url: /v6.2/export-screenshot-log-faq.md
---
# 导出、截图与日志

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

## 应用集市导出数据或 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. 系统调试日志或导出的服务器端历史日志

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

进一步阅读：

* [系统调试](debug-log.md)
* [运行日志清理](clean-log.md)
* [应用发布](app-publish.md)