如果还不能确定，使用uptime的时间窗技术进行重启。
更重要的是，准确的宕机发现数据可以为宕机预测提供准确的标注数据，为后期宕机预测提供数据基础，并且这些数据提供给运营部门进行整体分析，提升处理效率。
长尾再次处理
3）告知宕机的详细原因，如硬件故障，内核bug，网络异常等等。
服务器本身未丢包的误报，除了需要过滤出网络问题，还要通过丢包数据分析，过滤掉SA误报问题， SA异常会上报心跳异常，被误理解为宕机。
日志重启特征值匹配，确认是否发生重启。
我们从准确率和覆盖率来看：
进一步识别误报
目前，宕机感知是宕机分析的基础，通过服务器宕机实时检测，会把相应的宕机原因分布整理出来，明确具体的原因，达成服务器极致可靠性。
4）自动报修生成工单。
那么，如何可以准确发现宕机，减少误报呢？我们可以有以下操作，比如：
排除非正在工作的机器，如非working状态机器。
排除非业务状态的机器，如装机状态中的，包括生产中，维修中，迁移中，重装中，销毁中，重启中，无管控状态，只监控正常状态的机器。
异常排除
未确认的待处理的，会加入到长尾列表中，像这种分钟级的心跳异常，ping异常，但串口日志一直正常输出的情况，一般就是某种死机，死到连网络都不通的场景。会观察一段时间，一个固定时间窗内仍未恢复或重启的话，就暂时报宕机。后期会把这种死机单独找划分归类。
1）发现宕机。
覆盖率：当前统计的覆盖率已经能很好的支撑日常宕机处理，该数据在有足够的特征后，会进一步提升。
icmp及tcp丢包分析，icmp采集频率为固定数秒，tcp采集频率固定数秒，包括多个不同大小包（16，32，64，128，256等）的丢包情况，根据分析时间窗内两项数据的丢包情况
update消息，在有心跳发生变化情况下都会有，心跳异常和心跳恢复正常时都会发起，是主要的心跳来源。
网络干扰排除
仍不能确定的待处理，进入长尾处理名单。
提到服务器宕机检测，大家会想到，宕机能够很快知道，这个有什么可做的？实际上，很多时候服务器宕机，并不总是被及时感知。服务器宕机，ping或者ssh这是最简单的做法，但真正的工程实践，没这么简单。
排除上联网络设备异常导致的误报，包括机房断网演练，小面积网络故障，上联网络故障，如通过探测丢包情况，使用一些逻辑初步判断网络问题。
讲了这么多，到底效果怎么样？