send_resolved 参数是 Alertmanager 中用于控制告警通知行为的一个重要配置项。当您在 Alertmanager 的路由规则、接收器组或模板中设置此参数时，它会影响到告警状态从“触发（firing）”变为“解决（resolved）”时，Alertmanager 是否向相应的接收器发送通知。

参数详解：

  • 名称： send_resolved
  • 类型： 布尔值 (true 或 false)
  • 默认值： 通常为 true （具体取决于 Alertmanager 版本和配置）

功能描述：

send_resolved 参数决定了当一个告警从活跃状态（即问题已存在且被检测到）转变为非活跃状态（即问题已解决或不再存在）时，Alertmanager 是否应向指定的接收器（如邮件、Slack、PagerDuty 等）发送一条告警解决的通知。

  • send_resolved: true
    当设置为 true 时，当告警状态从“触发”变为“解决”时，Alertmanager 会向关联的接收器发送一条告警解决的通知，告知相关人员问题已被解决或已恢复正常。这对于确保运维人员了解问题的完整生命周期，及时跟进问题处理进度，以及确认系统恢复常态非常有帮助。
  • send_resolved: false 当设置为 false 时，即使告警状态变为“解决”，Alertmanager 也不会发送解决通知。这种配置适用于以下情况：
  • 减少通知噪音： 在某些场景下，运维团队可能更关注新出现的问题而非问题的解决过程，频繁的解决通知可能会造成信息过载，干扰关键信息的识别。
  • 特定告警策略： 对于某些不那么关键或者自我恢复能力较强的告警，运维团队可能仅关心首次触发通知，而不关心后续的解决状态。
  • 外部工具集成： 如果您的监控系统已经通过其他方式（如事件管理系统、服务状态页面等）清晰地展示了告警的解决状态，那么来自 Alertmanager 的解决通知可能就显得多余。

示例配置：

在 Alertmanager 的 YAML 配置文件中，您可以在路由规则、接收器组或模板级别设置 send_resolved 参数。以下是一个在接收器组级别设置的例子：

receivers:
- name: 'critical-alerts'
  email_configs:
  - to: 'critical-team@example.com'
  send_resolved: true

- name: 'non-critical-alerts'
  email_configs:
  - to: 'non-critical-team@example.com'
  send_resolved: false

在这个例子中，当“critical-alerts”接收器组中的告警被解决时，会向 critical-team@example.com 发送解决通知；而“non-critical-alerts”接收器组中的告警解决时，则不会发送任何通知。

总结来说，send_resolved 参数允许您根据实际需求自定义 Alertmanager 的告警解决通知行为，以适应不同的团队协作模式、告警管理策略和通知偏好。