logger级别及大小
技术大佬们，加我群吧，
群1：868373192，
群2：277356808
群3：102948747一、 日志级别
日志级别用于标识日志信息的重要性和紧急程度。开发者通过设置级别，可以控制哪些级别的日志需要被输出、记录或处理。
常见的日志级别从高到低（从严重到轻微）通常分为以下几种：
OFF / FATAL:
最高级别。用于关闭所有日志记录，或表示应用发生了最严重的错误事件，可能导致应用程序完全中止。
ERROR:
表示发生了错误事件，但应用程序可能仍然可以继续运行。例如：数据库连接失败、空指针异常、关键业务逻辑执行失败等。需要开发人员立即关注并处理。
WARN:
表示潜在的有害情况或非预期状态，但不会立即影响核心流程。应用程序通常可以恢复正常。例如：使用了过时的API、磁盘空间不足、非核心接口调用超时等。需要关注但不必立即处理。
INFO（最常用）:
用于记录应用程序运行过程中的重要信息，通常用于输出业务逻辑的正常状态。例如：程序启动/停止、用户登录成功、订单创建成功等。在生产环境中，通常将此级别作为默认级别。
DEBUG:
用于调试目的，比INFO更详细。通常记录程序运行的细节信息，例如：方法的入参和出参、变量的中间状态、SQL语句等。此级别通常只在开发或测试环境开启，生产环境会关闭，以避免产生大量日志影响性能。
TRACE:
比DEBUG更细致、更底层的跟踪信息。用于追踪程序的每一步执行路径。会产生极其大量的日志，仅在需要深度排查极端复杂的问题时临时开启。
级别规则：
日志框架会只输出设置级别及以上级别的日志。
如果设置级别为
WARN，则只会记录WARN,ERROR,FATAL级别的日志。如果设置级别为
DEBUG，则会记录DEBUG,INFO,WARN,ERROR,FATAL级别的日志。
二、 日志文件大小管理
如果不加控制，日志文件会无限增长，最终占满磁盘空间。因此，所有主流的日志框架都提供了“滚动策略”来管理日志文件的大小和数量。
核心思想是：当一个日志文件满足特定条件（如大小达到阈值、时间到了新的一天）时，就将其归档（重命名备份），然后创建一个新的空白日志文件继续记录。
常见的滚动策略配置参数：
基于文件大小的滚动策略
maxFileSize: 单个日志文件的最大大小。当达到这个大小时，就会触发滚动。例如：
10MB,100MB,1GB
maxHistory: 最多保留的归档日志文件数量。超过这个数量的最旧的归档文件会被自动删除，以防止磁盘被写满。例如：设置为
30，表示最多保留30个备份文件（如app.log.1,app.log.2, ...app.log.30）。
totalSizeCap: 所有归档日志文件的总大小上限。当总大小超过这个限制时，会从最旧的文件开始删除，即使数量还没达到maxHistory。
基于时间的滚动策略
fileNamePattern: 定义归档日志的文件名模式和滚动周期。例如：
/logs/app-%d{yyyy-MM-dd}.log会每天创建一个新的日志文件。
maxHistory: 同样适用，表示最多保留多少天（或其他时间单位）的日志文件。
通常，基于大小的滚动和基于时间的滚动会结合使用，例如“按天归档，并且当单日日志量过大时，在同一天内再按大小进行分割”。
三、 配置示例
下面以两个最流行的Java日志框架为例：
1. Logback 配置示例 (logback.xml)
xml
<configuration><appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"><!-- 当前正在记录的日志文件路径 --><file>/var/log/myapp/app.log</file><!-- 滚动策略：基于大小和时间的混合策略 --><rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"><!-- 归档文件的名称模式：%d{yyyy-MM-dd}: 按天归档%i: 当一天内日志超过最大大小时，进行索引编号 --><fileNamePattern>/var/log/myapp/archives/app-%d{yyyy-MM-dd}-%i.log.gz</fileNamePattern><!-- 每个日志文件最大 100MB --><maxFileSize>100MB</maxFileSize><!-- 最多保留 30 天的日志 --><maxHistory>30</maxHistory><!-- 所有归档文件总大小不超过 3GB --><totalSizeCap>3GB</totalSizeCap></rollingPolicy><encoder><pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern></encoder></appender><root level="info"><appender-ref ref="FILE" /></root>
</configuration>2. Log4j2 配置示例 (log4j2.xml)
xml
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN"><Appenders><RollingFile name="FileAppender" fileName="/var/log/myapp/app.log"filePattern="/var/log/myapp/archives/app-%d{yyyy-MM-dd}-%i.log.gz"><!-- 日志格式 --><PatternLayout><Pattern>%d{yyyy-MM-dd HH:mm:ss} [%t] %-5p %c{1} - %m%n</Pattern></PatternLayout><!-- 滚动策略 --><Policies><!-- 每天滚动一次 --><TimeBasedTriggeringPolicy interval="1" modulate="true"/><!-- 单个文件超过 100MB 时滚动 --><SizeBasedTriggeringPolicy size="100MB" /></Policies><!-- 保留策略 --><DefaultRolloverStrategy max="30" delete="true"><Delete basePath="/var/log/myapp/archives/" maxDepth="1"><!-- 删除超过30天或总大小超过3GB的日志 --><IfLastModified age="30d" /><IfAccumulatedFileSize exceeds="3GB" /></Delete></DefaultRolloverStrategy></RollingFile></Appenders><Loggers><Root level="info"><AppenderRef ref="FileAppender" /></Root></Loggers>
</Configuration>总结与最佳实践
级别选择：
生产环境：通常使用
INFO或WARN。测试/预发布环境：可以使用
DEBUG来排查问题。开发环境：可以使用
DEBUG或TRACE。
大小管理：
必须配置滚动策略，绝不能放任日志无限增长。
根据应用日志量和磁盘空间，合理设置
maxFileSize（如100MB-1GB）和maxHistory（如保留7-30天）。设置
totalSizeCap作为最后的安全网，防止误算导致磁盘爆满。
日志清理：
推荐使用日志框架自带的
maxHistory和totalSizeCap机制自动删除旧日志，而不是依赖外部Cron作业，这样管理更清晰、更可靠。
通过合理配置日志级别和滚动策略，你可以既能获取足够的信息来监控和调试应用程序，又能确保日志系统本身是高效、稳定且不会成为系统的负担。