Linux UWSGI log rotate-day cutting logs example

Both uwsgi and nginx's log write logs on a file name and cannot be rotated every day, so the volume of a single file will become larger and larger, which is not conducive to log backup.

nginx log segmentation method

The log segmentation method of nginx is researched on the network, and the principle is relatively simple.

Rename the file first, mv access.log access-20150215.log
Then reload nginx.
nginx continues to write log on access.log
I think this method should also be applicable to uwsgi. But not so easy.

Try to apply to uwsgi

Rename the file first, mv uwsgi.log uwsgi-20150215.log
Then reload uwsgi.
Don't see uwsgi.log file
It's completely different from what was imagined. It is found that the reload operation of uWSGI does not open the log file at all. Then you need to change your mind.

Solution one

The parameter touch-logreopen can reopen the log.


logto = /data/log/MODULE/uwsgi.log
touch-logreopen = / data / log / MODULE / .touchforlogrotate

touch-logreopen When the specified file is touched, the timestamp changes, which will cause uWSGI to reopen the log file without stopping the current service (not stop + start, but the concept of reload).


#! / bin / bash
 
module = "module_name"
DIR = `echo $ (cd" $ (dirname "$ 0") "; pwd)` #Get the current directory
LOGDIR = "/ data / log / $ module /" #log directory
 
sourcelogpath = "$ {LOGDIR} uwsgi.log" #logsource address
touchfile = "$ {LOGDIR} .touchforlogrotate" #Files that require touch
 
DATE = `date -d" yesterday "+"% Y% m% d "`
destlogpath = "$ {LOGDIR} uwsgi-$ {DATE} .log" #Renamed file
mv $ sourcelogpath $ destlogpath
 
#echo $ touchfile
touch $ touchfile # update file timestamp

Then add this in crontab, so that the log is split at 0: 0 every day. Of course, it can also be 23:59, but you need to change the shell script.


00 00 * * * /data/you_module_name/bin/uwsgirotate.sh> / dev / null 2> & 1

Of course, you don't need crontab. If you have logrorate service, you can add some events to it to scroll logs.

Solution two

The official said that the parameter log-maxsize <bytes> allows the uWSGI log file to be reopened after reaching a certain size. However, I remember that when it reached a certain size, it was not rewritten into the uwsgi.log file, which was strange. And according to the size of the log, I feel that it is not good to divide by time.

Solution three

Use the parameter log-master to let the main process listen for some signals. When you want the master process to send signals, the log will be re-opened. This is also necessary to change the file name in conjunction with the mv operation

Added: nginx log cutting and history log deletion script 7 days ago

The following log cutting script cuts nginx logs by date and automatically deletes logs 7 days ago (logs have been synchronized to a dedicated log storage server, you can safely delete historical logs.)

#! / bin / bash
#initialization
LOGS_PATH = / data / nginx / logs / www.domain.com
YESTERDAY = $ (date -d "yesterday" +% Y-% m-% d)
#Cutting logs by day
mv $ {LOGS_PATH} /access.log $ {LOGS_PATH} / access _ $ {YESTERDAY} .log
# Send the USR1 signal to the Nginx main process and reopen the log file, otherwise it will continue to write to the file after the mv, resulting in cutting failure.
kill -USR1 `ps axu | grep" nginx: master process "| grep -v grep | awk '{print $ 2}'`
#Delete logs 7 days ago
cd $ {LOGS_PATH}
find. -mtime +7 -name "* 20 [1-9] [3-9] *" | xargs rm -f
exit 0

Add this script to your scheduled task and execute it once a day:

1 0 * * * /usr/local/script/cut_del_logs.sh