New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log rotation #4890

Closed
benjaoming opened this Issue Feb 22, 2016 · 3 comments

Comments

Projects
None yet
1 participant
@benjaoming
Member

benjaoming commented Feb 22, 2016

Summary

After #4865 we have centralized the logging configuration and can start to use log rotation. This requires amending the docs because users might be instructed to just look at server.log and rotation might result in different file names.

Real-life consequences (anything community should be aware, for instance how it affects your deployment)

It's not too serious because currently the log file is cleared upon restart of ka lite, so the only implication is if you want to fetch a log for an error that occurred in a previous session.

@benjaoming

This comment has been minimized.

Show comment
Hide comment
@benjaoming

benjaoming Apr 14, 2017

Member

One method to guarantee full logging for the daemon (which redirects ALL stderr and stdout to server.log) would be to keep the existing mechanism where server.log is just overwritten each time KA Lite is started.

Following that, we could start logging with RotatingFileHandler to ~/.kalite/log/server.log.

On top of that, we need to do a quick empirical trial to see that exceptions at various levels (module load and views) are caught in the log, as those are the most important ones.

Member

benjaoming commented Apr 14, 2017

One method to guarantee full logging for the daemon (which redirects ALL stderr and stdout to server.log) would be to keep the existing mechanism where server.log is just overwritten each time KA Lite is started.

Following that, we could start logging with RotatingFileHandler to ~/.kalite/log/server.log.

On top of that, we need to do a quick empirical trial to see that exceptions at various levels (module load and views) are caught in the log, as those are the most important ones.

benjaoming added a commit to benjaoming/ka-lite that referenced this issue Apr 18, 2017

@benjaoming benjaoming referenced this issue Apr 18, 2017

Merged

Log rotation #5449

2 of 2 tasks complete

benjaoming added a commit to benjaoming/ka-lite that referenced this issue Apr 18, 2017

benjaoming added a commit to benjaoming/ka-lite that referenced this issue Apr 18, 2017

@benjaoming

This comment has been minimized.

Show comment
Hide comment
@benjaoming

benjaoming Apr 18, 2017

Member

This is implemented in #5449 and will be released in 0.17.1.

It doesn't contain any serious challenges, assuming that devices can easily carry 30 days of logs.

Unfortunately, maxBytes is not an accepted kwarg for TimedRotatingFileHandler, so we can't put an upper cap on the storage required for these logs. However, having 30 days back should not require substantial storage.

Member

benjaoming commented Apr 18, 2017

This is implemented in #5449 and will be released in 0.17.1.

It doesn't contain any serious challenges, assuming that devices can easily carry 30 days of logs.

Unfortunately, maxBytes is not an accepted kwarg for TimedRotatingFileHandler, so we can't put an upper cap on the storage required for these logs. However, having 30 days back should not require substantial storage.

@benjaoming benjaoming closed this Apr 18, 2017

@benjaoming

This comment has been minimized.

Show comment
Hide comment
@benjaoming

benjaoming Apr 19, 2017

Member

The timed log rotation will neatly place the date of the old log file when it rotates :)

screenshot from 2017-04-19 10-00-51

Member

benjaoming commented Apr 19, 2017

The timed log rotation will neatly place the date of the old log file when it rotates :)

screenshot from 2017-04-19 10-00-51

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment