一 、Nginx-Tomcat 等常用服务日志分析
在实际生产中，我们知道哪些应用的日志会自动分割吗？哪些应用日志需要我们通过服务进行定时分割？接下来我们来看看。
对比的标准是否会自动切割 ？
重启是否会自动分割 ？
Nginx 日志 日志名称日志描述是否自动切割是否需要定时切割access.log Nginx 访问日志 否 是
error.log Nginx 错误日志 否 是
如果需要单独配置网站日志的话需要在 server 模块添加access_log logs/djx.log ;
Tomcat日志 日志名称日志描述是否自动切割是否需要定时切割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 的日志是否切割取决于 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 日志在实际环境中我们也是建议进行切割的，切割频率可以降低。我看到有的 Redis 日志达到 1G，运行了2年，那么我们进行查找日志就比较不方便的，所以建议 Redis 的日志也进行切割。
二 、日志切割服务 logrotate