告警规则及处理方法

平台相关的告警

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

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

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

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

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

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

磁盘告警示例

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

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

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

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

机器状态告警示例

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

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

集群组件告警示例

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

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

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

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

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

应用相关的告警

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

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

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

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

应用告警示例

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

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

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