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。

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