海天AIOPS之路系列之二：Ankole监控告警

海天AIOPS之路系列之二：Ankole监控告警

1. 控制短信告警数量

监控是一个运维平台最基础的功能，ankole数据库运维平台在监控上有什么特别之处呢。

不知道运维的小伙伴有没有接受过，1天几万条短信告警的挑战。我接触过的团队就有，主做运营商的软件供应商开发的监控系统，如果不及时关单，可能一会儿告警短信的手机就没电了。

这种情况，属于无效告警较多，无效告警太多非常影响运维团队的工作效率，疲于进行关单操作，让监控不再发送告警。

2. Ankole平台的告警

在ankole数据库运维平台管理的生产环境中，监控了数百套数据库，有Oracle 单机、RAC、DataGuard、MySQL、GoldenGate等等各种复杂环境，而由ankole数据库运维平台发送的告警数量分布如下：

可见，告警大部分都在白天生成，大部分情况下每天的告警少于100条。在夜间（晚上23点到早晨7点）大部分情况要么没有，要么只有1到2条短信，偶尔告警短信数量超过5条。那ankole运维平台是怎么做到的呢？

3. 根据故障场景分级应对

在ankole运维平台中，定义了多种故障场景，有些故障场景需要及时发送短信，比如：数据库实例的可用性，这种故障需要越快发出短信越好。而有些故障场景，比如：逻辑备份则在夜间无需发出告警，当逻辑备份出现失败、未完成等等，在值班人员第二天上班时进行提醒处理即可。

在ankole运维平台中定义的告警场景现在有49种

4. 控制告警方式

一般监控系统都会定时轮巡检测，大家思考一下，当一台数据库故障后，在未修复完成之前，是否一直需要告警呢。大部分的告警系统，如果不对故障、监控做处理，则是一直告警下去。这种告警方式其实大部分都是无效告警，影响运维人员的处理专注度，因为运维人员需要时刻关注告警是否是新的告警，反而影响了故障的处理速度。另外如果不关注，那可能新的故障告警反而没被关注到。

ankole运维平台中对各种故障场景定义了告警暂停、恢复机制。比如：当发生数据库可用性告警，当发送3次告警后，短信告警会暂停发送。如果1小时后数据库可用性故障未修复，那短信告警会继续发送3次。如果数据库可用性故障解决，则短信告警会发出恢复告警信息。

5. 告警模板定义

根据以上这些，ankole运维平台将短信告警设计成模板定义方式，定义以下内容：告警时间范围、告警日期、告警涉度、告警敏感度、告警骚扰度、告警循环、告警闭环。

以下是各个故障场景的短信告警模板配置

以MySQL同步复制场景为例，该故障场景在7*24发生故障都可以直接发送告警短信，发送告警的频率是每10分钟发送1次短信，为了避免误告警，只有在运维平台连续监测到故障2次后才开始发送告警，并且该告警在发送2次后就暂停发送，让运维人员可以专心处理。如果故障3小时没有解决，则3小时后继续发送2次，如果故障处理后，不发送恢复告警。

通过告警模板，定义各种故障场景的短信告警发送时间、发送方式、发送频率等。

6. 告警接收人

通过定义告警接收人，可以将一种故障类型，甚至是这种故障类型中的某个具体节点的告警，发送到相应的接收人，而不是所有的告警都需要发送到运维值班人员，进一步减轻运维值班人员的短信接收量。

7. 差异化告警阀值

日常运维的短信告警，比如：主机文件系统使用百分比，数据库表空间使用百分比，数据库会话数限值百分比等，这类告警的告警阀值，白天需要比夜间低。比如表空间使用率百分比，白天设置告警阀值为85%，夜间设置告警阀值为95%，这样这些日常维护的告警基本发生在白天，避免运维值班人员夜里爬起来扩容表空间。

8. 短信告警历史查询

作为乙方，并且是运维平台的开发方，总是会被甲方追问，某个故障的短信是否发送给了特定的接收人，而且有时侯是追问几天前的事情，在短信告警历史查询界面中就可以解决这样的问题。

在短信历史页面，可以通过故障场景和接收人查询，告警短信是否确切地发送给某位责任人。

9. 写在最后

通过控制告警数量，避免无谓的无效告警，对于运维值班人员的感受提升是非常明显的，特别是需要7*24小时，响应又需要特别高的值班要求。

通过ankole运维平台的告警优化，尽量避免运维人员因为值班压力而离职，减轻团队内部对值班的排斥情绪。

欢迎咨询海天起点技术专家

免费热线：800-810-3650   400-810-3650

喜欢本文请长按下方的二维码订阅海天起点