企业官网建设流程全解析

ThingsBoard 日志治理指南：内置轮转 + logrotate 定时清理 3 步落地

【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard

ThingsBoard 是 All-in-one IoT Platform（设备管理、数据采集、处理与可视化的物联网平台），跑满几周后，它的日志目录常常就是吃掉磁盘的那块。好消息是它自带日志滚动策略，你不需要从零搭方案。读完整篇，你会拿到三样东西：一套已生效的内置滚动参数核对清单、一份可直接粘贴的 logrotate 配置、一条每天 3 点自动执行的清理任务。

先看懂 ThingsBoard 内置的滚动策略

滚动参数在 logback.xml 里

服务启动时加载 application/src/main/conf/logback.xml，所有写盘日志都走这里面的RollingFileAppender。关键四行参数：

<maxFileSize>100MB</maxFileSize> <maxHistory>30</maxHistory> <totalSizeCap>3GB</totalSizeCap>

单文件到 100MB 就切，最多留 30 个历史文件，总量超过 3GB 从最旧开始删。发现磁盘吃紧，先把这三行调小再重启服务，改完后看到.log文件尺寸不再超过 100MB 说明生效。

安装器会自动建好日志目录

包内 packaging/java/filters/unix.properties 把日志目录映射为${pkg.unixLogFolder}（对应发行版路径，Linux 上通常是/var/log/thingsboard），packaging/java/scripts/control/deb/postinst 里的mkdir -m 0755 -p和chown会在安装时把目录建好并交出写权限，不用你手动创建。

确认日志落盘位置与权限

从启动脚本反查真实路径

打开 application/src/main/conf/thingsboard.conf，第一行JAVA_OPTS里的${pkg.logFolder}占位符就是最终目录；同文件还挂了 JVM GC 日志：

export JAVA_OPTS="$JAVA_OPTS -Xlog:gc*,heap*,age*,safepoint=debug:file=@pkg.logFolder@/gc.log:time,uptime,level,tags:filecount=10,filesize=10M"

也就是说这个目录下同时有应用日志和gc.log，清理策略要一并考虑。

一条命令验证目录状态

执行下面命令检查目录是否存在、属主是否可写：

ls -ld /var/log/thingsboard && ls -lh /var/log/thingsboard | head

看到属主是服务运行账号且列表里出现.log文件，说明日志正在正常落盘；如果权限是只读，先把chown修正再谈后面的轮转。

给旧版本或自定义部署补一份 logrotate

ThingsBoard 当前版本靠 logback 自己滚动，仓库内没有现成的 logrotate 模板。若你跑的是老版本、或把日志交给了系统 logger，就手动补一份。把下面配置写到/etc/logrotate.d/thingsboard（路径换成你实际的日志目录）：

/var/log/thingsboard/*.log { daily rotate 7 compress delaycompress notifempty create 0644 thingsboard thingsboard }

其中daily按天切、rotate 7保留 7 份、delaycompress最近一份不压缩方便排障。写完用logrotate -d /etc/logrotate.d/thingsboard做干跑（dry-run，只打印动作不落盘），输出里没有error就算语法过关。

用 crontab 让清理任务自动跑

注册每天凌晨 3 点的轮转

执行crontab -e，在末尾追加：

0 3 * * * /usr/sbin/logrotate /etc/logrotate.d/thingsboard

保存后运行crontab -l，能看到这一行说明任务已注册；当晚查/var/log/thingsboard出现.gz压缩文件，就是第一次轮转成功。

顺手加一条存活自检

同一个 crontab 里追加健康检查，把 HTTP 状态码记进日志：

30 3 * * * curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/api/version >> /var/log/thingsboard/healthcheck.log

次日早上翻healthcheck.log看到200，说明服务和日志两条链路都活着。

进阶：调小日志体积并盯住集群统计

传输层日志怎么收

打开 transport/mqtt/src/main/resources/tb-mqtt-transport.yml 的log段：

log: enabled: "${TB_TRANSPORT_LOG_ENABLED:true}" max_length: "${TB_TRANSPORT_LOG_MAX_LENGTH:1024}"

设备上报报文太长是日志膨胀主因，把TB_TRANSPORT_LOG_MAX_LENGTH调小（比如 256）即可截断；HTTP、LwM2M 等传输层配置在transport/各模块下同构。

集群统计开关

application/src/main/resources/thingsboard.yml 中的cluster.stats.enabled默认关闭，开启后按print_interval_ms（默认 10 秒）把节点间消息量打进日志，多节点部署用它做容量观测最直观。SQL 侧还有log_queries_threshold（默认 5000 毫秒），慢到该阈值的查询才会记录，别把它调到 0。

到这里，内置滚动参数已核对、落盘目录验证过、logrotate 兜底写好、定时清理和存活自检都挂上了。接下来盯住磁盘水位曲线和凌晨 3 点的healthcheck.log，一周内应看到.gz文件按天累积、总量不再上涨。

【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址: https://gitcode.com/GitHub_Trending/th/thingsboard