我在服务器上部署了一个监控，结果服务器都关了，监控还是显示正常，测试ping服务器还是通的

ip有重复吧，实际ping的是另外一台机器。
是不是有相同设置的备用机？

是不是服务器外有防火墙，ping的是防火墙的转换地址呢

你ping的是网关ip么》你的监控是实时的吗

最好的监控是否alive还是自己在应用层发送和接受心跳来判断

我ping的网关，我在自己电脑测试时，服务器一关就报错，部署到服务器上就永不报错

如果你ping网关的话，那服务器关不关和你的判断就没什么关系，只和你的网关有关系，你可以ping一个服务器

但最后的办法还是采用心跳检测

一、什么是心跳检测　　

软件的质量属性是衡量软件非功能性需求的重要因素。

　　可用性质量属性主要关注软件系统的故障和它所带来的后果。心跳检测是能够提高系统可用性的措施。
　　例如：服务端和客户端之间进行通讯，每隔5分钟进行一次心跳检测，检测和主站连接是否正常。客户端每5分钟发一个心跳检测数据帧，服务端接收到数据帧表示通过，否则表示客户端断开，抛出异常。

判断对方（设备，进程或其它网元）是否正常动行，一般采用定时发送简单的通讯包，如果在指定时间段内未收到对方响应，则判断对方已经当掉。用于检测TCP的异常断开。

基本原因是服务器端不能有效的判断客户端是否在线也就是说，服务器无法区分客户端是长时间在空闲，还是已经掉线的情况。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。

代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息。如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。

发包方可以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。

一般来说，出于效率的考虑，是由客户端主动向服务器端发包，而不是相反。

“心跳”分为两种，第一种是客户端发起的心跳，第二种是服务端发起的心跳。
　　客户端发起的心跳：客户端每隔一段时间发送策略消息给Socket服务器，Socket服务器原路返回策略消息，如果客户端在设定时间段内没有收到Socket服务器的返回消息，经重试机制后，判定Socket服务器已Down，关闭连接。
　　服务端发起的心跳：服务端实时记录每条Socket的IO操作时间，每隔一段时间获取所有Socket列表的快照，扫描每条Socket，如果该Socket的IO操作时间距当前时间已超出设定值，则判定客户端Down，关闭连接。

你好，单从问题描述上看，因为也没有其他更具体的上下文环境描述，我猜测问题可能情况如下：
【情况1】服务器已发送关闭指令，但检查监控时实际还未完全关闭（或关闭被中断）
分析：
该关闭指令可能是手动敲命令执行，或者由其他管理端下发指令，然后机器确实也正在执行关闭指令，但关闭过程中有特殊情况发生阻断，比如开启了网络文件服务nfs，远程挂载正在被使用等，系统必须等待资源使用完毕才会做进一步操作（该过程持续时间不固定，有些阻断甚至必须手动强制结束），此时如果监控进程排在阻断服务后面，即未被系统关闭进程处理到，那此时肯定还是存活的，那监控显示肯定就是还是正常的（包括单体服务和代理服务模式的情况），而能ping通，是只要服务器还没完全关闭一般都能通，这是一种情况；
验证：
比如可以尝试使用ssh或telnet进去服务器，或者使用nc嗅探下该机器的监控服务端口，如果有反应，那说明机器并未彻底关闭。
【情况2】服务器实际已关闭，但监控面板和ping状态存在延迟或错误；
分析：
① 针对ping正常返回情况，如果服务器是在一个异构或异域网络，甚至是有开启防火墙转换策略的，那么ip肯定会经过网络转换服务即网关，那有可能ping的是一个被转换的ip，如果网关服务存在延迟或者bug，就可能返回一个错误ping数据包（即缓存，没有实时探活），进而获得一个错误的ping状态；
② 针对监控正常情况，如果该监控的模式是一个代理服务的机制，那么如果监控面板刷新存在延迟（问题描述没说明是否可手动刷新，这里排除手动刷新情况），或者监控代理设计存在缺陷刚好被触发，都可能导致看到的监控状态显示有误。
验证：
找运维owner检查网关服务或防火墙配置。

1、ip是自动获取的嘛如果是自动获取的话，可能ip已经被别的服务器申请使用了
2、或者是监控延迟
3、可以使用arp协议查看一下mac地址，看一下是那一台机器的mac地址
4、如果你觉得自己的监控不好的话可以换一个：推荐一个腾讯蓝鲸监控