ThingsBoard 日志越滚越大？用 logback 内置轮转 3 步控住磁盘
【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard
凌晨值班时被一条告警叫醒——磁盘占用飙到 95%，追下去全是 ThingsBoard 的.log文件在悄悄膨胀。设备连接、遥测、SQL 查询全往同一个目录写，时间一长就把日志卷打爆。好消息是，ThingsBoard 的每个服务进程都自带 logback 的滚动策略，只要读懂并调好那份配置，日志就能自己"滚动 + 压缩 + 过期清理"，不用额外挂一堆脚本。
方案总览：先看清 ThingsBoard 日志到底落在哪
我们先把全局讲清楚，避免一上来就改错文件：
- 谁在写日志：主服务和各传输服务（MQTT、HTTP、LwM2M…）各自独立进程，各自的
logback.xml决定落盘规则。 - 写到哪里：由
thingsboard.conf里的@pkg.logFolder@变量决定，进程主日志是${pkg.name}.log，JVM 的 GC 日志是${pkg.logFolder}/gc.log。 - 怎么控住：logback 的
SizeAndTimeBasedRollingPolicy已经内置了"按大小 + 按天滚动、保留 N 天、总量封顶"三件事，我们只需确认/微调参数，再叠加一层监控即可。
| 关注点 | 默认行为 | 对应配置 |
|---|---|---|
| 主日志文件 | ${pkg.name}.log | application logback |
| 单文件上限 | 100MB 触发滚动 | <maxFileSize> |
| 保留天数 | 30 天 | <maxHistory> |
| 磁盘总量封顶 | 3GB | <totalSizeCap> |
| GC 日志 | gc.log，10 份 × 10M | thingsboard.conf |
动手前确认这几项
对照下面这份清单，先确认环境和权限没问题，改配置才有意义：
- 能读到配置目录：
application/src/main/conf/下有logback.xml和thingsboard.conf，这是主服务的两套核心日志配置。 - 知道日志实际目录：运行时
@pkg.logFolder@被替换成真实安装路径（如/var/lib/thingsboard/logs或打包时指定的目录）。 - 对进程有重启/热加载权限：logback 支持
scan热更新，改完不一定要重启，但要有写权限。 - 有磁盘与
crontab权限：后面要挂一个只读的磁盘检查任务。
第 1 步：读懂当前 logback 轮转，确认它已在滚动
目的：先确认 ThingsBoard 不是"裸写"日志，而是已经带滚动策略——这决定了我们要做的是"调参"而不是"从零搭"。
操作：查看主服务的 logback 配置，重点看fileLogAppender里这段（下面只截取关键项，含义已加注释）：
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${pkg.logFolder}/${pkg.name}.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxFileSize>100MB</maxFileSize> <!-- 单文件超过 100MB 就切一个新文件 --> <maxHistory>30</maxHistory> <!-- 最多保留 30 天的归档 --> <totalSizeCap>3GB</totalSizeCap> <!-- 所有归档加起来不超过 3GB --> </rollingPolicy>验证：你应看到SizeAndTimeBasedRollingPolicy这三个参数都在。这意味着磁盘最多被 ThingsBoard 主日志占用约 3GB 后就会自动清掉最老的归档，不会无限增长。
第 2 步：按磁盘余量微调保留参数
目的：3GB / 30 天是默认值，如果你的日志目录空间紧张，就把"保留多久、封顶多少"往下调。
操作：在同一个logback.xml里改两个数字（传输服务同理，见 transport/mqtt 的 logback）：
<maxHistory>7</maxHistory> <!-- 只保留 7 天，磁盘小的环境改小 --> <totalSizeCap>1GB</totalSizeCap> <!-- 总量封顶压到 1GB -->改完保存即可，主服务根节点带了scan="true" scanPeriod="10 seconds"，logback 会自行热加载，不必立刻重启。
验证：观察日志目录，几小时后应出现thingsboard.2026-10-17.0.log这类带日期、带序号的归档文件；旧的过期归档在下一轮滚动时被清掉。
第 3 步：把日志"噪音源"也一并降噪
目的：光控大小还不够，有些开关一开，日志量会成倍膨胀——把它们按需求关掉，能直接减小写入压力。
操作：在 thingsboard.yml 里核对这几项默认值，按需收紧：
sql: log_queries: "${SQL_LOG_QUERIES:false}" # 默认关，别为排查一次而长期开着 log_tenant_stats: "${SQL_LOG_TENANT_STATS:true}" # 定期打租户统计，量大可关 transport: log: enabled: "${TB_TRANSPORT_LOG_ENABLED:true}" # 传输消息落 telemetry 的日志，稳态可关 max_length: "${TB_TRANSPORT_LOG_MAX_LENGTH:1024}" # 单条上限，避免长报文刷屏验证：重启或热更后，tail -f主日志，正常业务流量下不应再看到成片的租户统计或传输明细行，只留必要的连接/告警信息。
验证与踩坑
- 改了 logback 却不生效：多半是没改到"运行中进程实际加载的那份"
logback.xml——部署包里conf/与resources/下可能各有一份。以进程启动时LOADER_PATH指向的目录为准，确认改对文件。 - 归档文件还在继续变多：检查是不是把
totalSizeCap设得比maxHistory暗示的空间大，或目录被多进程共写。每个服务独立写自己的${pkg.name}.log，别把几个服务的目录叠在一起算空间。 - GC 日志也在悄悄占地方：thingsboard.conf 里
gc.log固定是filecount=10,filesize=10M，即最多约 100MB，属正常；若怀疑它异常，单独du -h看这一项即可，别和主日志混在一起判断。
进阶扩展
- 磁盘水位监控：主服务带
cluster.stats开关（TB_CLUSTER_STATS_ENABLED），配合系统侧的磁盘告警，可以提前在"日志快满"前收到通知，而不是等它打爆。 - 审计日志单独控：
audit-log支持按实体设logging-level（OFF / W / RW），稳态环境把只读类的级别调低，能明显减少落盘量。
收束
核心就一句话：ThingsBoard 的日志轮转是内置的，你要做的是读懂参数、按磁盘调小、关掉噪音开关。别去外面再造轮子，把 logback 那几个数字和 yml 里的日志开关理顺，磁盘就能稳住。
行动清单：
- 确认运行时真实的
@pkg.logFolder@目录，du -sh看当前占用 - 按磁盘余量把
maxHistory/totalSizeCap调到合适值 - 关闭
SQL_LOG_QUERIES、传输log.enabled等稳态不需要的日志源 - 对 GC 日志单独
du -h，确认在 10×10M 的正常范围内 - 挂一个磁盘水位告警，提前收到"快满"的提醒
【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
