1. 为什么你的DolphinScheduler磁盘又满了不知道你有没有遇到过这种情况某天早上收到监控告警说生产环境的服务器磁盘使用率超过90%了紧急登录服务器一看好家伙/opt/dolphinscheduler/logs目录下塞满了各种dolphinscheduler-api.*.log、dolphinscheduler-worker.*.log文件动辄几十上百个G把宝贵的磁盘空间吃得一干二净。这场景我经历过不止一次尤其是在任务调度频繁、流程复杂的生产环境中Apache DolphinScheduler 作为我们数据开发流程的核心引擎每天产生的日志量是惊人的。很多刚接触 DolphinScheduler 的朋友可能会疑惑日志不是会自动滚动吗是的DolphinScheduler 默认使用 Logback 作为日志框架它确实有滚动机制。但问题就出在“默认”配置上。默认情况下日志文件会保留168天将近半年每个文件达到64MB才会滚动切割一个新文件。想象一下一个每天处理上千个任务的工作流每个任务、每个服务节点都在写日志用不了多久日志目录就会像滚雪球一样膨胀起来。这不仅仅是磁盘空间的问题过多的日志文件还会影响文件系统的检索性能甚至在日志收集、备份时带来额外的网络和存储开销。所以告别磁盘告急的第一步不是等满了再去手动删而是建立一套自动化、精细化的日志生命周期管理策略。这就像家里的垃圾桶你不能等它溢出来了才想起来倒最好是设置一个固定的清理频率和容量上限。今天我就把自己在实际运维中摸爬滚打总结出来的两套“组合拳”分享给你一是调整Logback的滚动策略从源头控制日志的生成二是结合操作系统的定时任务设置一个兜底的清理机制。双管齐下确保你的调度系统既能留下足够的问题排查线索又不会让日志成为“磁盘杀手”。2. 第一招深入Logback配置从源头瘦身Logback 的配置文件是控制日志行为的“宪法”。DolphinScheduler 的日志配置分散在几个文件中主要位于安装目录的conf/文件夹下例如logback-api.xml、logback-master.xml、logback-worker.xml等分别对应 API Server、Master Server 和 Worker Server。我们的主战场就在这里。2.1 看懂核心参数maxHistory 和 maxFileSize打开任何一个logback-*.xml文件找到rollingPolicy标签你会看到类似下面的配置片段。这是整个日志滚动策略的核心。rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePattern${log.base}/dolphinscheduler-api.%d{yyyy-MM-dd_HH}.%i.log/fileNamePattern maxHistory168/maxHistory maxFileSize64MB/maxFileSize totalSizeCap1GB/totalSizeCap /rollingPolicy我来给你拆解一下这几个关键参数fileNamePattern定义了滚动后日志文件的命名规则。%d{yyyy-MM-dd_HH}表示按“年-月-日_小时”进行时间滚动%i是一个索引号用于解决同一小时内日志大小超限后需要切割多个文件的情况。maxHistory日志保留的最大天数。这是最需要关注的参数之一。默认值168意味着系统会保留过去168天内所有滚动生成的日志文件。对于生产环境保留半年通常太长了。我一般会根据实际需求调整比如重要生产环境保留30天测试环境保留7天。maxFileSize单个日志文件的最大体积。当日志文件达到这个大小时即使时间窗口比如当前小时还没过Logback 也会立即切割一个新文件并用%i递增索引。默认64MB对于高频任务来说可能偏大导致单个文件内容过多排查问题时翻阅不便。我常将其设置为10MB或20MB让文件更“轻量”。totalSizeCap所有日志文件总大小的上限。这是一个非常实用但容易被忽略的参数它并不是所有版本默认都显式配置的但我强烈建议你加上。它规定了该Appender生成的所有日志文件包括当前活跃文件和历史滚动文件所占用的磁盘空间总量上限。当总大小接近这个上限时Logback 会按照时间从旧到新的顺序删除最老的日志文件直到总大小低于上限。这是防止日志总量失控的终极保险丝。2.2 实战修改配置一个“自律”的日志策略光说不练假把式我们直接动手修改。假设我们的目标是保留最近30天的日志单个文件不超过10MB所有日志总量不超过5GB。我们以修改conf/logback-api.xml为例备份原文件这是一个好习惯。cp logback-api.xml logback-api.xml.bak编辑配置文件使用vi或你喜欢的编辑器打开文件。定位并修改参数找到APILOGFILE这个RollingFileAppender下的rollingPolicy部分将关键参数修改如下rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy !-- 按天滚动同一日期内按大小分割 -- fileNamePattern${log.base}/dolphinscheduler-api.%d{yyyy-MM-dd}.%i.log/fileNamePattern !-- 最多保留30天 -- maxHistory30/maxHistory !-- 单个文件最大10MB -- maxFileSize10MB/maxFileSize !-- 所有日志文件总大小不超过5GB -- totalSizeCap5GB/totalSizeCap /rollingPolicy这里有几个我踩过坑后总结的要点fileNamePattern的精度我把%d{yyyy-MM-dd_HH}改成了%d{yyyy-MM-dd}也就是从按小时滚动改成了按天滚动。为什么对于大多数场景按天滚动已经足够清晰而且能显著减少文件数量从最多24个/天变成1个/天。除非你的日志量极其庞大需要按小时分割来方便查找否则按天滚动是更清爽的选择。totalSizeCap的单位支持KB,MB,GB。确保书写正确。同步修改所有服务别忘了logback-master.xml、logback-worker.xml、logback-alert.xml等都需要进行类似的修改。每个服务的日志是独立的只改一个其他服务照样会“吃”掉你的磁盘。重启服务修改配置后必须重启对应的 DolphinScheduler 服务组件才能使配置生效。例如修改了 API 的配置就需要重启 API Server。你可以使用./bin/dolphinscheduler-daemon.sh stop api-server和./bin/dolphinscheduler-daemon.sh start api-server来完成。完成这一步你的 DolphinScheduler 就已经具备了初步的“自律”能力日志不会再无限制地野蛮生长了。3. 第二招联手Crontab设置兜底清理防线虽然调整 Logback 配置是治本之策但在复杂的生产环境中我们还需要一道额外的保险。比如万一totalSizeCap参数在某些旧版本不生效怎么办或者Logback 自身清理机制因为某些异常如磁盘inode耗尽而失效了呢这时候一个独立于应用之外的、操作系统层面的定时清理任务就显得非常可靠。它的思路很简单定期扫描日志目录无情地删除那些超过保留期限的旧文件。3.1 编写一个“冷酷无情”的清理脚本我们创建一个 Shell 脚本让它来执行清理工作。脚本的好处是逻辑清晰、可重复执行、易于加入定时任务。在服务器上找一个合适的位置比如/opt/scripts/创建文件ds_log_cleanup.sh#!/bin/bash # Apache DolphinScheduler 日志自动清理脚本 # 作者你的名字 # 功能删除指定目录下超过N天的指定模式日志文件 # 设置日志保留天数 RETAIN_DAYS7 # 设置DolphinScheduler的日志目录请根据实际安装路径修改 LOG_DIR/opt/dolphinscheduler/logs # 要清理的日志文件模式支持通配符 LOG_PATTERNS( dolphinscheduler-api.*.log dolphinscheduler-master.*.log dolphinscheduler-worker.*.log dolphinscheduler-alert.*.log ) echo 开始清理 DolphinScheduler 日志 [$(date %Y-%m-%d %H:%M:%S)] for pattern in ${LOG_PATTERNS[]}; do # 使用find命令查找并删除 # -type f: 只找文件 # -name: 匹配文件名模式 # -mtime $RETAIN_DAYS: 修改时间在 RETAIN_DAYS 天以前 # -delete: 执行删除操作先测试可以用 -print 查看会删除哪些文件 find $LOG_DIR -type f -name $pattern -mtime $RETAIN_DAYS -delete echo 已清理模式: $pattern (保留最近${RETAIN_DAYS}天) done echo 日志清理完成 [$(date %Y-%m-%d %H:%M:%S)] 脚本使用心法安全第一先“看”后“删”在第一次执行或修改模式后务必先将脚本中的-delete替换为-print运行一次看看它会列出哪些文件。确认无误后再改回-delete。这是避免误删重要日志的黄金法则。灵活设置保留天数脚本里的RETAIN_DAYS7表示保留最近7天的日志。这个天数应该与你 Logback 配置中的maxHistory协调一致且通常可以更短。例如Logback 保留30天作为应用层缓冲操作系统脚本保留7天作为强制兜底。这样即使 Logback 清理失败最坏情况也只有7天日志。赋予执行权限创建脚本后运行chmod x /opt/scripts/ds_log_cleanup.sh。3.2 交给Crontab让清理自动化脚本写好了总不能每天手动跑吧是时候请出 Linux 的定时任务神器——Crontab 了。编辑当前用户的crontab在命令行输入crontab -e。添加定时任务在打开的文件末尾添加一行。例如我们希望每天凌晨2点30分执行清理脚本并且将脚本的输出echo的内容记录到一个专门的日志文件中方便日后审计# 分 时 日 月 周 命令 30 2 * * * /bin/bash /opt/scripts/ds_log_cleanup.sh /var/log/ds_log_clean.log 21这行配置的意思是每天凌晨2点30分使用/bin/bash执行我们的清理脚本并将脚本的标准输出和标准错误都追加到/var/log/ds_log_clean.log这个文件中。保存并退出。Cron 服务会自动加载新的配置。进阶技巧如果你觉得每天清理一次还不够“精细”担心某些时段日志暴涨可以设置更频繁的清理比如每6小时一次0 */6 * * * ...。但要注意过于频繁的find操作对高负载磁盘可能有一定影响通常一天一次在深夜执行是完全足够的。4. 高级策略与避坑指南掌握了基本操作我们再来聊聊一些能让你显得更“老练”的高级策略和那些我亲自踩过的坑。4.1 按服务级别差异化配置不是所有日志都同等重要。在实际项目中我通常会对不同服务的日志采取不同的保留策略。Master/API Server日志这些日志记录了工作流定义、任务调度、系统交互等核心事件出问题时排查依赖度高。我会设置较长的保留期比如maxHistory: 30totalSizeCap: 10GB。Worker Server日志主要记录具体任务如Spark、Hive SQL的执行日志。这些日志通常更庞大且任务本身如果成功其日志的长期价值较低。我会设置较短的保留期比如maxHistory: 7totalSizeCap: 20GB因为总任务量大。Alert Server日志告警发送记录通常不需要长期保留maxHistory: 3可能就够了。在logback-worker.xml等文件中进行差异化配置可以实现更精细的磁盘空间管理。4.2 警惕隐藏的“日志巨兽”访问日志和GC日志除了应用业务日志还有两个地方容易遗漏API访问日志如果你启用了 DolphinScheduler API 的访问日志比如在logback-api.xml中配置了AccessLog相关的 Appender这部分日志增长也可能很快记得在清理脚本的LOG_PATTERNS数组里加上对应的模式如access_log.*。JVM GC日志在bin/dolphinscheduler-daemon.sh启动脚本中JVM 参数可能会配置-Xloggc:./logs/gc.log。GC 日志默认不会滚动时间一长就是个大家伙。你需要额外配置 JVM 参数来实现 GC 日志滚动例如使用-XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles5 -XX:GCLogFileSize10M或者在清理脚本中增加对gc.log*的清理。4.3 监控与告警让问题可视化配置好了不是一劳永逸。我建议将日志目录的磁盘使用率纳入你的监控系统如 Prometheus Grafana。设置一个告警规则比如当/opt/dolphinscheduler所在磁盘分区使用率超过80%时触发告警。这样你就能在用户抱怨系统变慢之前主动发现潜在的空间问题也许是因为某个任务突然疯狂报错产生了海量日志也许是你的清理脚本因为权限问题意外停止了。另一个有用的监控点是清理脚本的执行日志。我们之前把输出重定向到了/var/log/ds_log_clean.log。定期检查这个文件确保脚本每次都在成功执行。如果发现某天没有记录就要去排查 Crontab 服务或者脚本本身是否有问题。5. 效果验证与日常维护做完以上所有步骤怎么知道有没有效呢立即验证Logback配置重启服务后观察logs/目录下新生成的日志文件。文件名应该遵循你修改后的fileNamePattern例如包含日期2024-05-20。你可以手动写点日志比如触发几个任务看看文件大小快到maxFileSize如10MB时是否会正确滚动生成带%i索引的新文件如.0.log,.1.log。模拟测试清理脚本手动执行一下你的ds_log_cleanup.sh记得先用-print测试模式观察输出是否符合预期。可以手动用touch命令创建一些“过期”的日志文件来测试删除功能。观察磁盘空间变化使用df -h和du -sh /opt/dolphinscheduler/logs/命令在配置生效几天后对比一下目录大小的变化趋势。一个健康的趋势应该是大小在一个范围内波动而不是持续线性增长。日常维护就很简单了定期检查监控告警每隔几个月回顾一下日志保留策略看看是否需要根据业务变化调整maxHistory天数升级DolphinScheduler版本时注意备份并合并你的自定义logback-*.xml配置因为默认配置可能会被覆盖。说到底日志管理是运维工作中看似琐碎却至关重要的基础环节。一套好的日志滚动与清理策略就像给系统请了一个称职的“保洁阿姨”既能保持环境整洁又能在需要时找到重要的“旧物”。希望这份实战指南能帮你彻底摆脱磁盘告急的红色警报让你的 DolphinScheduler 运行得更稳健、更清爽。