提到服务器宕机检测，大家会想到，宕机能够很快知道，这个有什么可做的? 实际上，很多时候服务器宕机，并不总是被及时感知。服务器宕机，ping 或者 ssh 这是最简单的做法，但真正的工程实践，没这么简单。

想要获知服务器宕机怎么办? 可以通过服务器宕机实时检测：

1) 发现宕机。

2) 提前告警。

3) 告知宕机的详细原因，如硬件故障，内核 bug，网络异常等等。

4) 自动报修生成工单。

我们知道，进行全网物理机宕机准确探测与实时发现，可以给宕机分析提供第一现场，获取第一现场的日志。也可以尽早将宕机数据推送给业务或运营感知并处理，如自动报修，业务迁移等，从而尽可能将业务影响降到最低。

更重要的是，准确的宕机发现数据可以为宕机预测提供准确的标注数据，为后期宕机预测提供数据基础，并且这些数据提供给运营部门进行整体分析，提升处理效率。

那么，如何可以准确发现宕机，减少误报呢? 我们可以有以下操作，比如：

心跳源检测异常

顾名思义，通过心跳源，初步发现异常。通常心跳变化会有三类消息，update 消息，delete 消息和 insert 消息。心跳逻辑在于，正常情况下 SA 服务端与 NC 建立长连接，每数秒缓存一次心跳，每几分钟打包上报一次，但当 NC 异常时，长连接感知后，立即上报异常，并修改路由表。所以心跳异常做到秒级感知。

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

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

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

心跳源检测任务逻辑，主要是监听并缓存 uptime 消息，同时避免时间窗内多次消息冲突，导致信息被覆盖。

异常排除

排除非物理机器，将系统中暂时不关注的 VM 等产生的异常信息排除掉。

排除非业务状态的机器，如装机状态中的，包括生产中，维修中，迁移中，重装中，销毁中，重启中，无管控状态，只监控正常状态的机器。

排除非正在工作的机器，如非 working 状态机器。

网络干扰排除

宕机分析中，较多误报是由于网络问题干扰，无法准确判断出物理机是否宕机，有可能是网络问题。

排除上联网络设备异常导致的误报，包括机房断网演练，小面积网络故障，上联网络故障，如通过探测丢包情况，使用一些逻辑初步判断网络问题。

服务器本身未丢包的误报，除了需要过滤出网络问题，还要通过丢包数据分析，过滤掉 SA 误报问题， SA 异常会上报心跳异常，被误理解为宕机。

icmp 及 tcp 丢包分析，icmp 采集频率为固定数秒，tcp 采集频率固定数秒，包括多个不同大小包 (16，32，64，128，256 等) 的丢包情况，根据分析时间窗内两项数据的丢包情况

特殊情况干扰排除

个别机房有时候会出现大面积风暴式的无故心跳异常，同时网络 ping 包异常，但上联网络设备 ping 包正常，这种误报，一般根据具体 case 具体进行针对性的分析。如根据监控每个机房的上报频率，排除干扰。

进一步识别误报

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

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

进一步通过分析日志是否连续，判断是否发生重启。

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

如果还不能确定，使用 uptime 的时间窗技术进行重启。

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

长尾再次处理

未确认的待处理的，会加入到长尾列表中，像这种分钟级的心跳异常，ping 异常，但串口日志一直正常输出的情况，一般就是某种死机，死到连网络都不通的场景。会观察一段时间，一个固定时间窗内仍未恢复或重启的话，就暂时报宕机。后期会把这种死机单独找划分归类。

讲了这么多，到底效果怎么样?

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

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

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

目前，宕机感知是宕机分析的基础，通过服务器宕机实时检测，会把相应的宕机原因分布整理出来，明确具体的原因，达成服务器极致可靠性。