Export, Screenshot, and Log

Export, screenshot, and log issues often look like one class of problem, but the real causes are usually spread across proxy timeouts, rendering resources, log-database configuration, and debug-method choice. This page separates those paths first.

If app-market export or PDF export shows Gateway Time-out, where should I check first?

Start with the proxy timeout layer, not with the export feature itself.

If there is an Nginx-style proxy in front, check:

• proxy_connect_timeout
• proxy_send_timeout
• proxy_read_timeout
• send_timeout

If the timeout shown in the page matches the timeout configured in the proxy, the proxy is usually the layer cutting the request off first.

What if proxy timeout is already increased but export still times out early?

Then do not stare only at Nginx.

Other common causes include:

• WAF or security appliances with shorter timeout policies
• upstream gateways or load balancers with independent timeout limits
• intermediate network layers cutting long-running requests

In other words, page-export timeout does not necessarily mean HENGSHI timed out first. Any layer in the chain may have dropped the request.

If log export fails with Connections could not be accquired from the underlying database, what does it usually mean?

The common reason is: the log database configuration is wrong, not necessarily metadb.

Check first:

• conf/hengshi-sense-env.sh
• the HS_SYSLOG_* settings
• whether the configured user, password, and database permissions are truly reachable

This is even more common when the log database is configured separately from metadb.

When should I use realtime debug export versus historical log export?

Choose by timing:

Scenario	Better fit
You are about to reproduce a problem and want logs from now onward	Realtime debug export
The issue already happened and you need logs for a past time range	Historical log export

If you are troubleshooting a newly occurring issue, set the debug level and duration first, then reproduce it.

Why did realtime debug fail to capture the log I wanted?

The most common reasons are not that the system failed to log anything, but that the log level was never set correctly before enabling realtime debug, or realtime debug was exited too early.

A better order:

1. configure module log levels first
2. enable realtime debug
3. reproduce the issue
4. export immediately

If realtime debug is already exited, you can only fall back to historical logs if the time window was captured.

Is more logging always better?

No.

DEBUG and TRACE are better for troubleshooting, but they also:

• increase log volume
• consume more storage
• make investigation noisier

The better pattern is: enable high log levels briefly during troubleshooting, then turn them back down and clean logs regularly.

Why does system log cleanup matter so much?

Because the system continuously generates logs at runtime. Without cleanup, storage grows and can affect runtime behavior.

The system supports:

• scheduled automatic cleanup
• manual cleanup

The key is not only whether the feature exists, but whether your team has a real retention policy for how many days of logs must be kept.

What should I collect first when troubleshooting export, screenshot, or log issues?

Usually these three:

1. the exact browser-side error time and message
2. whether the proxy/gateway layer shows timeouts or interceptions
3. system-debug logs or exported historical server logs

Without those artifacts, many "it cannot export" cases end up bouncing pointlessly between product, network, and database teams.

Further reading:

• System Debug
• Runtime Log Cleanup
• App Publish