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}.logJVM 的 GC 日志是${pkg.logFolder}/gc.log。怎么控住logback 的SizeAndTimeBasedRollingPolicy已经内置了按大小 按天滚动、保留 N 天、总量封顶三件事我们只需确认/微调参数再叠加一层监控即可。关注点默认行为对应配置主日志文件${pkg.name}.logapplication logback单文件上限100MB 触发滚动maxFileSize保留天数30 天maxHistory磁盘总量封顶3GBtotalSizeCapGC 日志gc.log10 份 × 10Mthingsboard.conf动手前确认这几项对照下面这份清单先确认环境和权限没问题改配置才有意义能读到配置目录application/src/main/conf/下有logback.xml和thingsboard.conf这是主服务的两套核心日志配置。知道日志实际目录运行时pkg.logFolder被替换成真实安装路径如/var/lib/thingsboard/logs或打包时指定的目录。对进程有重启/热加载权限logback 支持scan热更新改完不一定要重启但要有写权限。有磁盘与crontab权限后面要挂一个只读的磁盘检查任务。第 1 步读懂当前 logback 轮转确认它已在滚动目的先确认 ThingsBoard 不是裸写日志而是已经带滚动策略——这决定了我们要做的是调参而不是从零搭。操作查看主服务的 logback 配置重点看fileLogAppender里这段下面只截取关键项含义已加注释rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePattern${pkg.logFolder}/${pkg.name}.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxFileSize100MB/maxFileSize !-- 单文件超过 100MB 就切一个新文件 -- maxHistory30/maxHistory !-- 最多保留 30 天的归档 -- totalSizeCap3GB/totalSizeCap !-- 所有归档加起来不超过 3GB -- /rollingPolicy验证你应看到SizeAndTimeBasedRollingPolicy这三个参数都在。这意味着磁盘最多被 ThingsBoard 主日志占用约 3GB 后就会自动清掉最老的归档不会无限增长。第 2 步按磁盘余量微调保留参数目的3GB / 30 天是默认值如果你的日志目录空间紧张就把保留多久、封顶多少往下调。操作在同一个logback.xml里改两个数字传输服务同理见 transport/mqtt 的 logbackmaxHistory7/maxHistory !-- 只保留 7 天磁盘小的环境改小 -- totalSizeCap1GB/totalSizeCap !-- 总量封顶压到 1GB --改完保存即可主服务根节点带了scantrue scanPeriod10 secondslogback 会自行热加载不必立刻重启。验证观察日志目录几小时后应出现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固定是filecount10,filesize10M即最多约 100MB属正常若怀疑它异常单独du -h看这一项即可别和主日志混在一起判断。进阶扩展磁盘水位监控主服务带cluster.stats开关TB_CLUSTER_STATS_ENABLED配合系统侧的磁盘告警可以提前在日志快满前收到通知而不是等它打爆。审计日志单独控audit-log支持按实体设logging-levelOFF / 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），仅供参考