本文从本人博客搬运，原文格式更加美观，可以移步原文阅读：Nginx日志分割
nginx默认没有提供对日志文件的分割功能，所以随着时间的增长，access.log和error.log文件会越来越大，尤其是access.log，其日志记录量比较大，更容易增长文件大小，影响日志写入性能

分割nginx日志的方法有很多，这里推荐利用Logrotate来完成

Logrotate用法

1.安装

logrotate是一个linux系统日志的管理工具。可以对单个日志文件或者某个目录下的文件按时间/大小进行切割，压缩操作；指定日志保存数量；还可以在切割之后运行自定义命令

logrotate是基于crontab运行的，所以这个时间点是由crontab控制的，具体可以查询crontab的配置文件/etc/anacrontab。系统会按照计划的频率运行logrotate，通常是每天。在大多数的Linux发行版本上，计划每天运行的脚本位于/etc/cron.daily/logrotate

主流Linux发行版上都默认安装有logrotate包，如果你的linux系统中找不到logrotate, 可以使用apt-get或yum命令来安装

yum install -y logrotate

一般linux都已经自带logrotate，下列命令可以查看是否已安装

rpm -ql logrotate

2.基本用法详解

2.1 入门

/etc/logrotate.conf这个文件是logrotate的主配置文件

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# 包含自定义配置目录
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

这个主配置文件中定义了日志文件分割的通用参数。并且include /etc/logrotate.d表示其会加载/etc/logrotate.d的所有自定义配置文件，自定义配置文件中的配置可以覆盖掉通用配置

我们来到自定义配置文件的目录/etc/logrotate.d

尝试在该目录中创建一个日志分割配置test，对/opt/logtest目录中所有以.log结尾的文件进行分割

vim test

# test配置文件的内容
/opt/logtest/*.log {
    daily
    rotate 2
    copytruncate
    missingok
}

test配置的第一行指定要对哪个路径的哪些文件进行分割，然后携带的4个参数解释如下：

• daily：按天切割。触发切割时如果时间不到一天不会执行切割。除了daily，还可以选monthly，weekly，yearly
• rotate：对于同一个日志文件切割后最多保留的文件个数
• copytruncate：将源日志文件切割成新文件后，清空并保留源日志文件。默认如果不启用该配置，分割后源日志文件将被删除。设置该值，以便分割后可以继续在源日志文件写入日志，等待下次分割
• missingok：切割中遇到日志错误忽略

创建好配置以后，系统会在每天利用cron定时执行logrotate日志分割指令。这里我们为了看到效果，不等到系统自动执行，可以手动强制执行一次日志分割。强制执行会立即进行一次日志

# -v:显示执行日志
# -f:强制执行分割
logrotate -vf /etc/logrotate.d/test

执行前，事先在日志所在目录中创建2个测试日志文件

touch test1.log
touch test2.log

手动执行一次日志分割，观察执行日志可以发现，过程如下：

1. 先将源日志内容拷贝到分割后的文件
2. 清空源文件

此时分割后的文件名为源文件名后面加上.序号，序号从1开始

然后我们再次手动执行一次分割，此时执行过程如下：

1. 将第一次分割后的日志文件test1.log.1重命名为test1.log.2
2. 将源日志文件拷贝到此次分割后的文件，命名序号重新从1开始，为test1.log.1
3. 清空源日志文件

接着再次手动执行一次分割，此时执行过程如下：

1. 将之前分割后的日志文件test1.log.2重命名为test1.log.3，test1.log.1重命名为test1.log.2
2. 分割源日志文件，拷贝其内容到test1.log.1
3. 由于设置了rotate为2，即最多保留2个日志文件，所以此时要删除最早分割出的那个日志文件，即test1.log.3

总结一下logrotate日志分割的步骤：

1. 默认分割后日志的命名为源日志名称+.序号(从1开始)。分割之前将所有之前分割出的日志文件重命名，序号往后移一位
2. 执行分割，将源日志文件分割为源日志文件名.1。这样就保证了所有分割后的文件中，序号最小的是最新分割出的，序号最大的是最早分割出的
3. 根据rotate设置，如果此次分割后文件数量大于rotate设置，那么删除序号最大的那个分割文件，也就是最旧的分割日志

实际开发中可以使用create代替copytruncate，它们的区别如下：

• copytruncate先将源文件内容拷贝到分割后文件，再清空源文件，拷贝和清空之间有时间差，可能会丢失部分日志。另外拷贝操作在源文件比较大时消耗性能

• create直接将源文件重命名为分割后文件，再创建一个与源文件名称相同的新文件，用于后续日志写入

  /opt/logtest/*.log {
      daily
      rotate 2
      create  # 创建与源文件名称相同的新文件，用于后续日志写入，新文件的归属用户、权限与源文件相同
      missingok
  }
  

  

  但是要注意create即使创建新的文件后，如果没有主动通知应用程序，那么应用程序仍然会往旧的文件(即被重命名的那个分割后的文件)写入日志。所以此时在分割后要通知应用程序重新打开新的日志文件进行写入。以通知nginx为例，配置如下

  /var/log/nginx/*.log {
      daily                      
      rotate 30              
      create
      sharedscripts              # 所有的文件切割之后只执行一次下面脚本，通知nginx重新打开新的日志文件进行后续写入
      postrotate
          if [ -f /run/nginx.pid ]; then
              kill -USR1 `cat /run/nginx.pid`  # 通过USER1信号通知nginx重新打开日志文件
          fi
      endscript
  }
  

• 综上，一般情况下如果应用程序提供了通知其打开新的日志文件的接口，那么推荐使用create续写日志；否则推荐使用copytruncate续写日志

注意：

• /etc/logrotate.d中的自定义配置中，如果不配置rotate、daily等参数在强制手动执行时并不会继承默认的主配置/etc/logrotate.conf。比如不配置rotate时，并不会继承保留4个分割文件，而是等价于0，即不保留任何分割文件。所以自定义配置中推荐显式指定这些参数
• 在系统crontab定时任务自动执行logrotate时，自定义配置会继承主配置文件中的参数
• logrotate执行分割的时机要依赖于crontab定时任务，也就是说crontab定时任务每日触发时，logrotate才会读取相应配置，检查是否满足分割的条件决定是否执行分割。这意味着，在默认crontab每日触发logrotate的定时任务情况下，即便logrotate配置文件中配置的分割频率小于1天，也将按照1天的频率触发分割，除非修改crontab定时任务，将logrotate的任务触发频率修改为小于1天

2.2 分割文件压缩

我们可以通过如下设置对分割后的日志文件开启压缩

/opt/logtest/*.log {
    daily
    rotate 2
    copytruncate
    missingok
    compress           # 以gzip方式压缩
    nodelaycompress    # 所有分割后的文件都进行压缩
}

此时删除原有所有文件，重新创建测试日志文件test1.log和test2.log，然后手动执行分割，可以生成压缩后的.gz文件

一般可以将nodelaycompress改为delaycompress，这样分割后对最新的序号为1的文件不会进行压缩，对其他序号的文件进行压缩，这样可以方便我们查看最新的分割日志

2.3 按照时间分割

按照时间分割可以定时分割出一个日志，比如每天分割一次，配合其他参数可以完成保留最近n天日志的功能。以下配置可以实现每天分割一次日志，并且保留最近30天的分割日志

/opt/logtest/*.log {
    daily      # 每天分割一次
    rotate 30  # 保留最近30个分割后的日志文件
    copytruncate
    missingok
    dateext  # 切割后的文件添加日期作为后缀
    dateyesterday # 配合dateext使用，添加前一天的日期作为分割后日志的后缀
}

还是先删除原来的所有文件，重新创建

touch test{1,2}.log

再手动执行分割，此时生成的分割后的文件将不再以序号作为文件名结尾，而是以昨天的日期作为结尾

并且如果马上再手动执行一次分割，由于日期相同，不会像原来一样生成序号递增的新日志文件，此时相当于没有执行任何分割操作。即同一天只能分割一次，第二天再次执行才会分割出新的日期结尾的文件，所以此时设置rotate的值即为保留最近多少天日志的意思

此外，默认添加的日期后缀格式为yyyyMMdd，可以用dateformat自定义

/opt/logtest/*.log {
    daily      # 每天分割一次
    rotate 30  # 保留最近30个分割后的日志文件
    copytruncate
    missingok
    dateext  # 切割后的文件添加日期作为后缀
    dateyesterday # 配合dateext使用，添加前一天的日期作为分割后日志的后缀
    dateformat -%Y-%m-%d  # 格式为2022-02-08
}

2.4 按照文件大小分割

我们可以利用size配置指定当日志文件达到多大体积时才进行分割。以下配置指定了每天执行分割，但是只有当日志文件大于5M时才真正执行分割操作

/opt/logtest/*.log {
    daily      # 每天分割一次
    size 5M    # 源文件小于5M时不分割
    rotate 30  # 保留最近30个分割后的日志文件
    create
    missingok
    dateext  # 切割后的文件添加日期作为后缀
    dateyesterday # 配合dateext使用，添加前一天的日期作为分割后日志的后缀
}

注意：这个配置并不是说日志文件达到指定大小就自动执行分割，它还是要遵循定时任务。比如配置了daily只有到每天指定时间执行分割任务时，才会检查文件大小，对超过指定大小的文件进行分割

2.5 自定义每小时分割

logrotate实现每日定时执行日志分割的原理是通过cron定时任务，默认在/etc/cron.daily中包含logrotate可执行命令，所以系统每天会定时启动logrotate，然后它会根据配置中具体分割频率(daily、weekly等)以及其他条件(比如size)决定是否要真正执行分割操作

如果我们想要实现每小时进行一次分割，需要如下步骤：

1. logrotate配置文件中指定分割频率为hourly

2. 配置完以后，还需要在cron的每小时定时任务中加入logrotate，因为默认情况下只有/etc/cron.daily中包含logrotate可执行命令，我们要将它往/etc/cron.hourly中也拷贝一份，这样系统才会每小时调用一次logrotate去执行分割

   cp /etc/cron.daily/logrotate /etc/cron.hourly/
   

2.6 自定义分割执行时间

logrotate 是基于cron 运行的，所以这个时间是由 cron 控制的，具体可以查询 cron 的配置文件/etc/crontab 。旧版CentOS 的cron 的配置文件是 /etc/crontab ，新版CentOS 改为 /etc/anacrontab

从上面的内容可以看出：

• 如果机器 没有关机，默认 logrotate（配置文件里设置的是cron.daily）一般会在每天的3点05分到3点50分之间执行， 真实的延迟时间是RANDOM_DELAY + delay in minutes
• 如果在3-22 这个时间段内服务器处于 关机状态，则 logrotate 会在机器开机5分钟后执行分割日志的操作

如果我们觉得每天凌晨3点多执行日志分割不合适，那么可以自定义分割执行时间。实现方式可以是：

• 修改/etc/anacrontab中的定时执行时间，实际不推荐，可能会影响系统其他定时任务
• 在/etc/logrotate.d以外的其他目录创建logrotate配置文件，然后利用crontab自定义cron表达式来执行logrotate对该配置进行分割操作

推荐采用crontab方式自定义执行时间，步骤如下：

1. 在非/etc/logrotate.d目录创建logrotate配置文件，这是为了避免被系统的定时任务扫描到该配置而导致重复执行分割

2. 添加 crontab 计划任务，在 root 用户下执行crontab -e进入 vim 模式，进行编辑

   crontab -e
   # 每天 23点59分进行日志切割
   59 23 * * * /usr/sbin/logrotate -f /etc/logrotate_mytime/nginx
   

3. 重启crontab

   # centos6: 
   service crond restart
   
   # centos7: 
   systemctl restart crond 
   

nginx日志分割步骤

在/etc/logrotate.d中创建文件nginx，作为nginx日志分割的配置文件。指定每天执行一次分割，并且当文件大于5M时才进行分割。同时指定notifempty，当日志文件为空时不分割

/opt/docker-ws/nginx/logs/*.log {
    daily      # 每天分割一次
    size 5M    # 源文件小于5M时不分割
    rotate 30  # 保留最近30个分割后的日志文件
    copytruncate
    notifempty # 当日志文件为空时不分割
    missingok
    dateext  # 切割后的文件添加日期作为后缀
}

这样配置了以后系统会在凌晨3点多执行分割操作，执行结果会保存到/var/spool/mail/root中

查看结果发现提示权限不够而分割失败，这是因为开启了selinux导致，解决方案有如下2种：

1. 关闭selinux

2. 利用semanage修改待分割的日志文件所在目录的权限

   # 开放/opt/logtest目录的权限
   semanage fcontext -a -t var_log_t "/opt/logtest(/.*)?"
   restorecon -Rv /opt/logtest
   

想象一下springboot开发的项目 一般都自带tomcat 如果我们直接以jar的形式执行，那么就需要不挂断执行那么日志怎么办？会不会越来越大？

根据网络安全法第二十一条规定，网络日志应留存不少于六个月。

     咋办？

    日志分割

sudo -u springboot nohup /usr/bin/java -Xms512m -Xmx512m -jar /home/java/xxxx-1.3.4.jar --server.port=8085 >> /tmp/xxx.log 2>&1 &

日志是一个很重要的记录，一般程序出现问题，都要通过日志来排除，那么我们怎么处理这个日志呢？不管又会一直变大，删除又不行

   日志有多种分割方式

     我例举我习惯使用的一种

   用shell来执行

current_date=`date -d "-1 day" "+%Y%m%d"`

split  -b 104857600 -d -a 4  /tmp/xxxx.log /tmp/java/xxxxx_${current_date}_

cat /dev/null >/tmp/xxxx.log

获取前一天的日期，把日志文件按照100M每份分割（你也可以设置小一点大一点），带日期加4个后缀  生成的文件类似   testlog_20211213_0000

最后清空原来的日志文件

当然你也可以使用宝塔面板来操作，确实很方便宝塔服务器面板，一键全能部署及管理http:// https://www.bt.cn/?invite_code=MV91ZWNla3Y=

可以很好管理我们服务器部署的项目

     

 这样建一个计划任务 让它每日自动给我们分割日志，我们就可以很好的玩耍了

 

默认tomcat运行产生的日志catalina.out文件不会自动分割，会一直不断累积增多，长此以往会影响服务器性能，如果服务器硬盘空间不是很大，很可能会超过磁盘空间，影响tomcat运行。

同时运维人员查看日志时，如果日志文件过大，打开日志也是问题，解决方法是把日志catalina.out文件进行分割处理。对应传统部署方式使用cronolog进行日志切割，但对于云模式容器化部署，这种方式改动较大，最终考虑通过脚本分割日志文件，并且编写脚本定时删除过久日志，本文将对实现的全过程进行记录。

 1整体介绍

对于Linux系统安全来说，日志文件是极其重要的工具，管理好海量的日志文件对管理有重大意义。本文将介绍一些实用的日志分割方法，详细讲解脚本分割方式，希望能够方便Linux/Unix管理员对日志文件进行有效管理。

1.1业务需求

在生产环境中，当我们使用tomcat服务时，如果用户量过多，又没有日志切割，将会产生大量日志，一天的日志都能有好几个G大小。当我们需要查看日志记录时非常麻烦。因此日志切割非常有必要。

1.2分割作用

随着服务访问量越来越大，服务器产生的日志文件也会越来越大，对其进行分割管理，单个日志文件不会变得异常庞大，有利于对日志进行综合分析、监控等。另外，当服务器遇到故障时，运维人员就要打开日志文件进行分析，打开的过程不会消耗很长时间，也势必会减少处理故障的时间。

2分割种类

tomcat的日志分割有三种方法，分别为用cronolog分割catalina.out文件、使用log4j分割catalina.out文件、使用shell脚本分割catalina.out文件。

2.1cronolog

使用cronolog比较简单，无需附加其他jar包，但是查看当天的catalina.out时必须使用日期后缀，不太方便。

容器化tomcat分割需要对容器内部的tomcat进行一定修改，相对繁琐。

2.2log4j分割

使用log4j的配置，稍微繁琐一些，但是感觉更加灵活，而且可以不改变原来的catalina.out的查看方式。

容器化tomcat分割需要对容器内部的tomcat进行一定修改，相对繁琐。

2.3shell脚本

脚本是使用一种特定的描述性语言，依据一定格式编写的可执行文件，又称作宏或批处理文件，脚本通常可以由应用程序临时调用并执行。使用灵活，分割方式自由控制，但需要使用者了解shell脚本的编写逻辑、cron的语法格式以及写入cron中自动执行此脚本。

容器化tomcat分割比较简单，不需要对容器内部的tomcat进行修改，但需要对k8s相关命令有所了解。

3配置过程

根据对上述3种日志分割方法的对比，选择了调整最小、侵入性最低的shell脚本方式实现日志分割，下面详细介绍脚本内各命令的作用。

3.1分割脚本

以下脚本存放目录为/opt/k8s/script/，编写脚本分割日志。

3.1.1脚本说明

下面就是分割容器内的日志脚本，整体思路如下：

1.master1和master2上创建日志分割脚本container-cut-log.sh；

2.脚本授权chmod a+x container-cut-log.sh；

3.检查vip，在有vip的服务器上执行分割脚本，原因是日志分割脚本会检查所有容器并分割日志，执行日志分割时，执行一次就可以了，没必要重复执行；

4.获取前一天日期；

5.加载k8s环境变量配置；

6.查询命名空间个数，循环查出每个命名空间名称；

7.通过命名空间查出，命名空间下有几个产品容器，循环查出每个产品容器名称；

8.通过命名空间和产品容器名称，，循环查出每个实例容器ID；

9.通过命名空间、产品容器名称、容器ID，先复制catalina.out为catalina.日期.out；

10.再通过命名空间、产品容器名称、容器ID，清空catalina.out，完成日志分割。

 

注意：虚拟ip需要根据实际情况修改。

3.1.2验证脚本

手动执行container-cut-log.sh脚本文件，查看执行日志，下图是截取的测试环境2个esb和2个idm日志分割的日志：

 

idm日志文件如下图：

 

3.2清理脚本

以下脚本存放目录为/opt/k8s/script/，编写脚本删除10天之前的日志文件。

3.2.1脚本说明

下面就是删除超过10天的日志脚本，整体思路如下：

1.master1和master2上创建日志清除脚本container-clean-log.sh；

2.脚本授权chmod a+x container-clean-log.sh；

3.检查vip，在有vip的服务器上执行清除脚本，原因是日志清除脚本会检查所有容器并删除日志,执行日志清除，执行一次就可以了，没必要重复执行；

4.加载k8s环境变量配置；

5.查询命名空间个数，循环查出每个命名空间名称；

6.通过命名空间查出，命名空间下有几个产品容器，循环查出每个产品容器名称；

7.通过命名空间和产品容器名称，循环查出每个实例容器ID和产品日志外部映射路径；

8.通过容器ID和产品日志外部映射路径，删除10天之前的日志文件。

 

 

 

注意：虚拟ip需要根据实际情况修改。

3.2.2验证脚本

手动执行container-clean-log.sh脚本文件，查看执行日志，下图是截取的测试环境2个esb和2个idm日志分割的日志：

 

3.3定时任务

cron是linux下用来周期性的执行某种任务或等待处理某些事件的一个守护进程，会自动启动cron进程，cron进程每分钟会定期检查是否有需要执行的任务，如果有则自动执行该任务。

3.3.1设置任务

编写定时任务：

# crontab -e

05 00 * * * sudo /opt/k8s/script/container-cut-log.sh

10 00 * * * sudo /opt/k8s/script/container-clean-log.sh

 

保存退出

:wq

3.3.2验证任务

完成上述操作就可以了，这里为了方便测试，可以创建n天前创建的文件，然后等待计划任务执行，看看效果。

 

测试已经删除。

 

4收获总结

4.1技术收获

1.日志文件大于一定大小就只保留最后特定行数，其他都删除，减少日志文件大小；

2.shell命令使用判断，循环，变量是设置和使用；

3.在容器外部使用kubectl命令，执行容器内部文件；

4.使用conrtab编写定时任务，定时调用脚本；

5.手动在服务器上执行命令，和用conrtab调用脚本执行命令实际上结果会不同，因为conrtab调用脚本不会加载服务器上的环境变量配置。

4.2测试须知

测试是很重要的环节，测试时考虑的场景一定要全，如果没有覆盖全部场景，就会导致脚本执行后无法达到预期效果。笔者最开始编写的脚本，当时只有两个环境，场景覆盖的并不完全，测试时没有任何问题。当环境扩展到4个后，暴露出了脚本的遗漏，之后重新调整脚本解决了问题。如果当时考虑到了，这个问题就不会再发生了，后续要多注意这种问题，凡事多想想，避免反复。

4.3成长感悟

linux的shell脚本功能是真的很强，基本上绝大多数应用程序出现自身解决不了的问题时都可以使用脚本编写命令解决。工作中经常执行一连串有顺序的、规律的甚至是重复性强且繁琐的命令行来实现我们要的操作，反复手动输入命令将会极大程度上限制我们的效率，这时编写shell脚本是很好解决这些问题的途径。

学会日志分割、删除没必要保留日志的实际作用很大，在项目中正式环境的服务运行基本都是很平稳的，每天都会产生很多日志数据，时间久了就有可能影响服务的运行。所以建议在项目中部署服务时，都要进行日志分割和定时清理，保证服务器的稳定运行。