KETTLE日志记录、任务巡检、邮件发送
1. KETTLE日志记录配置实战
第一次接触KETTLE日志记录时，我也被那些专业术语搞得一头雾水。但经过几个项目的实战，我发现这套机制其实特别实用。想象一下，你手上有几十个定时任务在跑，如果没有完善的日志系统，排查问题就像大海捞针。
配置日志记录的第一步是建表。我建议直接在项目数据库里新建三张表：转换日志表、步骤日志表和性能日志表。字段设计可以参考KETTLE自带的模板，具体操作是打开任意ktr文件，右键空白处选择"转换设置"，在"日志"选项卡里能看到所有标准字段。比如我的转换日志表通常包含这些核心字段：
- 转换名称
- 执行状态
- 开始/结束时间
- 读取/写入行数
- 错误信息
建表完成后，在ktr文件的"转换属性"里配置日志连接。这里有个小技巧：把日志间隔设为1秒（默认是60秒），这样数据库里就能实时看到最新状态。我遇到过因为间隔太长导致问题发现不及时的情况，调整后监控效果明显提升。
2. 数据库日志的进阶玩法
基础配置只是开始，真正发挥日志价值还需要些技巧。我习惯在日志表里添加几个自定义字段：
- 服务器IP（区分多节点执行）
- 业务日期（方便按周期统计）
- 执行耗时（性能分析用）
这些字段需要通过"设置变量"步骤在转换开始时注入。比如用"获取系统信息"步骤获取服务器IP，再用"SQL脚本"步骤写入日志表。实测下来，这种增强型日志能让后期分析效率提升3倍以上。
日志清理策略也很重要。我推荐两种方案：
- 按时间保留：比如只保留最近30天日志
- 按空间保留：当日志表超过10万行时自动清理最早记录
可以在数据库里创建定时任务执行清理SQL，或者直接用KETTLE的"执行SQL脚本"步骤在每次转换开始时检查。
3. 异常数据捕获实战指南
数据同步最头疼的就是目标表约束导致的失败。上周我就遇到个典型case：源系统某个字段突然从50字节扩容到100字节，但目标表没同步修改，导致每天凌晨任务失败。
我的解决方案是"错误数据双保险"机制：
- 主错误输出：所有出错数据实时写入Excel
- 辅助日志：错误摘要写入数据库日志表
具体配置时要注意：
- Excel文件名要包含时间戳（如error_20230815_0230.xlsx）
- 添加"过滤记录"步骤区分不同类型错误
- 用"Excel输出"步骤的"包括日期时间"选项
这里有个实用技巧：在"文本文件输出"步骤里勾选"创建父目录"，这样就不用手动建目录了。我吃过好几次因为目录不存在导致任务失败的亏。
4. 智能邮件告警系统搭建
邮件告警看似简单，实际配置时坑不少。先说最重要的安全配置：
- 一定要用授权码而不是邮箱密码
- 建议单独创建监控专用邮箱
- 启用SSL加密连接
我的邮件模板通常包含三部分内容：
- 基础信息：任务名称、执行时间、状态
- 关键指标：处理行数、耗时、错误数
- 详细日志：最近3条错误信息
进阶玩法是添加附件功能。把当天的错误数据Excel和日志截图打包发送，收件人直接就能分析问题。配置时记得设置附件大小限制，避免邮件被拒收。
5. 巡检报告自动化生成
单纯的邮件通知还不够，我们需要更智能的巡检报告。我的方案是每天凌晨自动生成PDF报告，包含：
- 24小时任务执行概览
- 错误类型分布图
- 性能TOP10排名
实现步骤：
- 用"表输入"步骤查询日志数据
- "JavaScript"步骤处理统计数据
- "Pentaho Reporting"步骤生成PDF
- "邮件"步骤定时发送
这里有个性能优化点：给日志表的关键字段建索引。我之前有个报表查询要跑5分钟，加了复合索引后只要8秒。
6. 常见问题排查手册
根据我踩过的坑，整理几个典型问题：
- 日志表没数据
- 检查数据库连接是否正常
- 确认日志级别不是"Basic"
- 查看转换是否设置了跳过日志
- 邮件发送失败
- 检查SMTP端口是否正确（465或587）
- 确认防火墙没拦截
- 测试telnet连接SMTP服务器
- Excel文件乱码
- 设置文件编码为UTF-8
- 避免特殊字符作为文件名
- 检查服务器区域设置
最近遇到个奇葩问题：日志突然不记录了。最后发现是数据库连接池满了，调整最大连接数后解决。这类问题建议在转换开始时添加ping检测。
7. 性能监控与优化
当任务量上来后，性能问题就凸显了。我常用的监控指标包括：
- 单任务平均耗时
- 资源占用率
- 并发任务数
优化手段举例：
- 大事务拆分为小批次
- 合理使用commit size
- 避免全表查询
有个特别实用的技巧：在"表输入"步骤使用变量替换SQL。比如：
SELECT * FROM orders WHERE create_date >= '${DATE_FROM}'这样就能实现动态查询，不用每次修改转换。
8. 企业级部署建议
在生产环境部署时，我推荐这些最佳实践：
- 日志库单独部署，避免影响业务库
- 建立归档机制，冷数据定期转储
- 实现日志分级（DEBUG/INFO/ERROR）
- 添加操作审计日志
对于集群环境，要考虑：
- 日志集中存储
- 节点心跳检测
- 负载均衡策略
最近帮客户设计了一套高可用方案：主节点挂掉后，备用节点自动接管任务，同时触发邮件告警。关键是在转换里添加心跳检测步骤，用"检测空流"判断主节点状态。