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

说到服务器停机检测，你会想到停机可以很快知道。有什么可做的？事实上，服务器停机并不总是及时被感知。服务器停机，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异常，但串口日志输出正常，一般是某种死机，甚至连网络都没有。观察一段时间，如果窗口在固定时间内没有恢复或重新启动，暂时报告停机。这种死机将在后期单独分类。

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

从准确性和覆盖率来看：

精度:目前发现的停机精度很高，可以区分真实停机或未停机。在判断为停机的数据中，也有少量误报。由于缺乏相关信息，这部分将进一步优化，误报将逐步减少。新措施后，比例将接近0。

覆盖率：目前统计的覆盖率可以很好地支持日常停机处理，该数据具有足够的特后，将进一步改进。

目前，停机感知是停机分析的基础。通过服务器停机的实时检测，将整理出相应的停机原因，明确具体原因，实现服务器的终极可靠性。