说到服务器宕机检测，大家会认为宕机可以很快知道，这有什么办法呢？事实上，很多时候服务器宕机，并不总是被及时察觉。服务器挂了，ping或者ssh是最简单的方法，但是真正的工程实践并没有这么简单。想知道服务器挂了怎么办？服务器宕机的实时检测可以做到：1）发现宕机。2）预警。3)通知详细的宕机原因，如硬件故障、内核bug、网络异常等。4)自动生成报修工单。我们知道，对全网物理机宕机的准确检测和实时发现，可以提供最新站点进行宕机分析，获取上一个站点的日志。也可以尽早将宕机数据推送给业务或运营感知和处理，如自动修复、业务迁移等，尽可能将业务影响降到最低。更重要的是，准确的停机发现数据可以为停机预测提供准确的标注数据，为后期的停机预测提供数据依据，并将这些数据提供给运营部门进行统筹分析，提高处理效率。那么，我们如何才能准确检测停机时间并减少误报呢？我们可以做如下操作，比如：心跳源检测异常，顾名思义，通过心跳源，初步发现异常。通常心跳变化的消息分为三种，更新消息，删除消息和插入消息。心跳逻辑是，正常情况下，SA服务器与NC建立长连接，每隔几秒缓存一次心跳，每隔几分钟上报一次。因此，可以秒级检测异常心跳。当心跳发生变化时，将出现更新消息。当心跳异常和心跳恢复正常时发送。它是心跳的主要来源。删除消息在心跳异常时发送，SA判断ping和ssh不可达，删除消息，避免延时过长。插入消息在新增机器时发起，或者重装后重装机器时发起。该消息对于停机时间检测价值不大，与正常运行时间结合使用。心跳源检测任务逻辑主要是监听和缓存uptime消息，同时避免时间窗口内多个消息冲突，导致信息被覆盖。异常排除排除非物理机，排除系统暂时不关心的虚拟机产生的异常信息。排除非业务状态的机器，如安装状态的机器，包括生产、维护、迁移、重装、销毁、重启、无控制状态的机器，只监控正常状态的机器。排除非工作机器，例如非工作机器。网络干扰排除在宕机分析中，很多误报都是因为网络干扰，无法准确判断物理机是否宕机，可能是网络问题。排除上行网络设备异常引起的误报，包括机房掉线演练、小区域网络故障、上行网络故障，比如检测丢包，利用一些逻辑初步判断网络问题。除了过滤掉网络问题，服务器本身还需要过滤掉丢包的误报，通过丢包数据分析过滤掉SA误报。SA异常会报告心跳异常，容易被误认为宕机。icmp和tcp丢包分析，icmp采集频率固定几秒，tcp采集频率固定几秒，包括多个不同大小（16、32、64、128、256等）包的丢包，根据分析时间窗口中的两项数据丢包，特殊情况，干扰排除，个别机房有时无缘无故出现大面积暴风雨般的心跳异常，同时网络ping包异常异常，但上行网络设备ping包正常。这种误报一般是根据具体情况进行的。有针对性的分析。例如，根据监控各机房的上报频率排除干扰。误报的进一步识别此时，大部分干扰已经被过滤掉，但仍然隐藏了一些误报。比如心跳、ping不正常，都是符合宕机判断逻辑的，会导致误判为宕机，比如导致网卡炸毁，或者重试率高等。这种网络异常是业务原因引起的，但业务认为不是异常。,需要排除。又比如服务器没有挂掉的场景，但是IO延迟和资源占用等指标异常。针对以上情况，增加uptime判断和out-of-bandlog分析排查。停机时间点检测正常运行时间以确定是否发生重启。进一步地，通过分析日志是否连续，判断是否发生重启。日志重启特征值匹配，确认是否发生重启。如果还不能确定，就用uptime的时间窗技术重启。仍未确定是否处理的将进入长尾处理列表。未确认的待定项目将被添加到长尾列表中。分钟级异常心跳和ping异常，但串口日志始终正常输出。一般是死机的一种，死机到连不上网络。不起作用的场景。会观察一段时间，如果在固定的时间窗口内还没有恢复或者重启，就暂时上报宕机。后面会单独对这种crash进行分类。说了这么多，效果如何？再看准确率和覆盖率：准确率：目前发现的宕机准确率很高，可以区分真实宕机和非宕机。在判断为宕机的数据中，也存在少量因缺乏相关信息而产生的误报。这部分会进一步优化，逐步减少误报。新措施实施后，该比例将接近于0。覆盖率：目前统计的覆盖率可以很好地支撑日常的宕机处理，等有足够的特征后，数据会进一步完善。目前，停机感知是停机分析的基础。通过实时检测服务器宕机，梳理对应宕机原因分布，明确具体原因，实现服务器最高可靠性。
