[Feature] PegaProx log files take up all available disk space without warning

[j0c00]

Describe the feature

PegaProx log files take up all available disk space without warning; you only notice this when the update fails to start after clicking the install button.
It would be helpful if the installation package included a component for logrotate, or if PegaProx implemented its own solution to address this issue.
It would also be helpful to have some information about the size of the log files in the documentation; for example, I’m seeing a 70+ MB log file every hour (on a cluster consisting of 20+ PVE nodes).

root@pegaprox-01:~# ls -l /opt/PegaProx/logs/
total 311608
-rw-r--r-- 1 pegaprox pegaprox 230096524 Apr 27 11:00 2e796bf2.log
-rw-r--r-- 1 pegaprox pegaprox  88980099 Apr 27 11:00 8929c839.log
root@pegaprox-01:~# uptime
 11:00:11 up  3:08,  1 user,  load average: 0.06, 0.06, 0.07
root@pegaprox-01:~#

Use Case

Alternatives considered

How important is this for you?

Checklist

• I have searched existing issues and discussions to make sure this hasn't been requested before

[mkellermann97]

Hi @j0c00 — yeah you're right, we don't ship anything for log rotation right now and on a 20-node setup that catches up with you fast. 100 MB/h is roughly the ballpark we'd expect at that scale (lots of polling), but obviously running you out of disk without warning is not great.

Logrotate snippet shipped via deploy.sh would be the cheap path; built-in RotatingFileHandler the proper one. Wird considered for one of the next patch releases — I'd lean on logrotate first since that's what most ops folks already have tooling around.

For now as a quick mitigation you can drop something like this into /etc/logrotate.d/pegaprox:

/opt/PegaProx/logs/*.log {
    hourly
    rotate 48
    compress
    missingok
    notifempty
    copytruncate
}

copytruncate so we don't have to teach the app to reopen the FD. We're funded via OpenCollective if that ever feels worth supporting.

— Marcus