Pentaho Data Integration V7 Channel日志表异常：手动正常，夜间批量失效

核心问题定位 #

先明确关键现象：

• 仅10小时长耗时的批量调度作业出现Channel日志缺失，手动运行、短作业单独调度均正常
• Job、Transformation日志正常，说明日志表基础配置生效
• Channel日志需作业完成后写入，推测长作业触发了未被察觉的超时或资源回收机制

排查与修复步骤 #

1. 调整Kettle日志超时参数 #

修改kettle.properties文件或作业启动参数，调整以下关键配置：

• KETTLE_LOG_TIMEOUT_MINUTES：默认时长可能偏短，改为大于作业运行时间（比如设为720，对应12小时）
• KETTLE_MAX_LOG_SIZE_IN_LINES：若日志行数过多触发截断，调大该值（比如1000000）
  启动作业时可通过参数强制指定：

kitchen.sh -file:/path/to/main.job -param:KETTLE_LOG_TIMEOUT_MINUTES=720

2. 检查数据库连接超时设置 #

Channel日志写入依赖数据库连接，需确认：

• 数据库连接池的maxIdle、maxWait参数足够大，避免长作业过程中连接被回收
• 关闭数据库的连接超时自动断开机制（比如MySQL的wait_timeout，需设为远大于10小时）

3. 拆分长作业为分段执行 #

把10小时的主作业拆成多个短作业段，通过调度器依次触发：

• 每个子作业完成后立即写入Channel日志，避免单作业长时间运行触发未知超时
• 用主作业的Success分支触发下一段作业，保证任务链完整性

4. 启用Debug日志追踪异常 #

作业启动时添加日志级别参数，捕获Channel日志写入的细节：

kitchen.sh -file:/path/to/main.job -level:DEBUG -logfile:/path/to/debug.log

查看debug.log中是否有ChannelLogTable相关的错误信息（比如数据库写入失败、连接断开等）

5. 排查调度器资源限制 #

确认夜间调度时服务器状态：

• 避免调度器在作业运行期间重启Kettle进程
• 检查服务器内存、CPU是否在作业运行时被耗尽，导致日志写入线程被终止

内容的提问来源于stack exchange，提问作者Cristina