Grafana OnCall 中 Alert Group 自动消警异常问题分析

问题现象

在使用 Grafana OnCall 告警管理平台时，发现系统出现了大量重复的告警组，且这些告警组无法自动消警。经过深入排查，发现这些告警没有被正确分组。

具体表现为：当尝试通过修改告警状态为"resolved"来消警时，系统没有自动关闭原有的告警组，而是创建了一个新的已消警状态的告警组。然而，当使用"firing"状态的相同告警负载时，却能正确地将新告警添加到原有的告警组中。

技术分析

从技术角度来看，这个问题涉及 Grafana OnCall 的告警分组和消警机制：

1. 告警分组机制：Grafana OnCall 使用 groupKey 来识别和分组相关告警。在测试案例中，groupKey 为 {}/{type="hermes-heartbeat"}:{frp="10859"}，这表明系统应该基于 type 和 frp 标签值来分组告警。

2. 消警流程：当收到状态为"resolved"的告警时，系统应该：

   • 匹配现有的告警组
   • 更新告警组状态
   • 关闭相应的告警

3. 异常行为：在问题案例中，消警请求没有匹配到现有的告警组，而是创建了新的告警组，这表明分组机制在消警场景下出现了异常。

根本原因

经过进一步调查，发现问题出在路由模板配置上。用户配置了条件路由模板：if {{payload.status = firing}}，这导致：

1. 当告警状态为"firing"时，能正确路由到现有告警组
2. 当告警状态为"resolved"时，由于路由条件不匹配，系统无法找到原有告警组，只能创建新的告警组

解决方案

要解决这个问题，可以采取以下措施：

1. 检查路由配置：确保路由模板能够正确处理所有告警状态（firing 和 resolved）
2. 修改路由条件：移除或调整过于严格的状态过滤条件
3. 测试验证：在修改配置后，通过模拟 firing 和 resolved 状态告警来验证功能是否正常

最佳实践建议

为了避免类似问题，建议在使用 Grafana OnCall 时：

1. 全面测试：在部署前测试所有可能的告警状态场景
2. 谨慎使用路由条件：避免在路由模板中使用过于严格的过滤条件
3. 监控告警生命周期：定期检查告警的分组和消警情况
4. 记录配置变更：保持配置变更的详细记录，便于问题排查

总结

这个案例展示了告警管理系统中一个常见但容易被忽视的问题 - 路由配置不完整导致的消警异常。通过这个案例，我们可以认识到告警管理不仅仅是简单的接收和显示告警，还需要精心设计告警的路由、分组和生命周期管理策略。正确的配置对于确保告警系统的可靠性和有效性至关重要。