本文展望了Prometheus Alertmanager，概述了理想的指标以及如何建立适当的阈值。
译自 Reduce Alert Fatigue and Improve Your Kubernetes Monitoring。
接受过多无关紧要或频繁出现的警报会导致警报疲劳状态。这种情况常见于警报无法操作、不相关或出现过于频繁的时候。
配置错误或基于错误假设的配置，以及没有服务级指标(SLO)的配置，会双重影响系统，导致警报疲劳，更严重的是可能会漏掉关键警报。
我们与200多个使用 Prometheus Alertmanager 的团队交流过。许多团队面临来自无实际操作建议的无关紧要警报带来的警报疲劳问题。
如今，为整个基础设施设置监控已经不是难事了，但是我们该如何应对警报疲劳，既确保不漏掉关键警报，又能对指标和阈值做出明智选择呢？
让我们深入研究 Prometheus Alertmanager。我们将概述理想的指标，并提供建立适当阈值的指导。
Prometheus 是一个开源的监控系统，它具有动态查询语言、高效的时间序列数据库和前沿的警报方式。
它的配套应用Alertmanager拦截Prometheus等客户端应用发送的警报，并处理重复数据、分组和精确路由。Alertmanager可通过电子邮件、Slack、Zenduty或PagerDuty等集成无缝地将警报发送到指定收件人。
Prometheus和Alertmanager共同提供了一个强大而现代的监控解决方案，可以帮助改进事件响应、减少警报疲劳并确保系统可靠性。
它提供多种功能，可以精确过滤、分组、路由、静音和抑制警报。
可以使用标签和表达式等条件过滤和分组警报，专注于关键问题，然后发送到合适的目的地如电子邮件、Slack等，以确保通知相关人员。
另外，在关键事件期间可以暂时静音警报，以防止过多通知；并根据特定条件抑制警报，以防止冗余和非关键通知。
既然我们已经了解了Prometheus Alertmanager的功能，让我们来研究如何定义有效的Prometheus指标。
Prometheus Alertmanager是一个强大的工具，但前提是您要正确使用它。想象一下，如果您没有为Kubernetes集群设置任何警报。
那将是一个巨大的错误。但是设置过少的警报或缺少关键指标同样糟糕。太多错误标记或没有必要的信息过载也会导致警报疲劳。
设置精确的阈值警报是实现可靠性和无缝操作的秘密。
但是问题是: 一个配置良好的Prometheus Alertmanager应该什么样?
这里有一些您应该考虑的特征:
- 定义明确 - 指标应该有清晰简洁的定义。这将帮助团队理解指标的测量目标和如何使用它。
- 可操作 - 被警报吵醒可能让人不安，尤其是当您不确定如何响应或无法控制时。这就是为什么要有可操作的指标非常重要。当您收到警报时，应该清楚地知道需要采取哪些步骤来解决根本问题并有效解决它。
- 有信息量 - 在设置Alertmanager指标时，应提供有关所监控的系统或应用程序的有价值信息。这些详细信息可用于识别和解决问题、改进性能并确保系统的整体运行状况和可靠性。
- 有影响 - 工程师不会希望被对业务无影响的事情叫醒。警报应该与可能影响业务的事情相关。如果您不确定警报是否重要，请谨慎地不要警报。
每个组织都应该关注特定的Prometheus Alertmanager指标并为它们设置警报。
例如，需要监控的一些基本内容:
- 监控1分钟内4xx和5xx请求的数量非常重要。如果所有请求中有60%以上是4xx，则触发通知。此外，区分500和400也至关重要。检测到500时设置警报。
- 当您的Horizontal Pod Autoscaler(HPA)接近其最大容量时，创建一个警报来发送通知。
- 为容器CPU使用率建立与您的基准和预期响应时间相符的警报阈值。这可以确保对任何异常的资源消耗进行及时通知。
- 确保您已经配置了一个内存不足警报，当pod面临内存问题和终止风险时触发。这有助于防止由于内存限制导致的关键故障。
- 检测到过多带5XX的请求返回，可以帮助系统/代码更改与丢弃的请求相关联。
除了提到的指标之外，我们还建议组织考虑几个其他必要的指标，比如:
- 监控5分钟内发生的节点上下文切换次数。当此计数超过5000时，触发通知。
持续高的上下文切换表示需要切换到内存优化(RAM)实例，而不是长期坚持当前配置。上下文切换通常在基准测试阶段使用。
不监控此指标会使我们对性能问题一无所知。如果我们的性能始终匹配我们的通常基准，我们可以将监控频率从每5分钟减少到每30分钟，以减少不必要的警报。
- 设置一个警报，当pod数量下降到低于某个阈值时通知团队。
对于可能面临物理pod关闭的产品团队来说，此警报可以是基本的生命线，通知团队此类故障。
当pod达到最小阈值容量时，此警报将触发。对于按比例运行且预计资源消耗低的产品，这将是一个持续的噪音来源。
- 如果您不知道某些事情已经出错，您将如何发现出了什么问题？
有时我们可能过度依赖自动化，并忘记我们需要跟踪自动重启。一个常被忽视的基本警报是没有警报pod重启。这一警报可以成为将其他服务修改与潜在延迟关联起来的有价值工具。
-
将不受支持的节点连接到集群会导致意外的行为，并使故障排除变得困难。为了防止这种情况，请在附加不受支持的节点时设置警报。
-
强烈建议监控Prometheus正在抓取的内容。如果Prometheus内存不足，您的Prometheus实例可能会变得不稳定或经常重启，从而导致警报延迟。
Alertmanager指标至关重要，但它们只是方程式的一部分。另一半是正确配置阈值。
设置过低的阈值会导致对细微指标变化的大量警报，从而造成警报疲劳。相反，如果阈值过高，重要的警报可能会被漏掉。
请记住: 理想的阈值根据您的基础设施和业务需求而有所不同。
为Alertmanager设置正确的阈值以减少警报疲劳
- 配置Alertmanager指标时，请查看和调整速率限制设置和等式。花点时间理解预期行为，并考虑如何抓取指标，因为这种方法会显著影响设置过程。
- 查看谁接收警报通知非常重要。确保通知到正确的人。在这里适当地区分警报至关重要。用不必要的警报压垮您的工程师会对他们的表现和整体生产力产生负面影响。
- 理解设置警报的目的。有时对特定指标的警报可能是不必要的，从而导致不必要的警报。在配置警报之前，问自己: 这个警报旨在指示什么？这种明确性将帮助确保警报有意义和有价值。
- 配置警报方程式时，对指标进行彻底分析以识别潜在缺陷非常重要。
定期进行统计分析，以了解指标的交互方式及其如何影响系统性能。弄清楚哪些系统可能会受到警报的影响非常重要。这种前瞻性方法可以让您在问题升级为完全发作的事件之前解决潜在问题，确保流畅的操作并最大限度地减少中断。
- 认识到某些警报是可以预期的，不应视为不寻常。为了防止警报疲劳，考虑为这些预期警报静音通知。这种战略性方法确保您的团队保持对关键问题的关注，同时减少不必要的噪音和干扰。
在Zenduty，我们提供与150多个应用程序和监控工具的集成。然而，一个最常用但配置错误的集成是Prometheus Alertmanager。我们的一位早期客户曾说过:“Prometheus Alertmanager的效果过于出色。”
虽然这可能是真的，但就目前而言，这就是我们所拥有的一切。
我们认为，这些策略应该能帮助您的团队有效应对警报疲劳，使工程师能够在Prometheus Alertmanager中建立准确的阈值和警报。
这些对您有用吗?我们错过了什么重要的东西吗?我们渴望了解您配置指标和阈值以应对警报疲劳的方法。通过contact@zenduty.com与我们分享您的见解。