服务器托管减少故障误报的方法
发布时间：2018-12-07 点击数：1052
服务器托管的用户一般都是根据主机显示板上的报错信号灯对服务器进行维护的，而且这个信号灯大多数时是准确的，可以是也有误报的情况发生，这就造成了用户不必要的维护工作，所以处理故障误报也是关键，今天我们就来谈谈服务器托管减少故障误报的方法。
顾名思义，通过心跳源，初步发现异常。通常心跳变化会有三类消息，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。
覆盖率：当前统计的覆盖率已经能很好的支撑日常宕机处理，该数据在有足够的特征后，会进一步提升。
以上就是全网数据小编整理的处理故障误报的方法，在全网数据一旦出现指示灯报错会及时排查是否是真的发生故障，确认无误也会第一时间通知服务器托管用户，全网数据优质的服务吸引了众多的新老用户，全网数据主要提供深圳服务器托管，深圳服务器租用，深圳主机托管，机柜租用等，欢迎咨询客服了解更多详情。
