IaaS运维之服务器宕机检测

提到服务器宕机检测,大家会想到,So easy,这个有什么可做的?实际上,很多时候服务器宕机,并不总是被及时感知。服务器宕机实时检测的工程实践并不像想象中的ping或SSH即可;

全网物理机宕机准确检测,可以给宕机分析提供第一现场,获取第一现场日志,不仅能更快的将宕机数据推送给业务或运营感知并处理,还能降当前服务器状态给保存下来,便于时候分析及后续的故障预测。不仅能做到服务器状态的实时感知,便于自动保修、业务迁移等降低宕机对业务的影响,还能更便捷的为事后分析提供精准数据,减少信息筛选时间,为服务器故障预测提供坚实的数据基础;

服务器宕机实时检测流程主要分以下几步:

1)服务器状态感知;数据收集、状态判定

2)宕机状态识别;

3)宕机原因分析;

一、服务器状态感知

服务器是否宕机可以通过心跳源变化进行检测,通常心跳变化会有三类消息,update消息,delete消息和insert消息:

update消息,在有心跳发生变化情况下都会有,心跳异常和心跳恢复正常时都会发起,是主要的心跳来源。

delete消息,在心跳异常,并且SA判断ping不通,且ssh不通情况下发起,删除该条消息,避免延迟太长。

insert消息,在新增加机器,或者重装后重新上位的机器发起,该消息对宕机发现价值不大,配合uptime使用。

正常情况下SA服务端与NC建立长连接,每数秒缓存一次心跳,每几分钟打包上报一次,但当NC异常时,长连接感知后,立即上报异常,并修改路由表。心跳源检测任务逻辑,主要是监听并缓存uptime消息,同时避免时间窗内多次消息冲突,导致信息被覆盖。

在检测服务器是否宕机前,需要优先建立当前机房所有服务器的工作状态,并且需要排除非物理机异常信息、排除非工作状态服务器、排除非业务状态服务器(如装机状态中的,包括生产中、维修中、无管控状态等),只监控正常状态的机器。

二、宕机状态识别

针对识别出来的宕机状态需要进行“宕机”识别,判断当前宕机状态是否真实,避免错误告警而衍生的误工单;

优先排查上联网络设备异常导致的误报;通过采集交换机流量数据,判断流量是否异常,在一般情况中可以仅通过上联口设备是否Down导致误报,若有交换机流量数据推荐做好实时监控,并做好采集时间同步;

排查服务器本身未丢包的误报;通过丢包数据分析,过滤掉SA误报问题,SA异常会上报心跳异常被误解为“宕机”;

ICMP及TCP丢包分析,ICMP采集频率为固定数秒,TCP采集频率固定数秒,可以根据时间窗内两项数据的丢包情况进行判断;

三、宕机原因分析

至此,大部分干扰已经过滤掉,但仍有一部分误报隐藏其中。比如心跳异常,ping异常,都合乎宕机判断的逻辑,会导致误判成宕机,如导致网卡被打爆,或者重试率高,这种是业务原因导致网络异常,但业务认为不是异常,需要排除掉。再例如服务器并没有挂掉,但是IO延时和资源占用率各项指标都不正常等场景。针对以上等情况,增加uptime判断以及带外日志分析排查。可以通过决策树的方式构建判断组合;例如:

宕机时间点探测uptime确定是否发生重启。

分析日志是否连续,判断是否发生重启。

日志重启特征值匹配,确认是否发生重启。

使用uptime的时间窗技术进行重启。

仍不能确定的待处理,进入长尾处理名单。

针对长尾处理名单问题采用固定时间窗持续监控,若未回复或重启,则直接判断“宕机”。

上述仅展示了部分可能性,在判断宕机过程中需要充分利用交换机日志、端口流量、服务器日志数据,在数据实时监控和处理过程中我们会碰到设备日志标准化、流量数据丢包、交换机端口Down等问题,因此可以采用机器学习技术对这些数据进行标准化分析,并将“宕机”状态的周边设备异常信息保存下来,便于后续根因分析及可能宕机原因确认。

在做过宕机原因分析及排序后,可以快速生成工单或自动重启,并根据服务等级对当前状态进行分级处理。

我们从准确率和覆盖率来看:

准确率:目前发现的宕机中有很高准确度,可以区分出真正宕机或者未宕机。而判断为宕机的数据中,也存在少量的,由于缺少相关信息导致误报,该部分将进一步优化,逐渐降低误报,在新的措施之后,该比例会接近0。

覆盖率:当前统计的覆盖率已经能很好的支撑日常宕机处理,该数据在有足够的特征后,会进一步提升。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181226G196EC00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券