南京初唐科技发展有限公司-pg电子试玩平台

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

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

1)发现宕机。

2)提前告警。

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

4)自动报修生成工单。

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

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

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

心跳源检测异常

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

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

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

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

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

异常排除

• 特殊情况干扰排除

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

  进一步识别误报

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

  • 宕机时间点探测uptime确定是否发生重启。
  • 进一步通过分析日志是否连续，判断是否发生重启。
  • 日志重启特征值匹配，确认是否发生重启。
  • 如果还不能确定，使用uptime的时间窗技术进行重启。
  • 仍不能确定的待处理，进入长尾处理名单。

  长尾再次处理

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

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

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

  • 准确率：目前发现的宕机中有很高准确度，可以区分出真正宕机或者未宕机。而判断为宕机的数据中，也存在少量的，由于缺少相关信息导致误报，该部分将进一步优化，逐渐降低误报，在新的措施之后，该比例会接近0。
  • 覆盖率：当前统计的覆盖率已经能很好的支撑日常宕机处理，该数据在有足够的特征后，会进一步提升。

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