• 告警
    • " level="2">应该告警什么
      • " level="3">在线服务系统
      • " level="3">离线处理
      • " level="3">批处理作业
      • " level="3">容量
      • Metamonitoring

    告警

    我们建议您阅读 My Philosophy on Alerting。它基于 Rob Ewaschuk 在 Google 的观察 -

    总结就是: 保持告警简单,告警能够显示症结所在, 有良好的控制台可以查明原因,避免出现无用的页面

    应该告警什么

    通过报告用户疼痛的症状,而不是试图捕获可能引起疼痛的所有可能方式,以使告警尽可能少。警告应链接到相关的控制台,并易于确定哪个组件有故障。

    允许告警有一个缓和时间,以适应可能出现的小尖头信号。

    在线服务系统

    通常会在堆栈中尽可能高的高延迟和错误率上发出警报。

    仅在堆栈中的一点上有延迟进行告警。如果较低级别的组件的速度慢于应有的速度,但总体用户延迟很好,则无需告警。

    有关错误率,请参见用户可见错误页面。 如果堆栈中有进一步导致错误的错误,则无需单独翻页。 但是,如果某些故障不是用户可见的,但严重到需要人工干预的程度(例如,您损失了很多钱),请添加要在这些故障上发送的页面。

    如果不同类型的请求具有不同的特征,则您可能需要告警,否则低流量类型的请求中的问题将被高流量请求淹没。

    离线处理

    对于离线处理系统,关键指标是数据通过系统需要多长时间,如果足够高以至于影响用户,则进行告警。

    批处理作业

    对于批处理作业,如果最近一次批处理作业还不成功,则可以告警,这将导致用户可见的问题。

    通常,这至少应足够用于批处理作业的 2 次完整运行。对于每 4 小时运行一次且需要一个小时的工作,10 小时是一个合理的阈值。如果您无法承受单次运行失败,请更频繁地运行作业,因为单次失败不需要人工干预。

    容量

    虽然这不是引起立即影响用户的问题,但接近容量通常需要人为干预,以避免在不久的将来发生中断。

    Metamonitoring

    确保监控正在运行是重要的。因此,需要有告警以确保 Prometheus 服务,Alertmanagers,PushGateways 和其他监控基础结构可用并正确运行。

    与往常一样,如果可以告警症结所在而不是原因,则有助于减少噪音。例如,从 PushGateway 到 Prometheus 到 Alertmanager 到邮件的黑盒测试告警比独立的每个告警都更好。

    用外部黑盒监控来补充 Prometheus 的白盒监控可以捕获原本看不见的问题,且在内部系统完全故障的情况下也可以作为备用。