Metabase告警系统异常排查：定时通知发送失败问题深度分析

问题现象

在Metabase v0.54.1版本中，用户报告定时告警功能出现间歇性失效。具体表现为：

1. 系统日志显示notification-trigger任务状态为"success"
2. 前端"Tasks"界面显示任务执行成功
3. 实际未收到任何邮件/Slack通知
4. 手动触发"Send now"功能可正常发送

技术背景

Metabase的告警系统采用分层架构：

1. 调度层：基于Quartz的定时任务系统
2. 触发层：notification-trigger负责执行预定的SQL查询
3. 发送层：通过notification-handler处理具体发送逻辑
4. 日志系统采用Log4j2实现多级别日志记录

问题定位过程

通过分析用户提供的日志和数据库信息，发现以下关键现象：

1. 日志显示矛盾：

2025-04-14 09:00:00 INFO 发送通知35
2025-04-14 09:00:00 INFO 跳过: :empty
2025-04-14 09:00:00 INFO 发送成功

2. 数据库查询异常：

SELECT * FROM notification_handler 
WHERE notification_id = 35 -- 返回空结果集

3. 并发问题迹象：

• 每小时有40+告警集中触发
• 默认线程池大小(MB_NOTIFICATION_THREAD_POOL_SIZE)仅为3

根本原因

经过深入分析，确定问题由以下因素共同导致：

1. 处理程序丢失：

• 数据库中的notification_handler记录异常消失
• 升级过程中可能存在数据迁移缺陷

2. 并发控制缺陷：

• 大量告警集中触发导致线程池耗尽
• 系统错误地将排队任务标记为"success"

3. 日志误导：

• "Sending notification"日志实际表示任务入队
• 真正的发送过程日志为"Sent successfully"

解决方案

建议从三个维度进行修复：

1. 临时解决方案

# 增加并发处理能力
export MB_NOTIFICATION_THREAD_POOL_SIZE=10

2. 配置优化

<!-- log4j2.xml配置示例 -->
<Loggers>
  <Logger name="metabase.notification" level="DEBUG"/>
  <Logger name="metabase.channel" level="DEBUG"/>
  <PatternLayout pattern="%d %p %c{1.} %notEmpty{%X }%m%n"/>
</Loggers>

3. 长期修复方案

代码层面需要：

1. 修复handler记录丢失问题
2. 改进任务状态跟踪机制
3. 优化日志输出准确性
4. 增加并发控制策略

最佳实践建议

1. 告警调度策略：

• 避免整点集中触发
• 采用分时调度（如:05/:15/:25）

2. 监控配置：

-- 监控handler完整性
SELECT n.id, COUNT(h.id) AS handler_count 
FROM notification n
LEFT JOIN notification_handler h ON n.id = h.notification_id
GROUP BY n.id
HAVING COUNT(h.id) = 0;

3. 容量规划：

• 每100个告警约需1GB内存
• 线程池大小建议：核心数×2 + 缓冲数

总结

Metabase告警系统的稳定性取决于多个组件的协同工作。本次故障揭示了在高并发场景下任务调度、数据处理和日志记录等多个环节的潜在风险。通过优化系统配置和改进代码实现，可以显著提升告警功能的可靠性。建议用户在升级前充分测试告警功能，并建立完善的监控机制。