Prometheus中alert_relabel_config导致告警误统计问题分析

问题背景

在Prometheus监控系统中，用户配置了alert_relabel_configs规则来过滤特定告警时，发现prometheus_notifications_dropped_total指标异常增长。这个指标原本用于统计未能成功发送到Alertmanager的告警数量，但在有意识地通过relabel规则丢弃告警时，该指标也会被错误地计数。

技术原理分析

Prometheus的告警处理流程中，alert_relabel_configs配置允许用户在告警发送到Alertmanager之前对告警进行重新标记或过滤。当配置了action: drop规则时，符合特定条件的告警会被系统主动丢弃。

问题的核心在于notifier.sendAll()方法的实现逻辑。该方法在处理告警时：

1. 首先对每个Alertmanager应用relabel规则
2. 如果relabel后告警列表为空，则跳过该Alertmanager
3. 最终统计成功发送的Alertmanager数量

当所有Alertmanager都因为relabel规则而跳过时，系统错误地将这种情况视为"发送失败"，导致prometheus_notifications_dropped_total指标增加。

影响范围

这一行为会导致以下问题：

1. 监控指标失真：主动丢弃的告警被误统计为发送失败
2. 告警质量下降：无法区分真正的发送失败和有意过滤的告警
3. 运维复杂度增加：难以通过指标判断Alertmanager的实际健康状况

解决方案

该问题已在Prometheus的代码修复中通过以下方式解决：

1. 修改指标统计逻辑，区分主动丢弃和发送失败
2. 确保prometheus_notifications_dropped_total仅统计非预期的发送失败
3. 为主动丢弃的告警添加专门的统计指标

最佳实践建议

对于需要在Prometheus中过滤告警的用户，建议：

1. 明确区分业务过滤和系统故障：为不同的过滤目的使用不同的标签
2. 监控告警流程：同时关注发送成功和主动过滤的指标
3. 合理配置relabel规则：避免过度使用全局drop规则
4. 升级到修复版本：确保使用包含此修复的Prometheus版本

总结

Prometheus的这一行为修正体现了监控系统设计中的一个重要原则：系统指标应该准确反映系统状态，而不应包含用户预期的行为。通过这次修复，用户可以更准确地监控告警发送流程，及时发现真正的系统问题，而不被预期的过滤行为所干扰。