ThingsBoard 日志管理完整指南3 步解决日志膨胀与磁盘告警【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard凌晨三点磁盘使用率告警把值班同事叫醒排查下来发现是/var/log/thingsboard下的日志文件撑爆了分区。ThingsBoard 这类物联网平台设备连接多、数据流大日志增长本来就快好消息是它的日志路径、轮转策略在代码里全是写死的约定只要按下面三步走一遍你就能让 ThingsBoard 日志自动就位、定期清理、空间可控全程不需要动仓库里任何一行代码。从告警到自动清理我们要做成什么样先说清楚最终效果这样后面每一步你都知道自己在补哪块拼图目录就位/var/log/thingsboard存在、属主正确、可写日常轮转单个文件超 100MB 或跨天时自动切分总盘子不超过 3GB兜底保险系统级 logrotate crontab每天凌晨再清一次历史文件。三条线里第 2 条是 ThingsBoard 自带的前两条和后一条需要你在服务器上做一次性配置。下面按操作顺序拆。第 1 步确认日志目录就位且可写这一步解决日志到底去哪了的问题。ThingsBoard 所有服务的日志目录都来自同一个 Maven 变量定义在根目录 pom.xml 里pkg.unixLogFolder/var/log/${pkg.name}/pkg.unixLogFolder也就是说主服务、MQTT/HTTP 传输、各 integration 进程日志统统落在/var/log/thingsboard。用 deb/rpm 包安装时postinst 脚本会自动mkdir -m 0755并把属主改成运行账号这一步通常不用你操心。但如果是解压部署或目录被清理过建议手动确认一次ls -ld /var/log/thingsboard sudo -u thingsboard touch /var/log/thingsboard/.write-test执行后第一行应该看到drwxr-xr-x thingsboard thingsboard /var/log/thingsboard第二条命令无任何报错。为什么强调属主因为启动脚本在检测到LOG_FOLDER不可写时会静默回退到/tmp逻辑见 启动脚本模板日志照写、只是你不一定马上发现。第 2 步让内置 logback 滚动策略接管日常清理目录就位后先看看 ThingsBoard 自己已经替你做了什么——答案比想象中多。主服务的 logback.xml 配置了SizeAndTimeBasedRollingPolicy关键参数如下maxFileSize100MB/maxFileSize !-- 单文件超 100MB 切分 -- maxHistory30/maxHistory !-- 保留 30 天 -- totalSizeCap3GB/totalSizeCap !-- 日志总上限 3GB超出自动删最旧的 --同目录下每个传输/集成服务transport/、msa/integration/等模块的conf/logback.xml都是同一套策略不用逐个改。另外 JVM 的 GC 日志也由 thingsboard.conf 中的JAVA_OPTS控制自带filecount10,filesize10M的封顶。怎么验证轮转在生效观察目录里的文件名ls -lh /var/log/thingsboard/正常运行一段时间后你会看到thingsboard.log旁边出现thingsboard.2026-10-16.0.log这样的日期命名文件最旧的超过 30 天或被totalSizeCap挤掉时会自动消失。到这里日常清理就算成功了一半——剩下的兜底交给下一步。第 3 步加一道系统级 logrotate 保险 定时任务logback 的清理依赖进程活着如果服务长期重启失败、或者你开了SQL_LOG_QUERIES这类调试开关导致文件暴涨还有一层保险可用系统 logrotate。它管的是目录里所有*.log与 Java 进程无关。创建/etc/logrotate.d/thingsboard这是系统目录不在仓库内/var/log/thingsboard/*.log { weekly rotate 8 compress delaycompress missingok notifempty copytruncate create 0644 thingsboard thingsboard }copytruncate是关键先复制再清空避免 Java 进程还握着旧文件句柄导致磁盘空间回收不了。然后挂上每天凌晨 3 点的定时任务crontab -e0 3 * * * /usr/sbin/logrotate -s /var/lib/logrotate/thingsboard.status /etc/logrotate.d/thingsboard手动跑一次验证执行/usr/sbin/logrotate -d /etc/logrotate.d/thingsboard-d是 dry-run输出里出现rotating pattern /var/log/thingsboard/*.log且无 error就说明配置解析正确。顺手把日志源头调小保险配好后建议同时把产日志的口子收紧。核心配置在 thingsboard.yml 中都通过环境变量覆盖不需要改文件本身# SQL 慢查询日志默认只记录超过 5 秒的查询 log_queries_threshold: ${SQL_LOG_QUERIES_THRESHOLD:5000} # 租户统计日志默认开启每分钟一条 log_tenant_stats: ${SQL_LOG_TENANT_STATS:true} # 集群统计默认关闭集群部署排查节点间消息量时可临时打开 cluster: stats: enabled: ${TB_CLUSTER_STATS_ENABLED:false} print_interval_ms: ${TB_CLUSTER_STATS_PRINT_INTERVAL_MS:10000}平时保持TB_CLUSTER_STATS_ENABLEDfalseMQTT 传输这类服务还有独立的传输层日志开关细节见 tb-mqtt-transport.yml。原则是排障时打开、排完就关别让调试日志成为常态。验证与两个高频坑全部做完后你可以按这个清单自检# 1. 目录属主与权限 ls -ld /var/log/thingsboard # 2. 轮转文件是否按日期生成 ls -lh /var/log/thingsboard/ # 3. 定时任务是否在册 crontab -l三个命令分别对应前文三步目录正常、有日期轮转文件、crontab 里有那条 3 点任务——三个都通过这套日志管理就算闭环了。最后提醒两个坑日志目录不可写会静默降级启动脚本发现LOG_FOLDER不可写时会改用/tmp服务看起来一切正常。如果你发现/var/log/thingsboard迟迟没有新文件先去检查目录权限和属主。gc.log不归 logrotate 管GC 日志由 JVM 参数自己滚动10 个文件 × 10MB 封顶logrotate 配置里的*.log匹配到它也无副作用但别指望改 logrotate 就能控制它。回到最初的告警现在再遇到磁盘告警第一反应不再是日志又涨了目录有兜底创建、轮转有 3GB 封顶、凌晨还有系统级清理。建议你本周就做两件事——把TB_CLUSTER_STATS_ENABLED和调试类日志开关检查一遍只保留必要的输出下个月再看一次ls -lh /var/log/thingsboard确认体积稳定在预期范围内。【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考