[Bug] The log module cannot retrieve log files larger than 500MB

[uouuou]

Contact Information

No response

1Panel Version

2.0.2

Problem Description

/api/v2/files/read
{"code":500,"message":"服务内部错误: 日志文件超过 500M，无法打开","data":null}

Steps to Reproduce

--

The expected correct result

No response

Related log output

Additional Information

No response

[wanghe-fit2cloud]

感谢反馈。对于超过 500MB 的日志文件，直接读取确实会导致浏览器卡顿甚至崩溃，整体体验较差。
我们建议你创建网站日志切割类型的计划任务，将大文件按时间或大小进行拆分，既能提升查看效率，也更利于日志管理。

[uouuou]

不是，这是设计问题啊，我每天都有6.1m的请求，日志大于500m那太正常了

[uouuou]

感谢反馈。对于超过 500MB 的日志文件，直接读取确实会导致浏览器卡顿甚至崩溃，整体体验较差。 我们建议你创建网站日志切割类型的计划任务，将大文件按时间或大小进行拆分，既能提升查看效率，也更利于日志管理。

咱们1p不能只停留在小网站的建站呀，我们这种企业级的上1p每天日志超过1G是非常轻松的，整体日志系统的设置和读取因该优化为分段读取或者tail这种读取方式，而不是先加载文件再去读的形式，那肯定是不可以的

[zhengkunwang223]

感谢反馈。对于超过 500MB 的日志文件，直接读取确实会导致浏览器卡顿甚至崩溃，整体体验较差。 我们建议你创建网站日志切割类型的计划任务，将大文件按时间或大小进行拆分，既能提升查看效率，也更利于日志管理。

咱们1p不能只停留在小网站的建站呀，我们这种企业级的上1p每天日志超过1G是非常轻松的，整体日志系统的设置和读取因该优化为分段读取或者tail这种读取方式，而不是先加载文件再去读的形式，那肯定是不可以的

因为我们现在用了分页，会统计行数，返回总行数，这样就可以在读取日志的时候按照分页来加载数据，这样也造成了日志过大读取会很慢，如果用tail，可能就不太好处理，或者你只需要读取最后的几百或者几千行日志？

[uouuou]

不好意思，没看到切换了