You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RollingFile should have limits, like last month, or 1gb max, to not drain disk space on customers machine. I think this is critical to have if this lib is meant to be used in production environments.
The generated files will not be deleted. If you want to do a log rotation, please do it from outside.
I think this is not good way to deal with log rotation. Especially if you have something misbehaving (generating lots of logs), the only solution is to react before disk fills up.
To solve this from outside it would be really hard to get right, as it cannot be just solved with cron job, it needs active monitoring and dealing with locked files, whereas log process already knows file masks and can correctly compute file sizes and stop logging when attempting to roll.
I think the right thing to do is stop logging, because if something is misbehaving and creating lots of log files probably cause of the problem is much more useful. If logger would remove younger logs, it could hide the cause of problem with lots of gibberish.
The text was updated successfully, but these errors were encountered:
A classic practice is to monitor it externally, which I believe is possible.
However, this is certainly cumbersome.
Shall we add a retainedFileCountLimit?
RollingFile should have limits, like last month, or 1gb max, to not drain disk space on customers machine. I think this is critical to have if this lib is meant to be used in production environments.
I think this is not good way to deal with log rotation. Especially if you have something misbehaving (generating lots of logs), the only solution is to react before disk fills up.
To solve this from outside it would be really hard to get right, as it cannot be just solved with cron job, it needs active monitoring and dealing with locked files, whereas log process already knows file masks and can correctly compute file sizes and stop logging when attempting to roll.
I think the right thing to do is stop logging, because if something is misbehaving and creating lots of log files probably cause of the problem is much more useful. If logger would remove younger logs, it could hide the cause of problem with lots of gibberish.
The text was updated successfully, but these errors were encountered: