独立经营四个电信机房，福州机房，台州机房，嘉兴机房，泉州机房

高防服务器咨询QQ:177707604   TEL:13548367784

服务器“异常”的几个可能性预警请重视！

提到服务器宕机检测，大家会想到，宕机能够很快知道，这个有什么可做的?实际上，很多

时候服务器宕机，并不总是被及时感知。服务器宕机，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异常，但串口

日志一直正常输出的情况，一般就是某种死机，死到连网络都不通的场景。会观察一段时

间，一个固定时间窗内仍未恢复或重启的话，就暂时报宕机。后期会把这种死机单独找划

分归类。