解决logback无法生成第二天日志的问题

本文介绍如何解决Logback配置中无法自动生成第二天日志的问题。通过将滚动策略从TimeBasedRollingPolicy更改为SizeAndTimeBasedRollingPolicy,确保了日志按预期滚动。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

解决logback无法生成第二天日志的问题

之前有写过一篇springboot 配置logback日志,但是存在一个bug,无法生成第二天的日志,解决方案如下:

原代码如下:

<!-- ERROR级别日志 -->
    <!-- 滚动记录文件,先将日志记录到指定文件,当符合某个条件时,将日志记录到其他文件 RollingFileAppender -->
    <appender name="ERROR"
        class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 过滤器,只记录WARN级别的日志 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
        <!-- 最常用的滚动策略,它根据时间来制定滚动策略.既负责滚动也负责出发滚动 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!--日志输出位置 可相对、和绝对路径 -->
            <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/error-log.log
            </fileNamePattern>
            <!-- 可选节点,控制保留的归档文件的最大数量,超出数量就删除旧文件假设设置每个月滚动,且<maxHistory>是6, 则只保存最近6个月的文件,删除之前的旧文件。注意,删除旧文件是,那些为了归档而创建的目录也会被删除 -->
            <maxHistory>${maxHistory}</maxHistory>
        </rollingPolicy>

        <!-- 按照固定窗口模式生成日志文件,当文件大于20MB时,生成新的日志文件。窗口大小是1到3,当保存了3个归档文件后,将覆盖最早的日志。 -->
        <!-- <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
            <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/.log.zip</fileNamePattern> <minIndex>1</minIndex> 
            <maxIndex>3</maxIndex> </rollingPolicy> -->
        <!-- 查看当前活动文件的大小,如果超过指定大小会告知RollingFileAppender 触发当前活动文件滚动 -->
        <triggeringPolicy
            class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>10GB</maxFileSize>
        </triggeringPolicy>

        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger -
                %msg%n</pattern>
        </encoder>
    </appender>

修改之后:

<!-- ERROR级别日志 -->
    <!-- 滚动记录文件,先将日志记录到指定文件,当符合某个条件时,将日志记录到其他文件 RollingFileAppender -->
    <appender name="ERROR"
        class="ch.qos.logback.core.rolling.RollingFileAppender">
        <!-- 过滤器,只记录WARN级别的日志 -->
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>ERROR</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
        <!-- 最常用的滚动策略,它根据时间来制定滚动策略.既负责滚动也负责出发滚动 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!--日志输出位置 可相对、和绝对路径 -->
            <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/error-log.log
            </fileNamePattern>
            <!-- 可选节点,控制保留的归档文件的最大数量,超出数量就删除旧文件假设设置每个月滚动,且<maxHistory>是6, 则只保存最近6个月的文件,删除之前的旧文件。注意,删除旧文件是,那些为了归档而创建的目录也会被删除 -->
            <maxHistory>${maxHistory}</maxHistory>
        </rollingPolicy>

        <!-- 按照固定窗口模式生成日志文件,当文件大于20MB时,生成新的日志文件。窗口大小是1到3,当保存了3个归档文件后,将覆盖最早的日志。 -->
        <!-- <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
            <fileNamePattern>${log_dir}/%d{yyyy-MM-dd}/.log.zip</fileNamePattern> <minIndex>1</minIndex> 
            <maxIndex>3</maxIndex> </rollingPolicy> -->
        <!-- 查看当前活动文件的大小,如果超过指定大小会告知RollingFileAppender 触发当前活动文件滚动 -->
        <triggeringPolicy
            class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>10GB</maxFileSize>
        </triggeringPolicy>

        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger -
                %msg%n</pattern>
        </encoder>
    </appender>

此次修改,主要是将ch.qos.logback.core.rolling.TimeBasedRollingPolicy调整为ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy。
经测试,第二天日志有正常生成了!

<think>好的,我现在需要帮助用户理解他们的Logback配置,特别是关于日志文件大小是否会影响生成,以及自动生成新压缩包的时间。首先,用户提供的配置片段中使用了SizeAndTimeBasedRollingPolicy,这是一个结合时间和文件大小的滚动策略。我需要先分析这个配置的各个参数,然后回答用户的问题。 首先,用户的问题有两个部分:1日志文件太小是否会影响生成2)自动生成新压缩包的时间。我需要先解释配置中的各个部分,特别是maxFileSize、fileNamePattern中的%i,以及时间相关的%d。然后结合这些参数,说明何时会触发新的日志文件生成日志文件太小是否会影响生成?这里的“太小”可能指的是maxFileSize设置的值。根据文档,当单个日志文件达到maxFileSize时,会触发滚动,生成新的文件。所以如果maxFileSize设置得很小,比如20MB,那么每当文件达到这个大小时,就会生成新的文件,包括压缩包。因此,用户的问题中提到的20MB,确实会影响生成的频率,文件会更快滚动,生成更多的%i编号的文件。 然后是自动生成新压缩包的时间。因为配置中使用了%d{yyyy-MM-dd},所以每天会创建一个新的日期目录。但具体何时生成新的压缩包,还需要考虑时间滚动策略。SizeAndTimeBasedRollingPolicy结合了时间和大小,所以新的日期到来时,即使文件没达到大小限制,也会触发滚动。而如果是在同一天,文件大小达到20MB时,也会滚动生成新的%i文件。压缩包的时间部分由%d决定,所以每天的第一个日志文件会以日期目录开始,而后续的滚动在同一天内通过%i递增,并在跨天时创建新的日期目录,并重置%i。 接下来,用户可能关心的是,如果日志量很小,比如一天都没达到20MB,是否会在第二天生成新的压缩包。是的,因为时间滚动策略会在每天凌晨触发,无论大小是否达到,都会生成新的日期目录,并将旧文件归档。但需要确认TimeBasedRollingPolicy的行为,通常时间触发的滚动是在应用程序运行时,在时间点到达时触发。如果应用在跨天时没有运行,可能不会触发,但一旦应用运行到新的一天,就会触发滚动。 另外,用户提到日志停止输出,可能和配置中的maxHistory或totalSizeCap有关。如果设置了maxHistory为30天,超过30天的日志会被删除,但用户的问题中停止生成新目录可能和磁盘空间、权限或配置错误有关,比如fileNamePattern中的路径是否正确,是否有写入权限,或者时区问题导致滚动时间不正确。 用户配置中的fileNamePattern是logs/%d{yyyy-MM-dd}/server.%i.log.zip,这意味着每天的日志会存放在对应日期的目录下,每个文件达到20MB后会生成新的%i文件,并且压缩成zip。需要确认是否生成了正确的目录结构,以及是否有权限写入。 总结回答的结构应该是先解释配置中各参数的作用,然后分别回答日志文件大小的影响和自动生成的时间点,最后结合用户之前的问题,给出可能的问题原因,比如时区、权限、配置错误等。</think>以下是针对您提供的Logback配置及问题的技术解析: --- ### 一、配置核心参数解读 ```xml <appender name="server" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <!-- 关键参数 --> <fileNamePattern>logs/%d{yyyy-MM-dd}/server.%i.log.zip</fileNamePattern> <maxFileSize>20MB</maxFileSize> <!-- 单个文件最大尺寸 --> <maxHistory>30</maxHistory> <!-- 保留最近30天日志 --> <totalSizeCap>5GB</totalSizeCap> <!-- 所有日志总大小上限 --> </rollingPolicy> </appender> ``` --- ### 二、日志文件大小与生成关系 #### 1. **文件大小直接影响滚动触发** - **`maxFileSize=20MB`** 表示: - 当单个未压缩的日志文件达到20MB时,**立即触发滚动**生成新文件 - 滚动后旧文件会被压缩为`.zip`(由文件名后缀决定) - `%i`为索引计数器,同一日内多次滚动时递增(如:server.0.log.zip, server.1.log.zip) - **如果日志量极小**(如一天总日志<20MB): - 当日志写入跨越**日期变更**时(如从2025-03-122025-03-13) - **强制触发时间滚动**,生成新日期目录及文件,与文件大小无关 --- ### 三、自动生成新压缩包的时间规则 #### 1. **双重触发机制** | 触发条件 | 行为示例 | 优先级 | |-------------------------|-----------------------------------|--------| | **时间滚动**(主驱动) | 每天00:00生成新目录`yyyy-MM-dd` | 高 | | **大小滚动**(辅助驱动)| 同一日内日志文件达到20MB时递增`%i` | 低 | #### 2. **具体时间点** - **新日期目录生成时间**:取决于`%d{yyyy-MM-dd}`中的日期变更点 - 默认基于**服务器本地时区**的00:00 - 若时区配置错误(如UTC+8服务器误用UTC),实际生成时间会偏移 - **压缩包生成时机**: - 时间触发:每天首次日志写入时创建新目录及文件 - 大小触发:任何时刻达到`maxFileSize`即生成新`.%i.log.zip` --- ### 四、配置潜在问题自查表 | 现象 | 可能原因 | 验证方法 | |--------------------------|-----------------------------------|------------------------------| | 未生成新日期目录 | 时区配置错误 | 对比服务器时间与日志文件名 | | 同日内未生成新压缩包 | 日志量未达20MB | 检查日志文件大小 | | 压缩包数量异常增多 | 突发大量日志触发频繁大小滚动 | 监控日志产生速率 | | 旧日志未被清理 | `totalSizeCap`优先于`maxHistory` | 计算日志总大小是否超5GB | --- ### 五、针对您日志中断的特殊分析 结合您描述的**2025-03-12 23:13:26**后无新日志1. **检查3月13日目录权限** ```bash ls -ld logs/2025-03-13 # 确认目录是否存在及可写 ``` 2. **验证时区一致性** - 执行对比命令: ```bash date +"%Z %Y-%m-%d %H:%M:%S" # 系统时间 grep "JVM TimeZone" app.log # 应用感知时区 ``` 3. **检查磁盘配额** ```bash df -h logs # 检查inode与块剩余量 ls -lh logs/*.zip # 确认压缩包未异常膨胀 ``` --- ### 六、调试建议 1. **强制触发滚动测试** ```bash # 查找Java进程PID jps -l | grep your-app-main-class # 发送重载信号 kill -SIGUSR1 <PID> ``` 2. **启用调试模式** 在logback.xml中添加: ```xml <configuration debug="true"> <!-- 原有配置 --> </configuration> ``` 观察控制台输出的滚动策略执行日志。 如果需要进一步分析具体异常场景,可提供触发时间点前后的系统监控数据(CPU/内存/IO)。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值