告警规则及处理方法

平台相关的告警

在不同规模的集群中,会有不同数量的服务器和各种系统组件,小到几十个,大到成百上千个。

每天会有各种事件发生,有些是正常操作而产生的事件,然而有些是异常事件,是需要运维人员去关注的。

运维人员需要通过监控告警机制来发现集群中的异常情况,从而及时处理,避免造成损失。

在平台中,多云管理平台/运维告警 里提供了对平台组件和机器的异常发现机制,在告警策略里,可以针对不同的监控对象,配置不同的规则,来触发告警。

如果一台机器上运行了 Elasticsearch 或者 MySQL 等存储类的中间件,那么运维人员需要特别关注机器的磁盘使用率,当超过一定的使用率,需要通过邮件、钉钉等方式通知运维人员,运维人员需要去清理数据或扩大磁盘容量。

可以通过配置一条机器磁盘告警的策略来,来发现这种情况,如图所示:

磁盘告警示例

  • 告警名称:可以自定义一个名称,用于标示这个告警定义。
  • 告警集群:需要监控的目标所在的集群。这种情况下,就是需要监控的机器所在的集群。
  • 告警规则:通过添加规则按钮,可以添加一条或者多条触发告警的规则。通过类型模版可以一次性添加预先定义好的常见的一组告警规则,避免一个一个添加。
  • 沉默周期:是指在第一次触发告警后,多久时间内,如果有相同的告警,则不会再触发告警。避免因相同的异常事件的不断发生而触发多次告警通知,或者因正在处理的异常事件发出不必要的通知。
  • 选择群组/通知方式:Erda 系统将通知功能抽象为通知组,一个通知组里面可以包含多个成员或者是不同的通知方式。这里可以选择一个通知组,如果没有创建过通知组,则可以点击弹出的下拉列表底部的链接来创建通知组。

如果配置的通知方式是钉钉,那么当磁盘使用率过高时,通知的消息如下:

告警规则及处理方法 - 图2

部分告警消息,会附带一个详情链接,可以点击 查看详情 来打开详情页面,来查看更详细的信息。

如果一台机器因为各种原因,发生了故障,宕机了,这是一种相对比较严重的情况,那么可以配置一条机器状态的告警策略,当发生宕机时,运维人员能够及时的发现,从而进一步排查问题:

机器状态告警示例

当发生异常时的消息如下:

告警规则及处理方法 - 图4

如果平台是基于 Kubernetes 的,因为误操作或者是其他未知原因等,导致 Kubernetes 的某个组件异常退出了,那么可以配置如下规则来发现这种问题:

集群组件告警示例

当发生异常时的消息如下:

告警规则及处理方法 - 图6

可配置的告警策略还有很多,总体可以分为如下几类:

  • 机器相关的告警
  • 平台组件相关的告警
  • 平台 Addon 相关的告警
  • Kubernetes 组件相关的告警

告警的核心功能是能让我们发现问题,并能够有个初步的判断。有些异常是因为资源分配导致的,这种需要运维人员去清理或协调资源;然而有些告警消息,情况可能比较复杂,需要结合告警详情页面和对应的集群环境,来综合去分析得出结论。

总体来说,平台的告警消息是需要运维人员重点去关心的,有了这样的告警机制,平台可靠性才有进一步保证。

应用相关的告警

平台的稳定性是业务程序稳定运行的基础保障,平台相关的告警能确保基础平台的稳定性,那么业务程序的稳定性,同样也有对应的一组告警策略来保障。

一个服务可能会因为程序的Bug,或者无法正常访问第三方服务,又或者申请的内存资源不足等原因,导致异常的抛出,从而导致了服务不正常运行。

针对应用的告警机制,这个时候显得特别重要,运维人员、项目管理员等,可以不用每时每刻盯着屏幕看服务正不正常,只需要配置一些告警策略,就可以解放劳动力。

在平台上,在一个 Runtime 界面下,从 应用监控 这个 Addon 进入,在 应用监控/告警通知 里有针对应用的告警策略的配置。

应用告警示例

如果是发生应用错误次数告警,说明某个服务的异常次数达到了一定的阈值,那么项目管理员和应用开发人员需要关注一下程序里的逻辑,是不是哪里有问题。

如果发生了应用实例OOM告警,说明这个服务的 dice.yml 里配置的内存过小,或者服务有内存泄露,应该开发人员需要去调整申请的内存,或者检查是否有内存泄露的代码。

如果是应用请求状态码告警,说明在 主动监控 中配置的某个被检测的URL,访问请求异常,需要关注该URL对应的服务是否正常。