Linux常用运维服务 – Nginx与Tomcat日志切割

444次阅读

共计 5389 个字符，预计需要花费 14 分钟才能阅读完成。

在实际生产中，我们知道哪些应用的日志会自动分割吗？哪些应用日志需要我们通过服务进行定时分割？接下来我们来看看。

是否会自动切割？
重启是否会自动分割？

日志名称	日志描述	是否自动切割	是否需要定时切割
access.log	Nginx 访问日志	否	是
error.log	Nginx 错误日志	否	是

如果需要单独配置网站日志的话需要在 server 模块添加access_log logs/djx.log ;

日志名称	日志描述	是否自动切割	是否需要定时切割
catalina.out	Tomcat 运行时日志和输出到控制台日志(应用)	否	是
catalina.2019-04-28.log	Tomcat 本身运行的日志，主要是启动和暂停的。	是	否
localhost_access_log.2019-04-28.txt	访问 Tomcat 的日志，请求时间和资源，状态码都有记录	是	否
localhost.2019-04-28.log	应用初始化 (listener, filter, servlet) 未处理的异常最后被 Tomcat 捕获而输出的日志	是	否
host-manager.2019-04-28.log	放 Tomcat 的自带的 Host Manager项目的日志信息的	是	否
manager.2019-04-28.log	Tomcat 自带 Manager项目专有的日志文件	是	否

Tomcat 的日志比较特别和有意思，我也是认真看了看才发现其中的奥秘。

Tomcat 的 catalina.out 日志是不会自动切割的，所以我们需要对它进行定时切割，重启 Tomcat 也是不会自动切割的。

其它的日志 Tomcat 是会进行自动切割的，但是会遵循这样的一个规则：日志隔天切割，有日志才切割，重启会切割：

日志隔天切割：含义是日志在 24.00 分才会进行切割，如果 00:00:10 产生了当天的第一条日志，那么就进行切割。
有日志才切割：含义是如果满足了隔天的要求，但是第二天一直没有产生日志，那么就会直到第二天第一条日志产生时才进行切割。
重启切割：含义是如果上面的条件都不满足，就是到了第二天，但是一条日志一直都没有产生，那么在重启 Tomcat 时是会进行切割的。

上面内容有点绕，我们举几个示例理解下。

示例 1：

    Tomcat 在 2019 年 4 月 28 号 15.30分启动的，有日志文件 catalina.2019-04-28.log 等。2019 年 4 月 29 号的第一条日志在 2019 年 4 月 29 号 9 .30分。那么日志切割在什么时候？       日志切割是在  2019 年 4 月 29 号 9 .30分。

示例 2：

        Tomcat 在 2019 年 4 月 28 号 10.30分启动的，有日志文件 catalina.2019-04-28.log 等。在 2019 年 4 月 29 号 3 .30分重启了 Tomcat，但是在重启前，Tomcat 在 2019 年 4 月 29 号 3 .30分当天是没有产生日志的，但在  2019 年 4 月 29 号 3.50 产生了日志。问在什么时候切割了日志？       Tomcat   重启时就进行了切割。

MongoDB 的日志我们平时是关注的比较少，但是我们这边还是做下记录。

MongoDB 的日志是否切割取决于 MongoDB 的配置参数。

logRotate= rename/reopen
    #3.0.0 版中的新功能。可以取值为 rename 或 reopen：
        rename 重命名日志文件。每次重启都会重命名日志文件。reopen 按照典型的 Linux/Unix 日志循环行为关闭并重新打开日志文件。使用 reopen 使用的             Linux/Unix logrotate 的工具时，以避免日志的丢失。如果指定 reopen，则还必须使用 logappend
logappend= true # 当 MongoDB 实例重新启动时，将新的日志内容添加到现有日志文件的末尾。如果没有此选项，MongoDB 将备份现有日志并创建新文件。

但是，MongoDB 的日志默认是不会进行切割的(如果不重启的话)。

MongoDB 日志切割见文章：MongoDB 日志切割三种方式

Redis 日志默认也是不切割的, 重启也不切割。Redis 日志在实际环境中我们也是建议进行切割的，切割频率可以降低。我看到有的 Redis 日志达到 1G，运行了 2 年，那么我们进行查找日志就比较不方便的，所以建议 Redis 的日志也进行切割。

我们通常会去寻找对应的日志切割服务，但是我们不知道系统默认已经默认带了一个日志的切割服务 logrotate。像我们系统的日志 /var/log/cron、/var/log/maillog、/var/log/messages等等这些都是通过 logrotate 来进行切割的，我们可以在文件 /etc/logrotate.d/syslog 看到具体的配置。logrotate 可以每天或者每个月按周期对日志进行自动切割和压缩，以及通过邮件发送。logrotate 的自动切割是通过 crond 来运行任务的。

logrotate 官方链接

logrotate [OPTION...] <configfile>
 -d, --debug  # 仅仅是测试，并不做任何东西。在测试配置文件是否正确的时候可以使用。
 -f, --force  # 指定配置文件
 -m, --mail=command   # 指定发送邮件的命令，替代 /bin/mail
 -s, --state=statefile # 指定状态文件的路径，默认路径是 /var/lib/logrotate.status。
 -v, --verbose  # 显示 logrotate 分割信息
 -l, --log=STRING # 指定日志文件的路径
 --version # 显示版本信息

logrotate 配置文件的位置位于/etc/logrotate.conf

logrotate 用户配置文件位于 /etc/logrotate.d/

logrotate 的执行状态文件/var/lib/logrotate.status

compress # 是否通过 gzip 压缩转储以后的日志文件，如 xxx.log-20131216.gz；如果不需要压缩，注释掉就行
compresscmd # 指定压缩的命令，默认 gzip
uncompresscmd # 用于解压缩的日志文件的命令 默认是 gunzip
compressext  # 启用压缩的扩展名，默认 gzip 的扩展名就是 .gz。
copy  # 制作日志文件的副本，与 create 选项互斥。
copytruncate # 用于还在打开中的日志文件，把当前日志备份并截断；是先拷贝再清空的方式，拷贝和清空之间有一个时间差，可能会丢失部分日志数据。与 create 选项互斥。
create mode owner group # 在切割后，创建新的日志文件，并指定数据的权限和所有者和所属组。
dateext    # 这个参数很重要！就是切割后的日志文件以当前日期 YYYYMMDD 为格式结尾，如 xxx.log-20131216 这样, 如果注释掉, 切割出来是按数字递增, 即前面说的 xxx.log- 1 这种格式
dateformat format_string # 指定日志文件后缀日期格式
ifempty # 表示即使是空文件也要选择，该选项是默认值。与 notifempty 相反
notifempty  # 当日志文件为空时，不进行轮转，与 ifempty 相反
mailfirst  #  当配置了邮件地址，指定发送最新的文件
maillast  # 当配置了邮件地址，指定发送最旧的文件，(默认设置)
rotate count  # 日志保留的次数，如果该参数不写的话，默认就是删除之前所有的文件日志。比如切割了 200 次，那么只保留最新的 180 次日志，并删除旧的 20 次日志。如果配置文件指定的是 daily，那每天切割一次日志，就意味着保留 180 天日志。
maxage count # 删除早于 count 天的日志，如果配置了 mail 则通过邮件发送。
daily   # 每天 切割
weekly  # 每周运行一次，通常在每周的第一天。
monthly      # 每月运行一次切割，通常会在该月的第一天。
yearly   # 如果当前年份与上一次年份不相同，就会进行切割
nocompress   # 不进行压缩。
size size  # 日志文件达到多大就切割
olddir dir  # 切割后存放的目录
start count  #  当没有指定日期后缀，将数字作为后缀内容，默认是从 1 开始。可以指定其他数字开始。
missingok   # 如果日志丢失，不报错继续滚动下一个日志
mail  112@163.com # 该参数与 rotate 是有关联的，当超过 rotate 指定次数，文件不是删除，而是通过邮件发送到指定位置。
prerotate       # 在 logrotate 转储之前需要执行的指令
postrotate      # 在 logrotate 转储之后需要执行的指令

###  3.85 版本增加每个小时切割
hourly # 每个小时切割

#  文件路径，可以使用通配符。
/opt/tomcat/logs/catalina.out{
compress 
compressext .gz
copytruncate
dateext
notifempty
maillast
rotate 180 
daily
size 10M
olddir /opt/logs/tomcat
missingok
mail 888888@qq.com # 如果我们本地没有配置好发送邮件配置的话是发送不了邮件的。
}

logrotate -d -f /etc/logrotate.d/tomcat  # 测试配置文件是否配置正常
logrotate  -f /etc/logrotate.d/tomcat  # 立刻切割文件，可以将该命令放到定时任务中实现定时切割

当我们设置好日志按日进行切割的时候，具体的执行时间是在什么时候呢？我们不要以为是会在 24.00 的时候进行切割的，它进行切割的时间是随机的。这个随机值取决于 crond 服务的，最终会取决于文件 /etc/anacrontab，
[root@localhost ~]# cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs # 延迟时间
RANDOM_DELAY=45
# the jobs will be started during the following hours only    执行时间段
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1   5   cron.daily      nice run-parts /etc/cron.daily
7   25  cron.weekly     nice run-parts /etc/cron.weekly
@monthly 45 cron.monthly        nice run-parts /etc/cron.monthly
我们可以发现定时任务是会在 3-22 点的 5 分 -45 分里面进行日志切割。
生产环境中该如何定时日志分割

我们在实际的生产环境中，我们通常会进行按日进行日志分割，也就是我们希望在 24.00 进行前一天的日志分割，我们可以通过 crond 服务进行定时切割 (logrotate -f /etc/logrotate.d/tomcat)，但是我们通常在很多应用中会有定时任务在 24.00 进行执行，那个时间段也就会产生大量的日志，如果我们在此时切割，那么我们可能会导致比较多的重要的日志丢失(并且此时任务多，资源消耗多，切割也慢)，那么我们建议先咨询开发，24.00 是否有大量定时任务，我们可以在 24.00 之前几分钟或者之后几分钟 进行切割。这样就避免大量的日志丢失。

示例：Nginx 日志保存在 /opt/nginx/logs/, 包含日志 access.log 和 error.log。

/opt/nginx/logs/* {
compress 
compressext .gz
copytruncate
dateext
notifempty
maillast
rotate 180 
daily
size 10M
olddir /opt/logs/nginx
missingok
mail 888888@qq.com # 如果我们本地没有配置好发送邮件配置的话是发送不了邮件的。
}

示例：Tomcat 日志保存在 /opt/tomcat/logs/, 包含日志 catalina.out, 其他日志会自动切割。

/opt/tomcat/logs/catalina.out{
compress 
compressext .gz
copytruncate
dateext
notifempty
maillast
rotate 180 
daily
size 10M
olddir /opt/logs/tomcat
missingok
mail 888888@qq.com # 如果我们本地没有配置好发送邮件配置的话是发送不了邮件的。

：

正文完

星哥玩云-微信公众号