宕机检测(轻松应对!教你如何检测服务器宕机)
一、服务器宕机了,应该怎么办
造成服务器宕机（死机）的原因是什么呢？那么他解决方法有哪些呢？壹基比来告诉你
引发服务器宕机原因大概有：运行环境问题、服务器性能问题、服务器硬件问题、数据丢失或损坏问题。下面我们对以上几个问题详情描述并提供解决办法：
一、运行环境问题导致服务器宕机
服务器运行环境包括操作系统，数据库，应用程序，应用程序bug，网络数据等，以上软件系统故障会引起服务器宕机现象。解决办法：需要我们查找分析系统、应用程序相关日志来找出真正的原因。一般都能发现问题，根据日志提供的错误信息修改相关设置来解决此类宕机故障，由于系统原因可以重装系统，或重启一下服务器就可以了。
二、服务器性能问题导致服务器宕机
服务器性能好坏也是引发宕机的一个因素，因为IDC提供商的服务器有些不是品牌服务器，是组装型的服务器，采购的硬件也不是品牌的，多用于杂牌硬件，难免会因硬件兼容性，CPU，内存等性能不好，导致宕机。解决办法：查看服务器硬件信息，在租用或选购时尽量用品牌服务器，品牌服务器在稳定性方面是没得说的。
三、服务器硬件问题导致服务器宕机
如服务器主板，电源，CPU，内存，磁盘有问题也会导致服务器宕机故障，解决办法：使用工具测试相关硬件配件，或更换配件测试服务器硬件问题。
四、数据丢失或损坏问题导致服务器宕机
数据丢失包括人为错删除数据，磁盘坏道导致数据丢失，磁盘写满等原因可导致服务器系统崩溃宕机，解决办法：做好数据备份，监控磁盘空间大小。
二、如何检测一台机器是否宕机
检测一台机器是否宕机的应用场景如下：
1,工作机器宕机，总控节点需要能够检测到并且将原有服务迁移到集群中的其它节点。
2,总控节点宕机，总控节点的备份节点（一般称为Slave）需要能够检测到并替换成主节点继续对外服务。
检测一台机器是否宕机必须是可靠的。在大规模集群中，机器可能出现各种异常，比如停电，磁盘故障，过于繁忙导致假死等。对于机器假死，如果总控节点认为机器宕机并将服务迁移到其它节点，假死的机器又认为自己还可以提供服务，则会出现多个节点服务同一份数据而导致数据不一致的情况。
首先必须明确，理论上检测另外一台机器是否宕机是无法做到的，有兴趣的同学可以参考Fischer的论文。可以简单理解如下：A机器往B机器发送心跳包，如果B机器不发送响应，A无法确定B机器是宕机了还是过于繁忙，由于A和B两台机器的时钟可能不同步，B机器也无法确定多久没有收到A机器的心跳包可以认为必须停止服务。因此，A机器没有办法确定B机器已经宕机或者采取措施强制B机器停止服务。
当然，工程实践中，由于机器之间会进行时钟同步，我们总是假设A和B两台机器的本地时钟相差不大，比如相差不超过0.5秒。这样，我们可以通过Lease机制进行宕机检测。Lease机制就是带有超时时间的一种授权。假设总控节点需要检测工作节点是否宕机，总控节点可以给工作节点发放Lease授权，工作节点持有有效期内的Lease才允许提供服务，否则主动下线停止服务。工作节点的Lease快要到期的时候向总控节点重新申请Lease（一般称为renewLease），总控节点定时检测所有工作机的Lease授权是否合法，如果发现某台工作机Lease失效，可以将工作机上的服务迁移到集群中的其它机器，这时因为工作机发现自己Lease失效会主动停止服务。当然，这里需要注意，由于总控节点和工作机的时钟可能不一致且有网络延迟，总控节点上的Lease超时时间要长，也就是说，如果工作节点的Lease超时时间是12秒，总控节点可能需要13秒后才能确认工作节点已经停止了服务，从而避免数据不一致问题。
同构节点之间的选主也有一个宕机检测问题。比如总控节点宕机，备份节点需要能够检测并升级为主节点继续对外服务。Mysql数据库经常采用Heartbeat+ DRBD(Distributed Replicated Block Device)+ Mysql的高可用性方案，据说能够达到3个9的高可用性，主节点和备节点维持Heartbeat心跳，当提供服务的主节点出现故障时，备节点的Heartbeat检测到主节点没有心跳（例如，Ping不通主节点），备节点自动接管虚拟IP，升级为主节点提供Mysql读写服务。由于Heartbeat检测机器主节点宕机不可靠，这个方案存在众所周知的脑裂问题，即集群中可能同时存在多个主节点同时提供服务。解决这个问题本质上还是需要引入仲裁节点，比如Heartbeat+ DRBD方案中引入Fence节点使出现问题的节点从集群中脱离，或者引入分布式锁服务，比如Chubby的开源实现Zookeeper服务。分布式锁服务实现主节点选举大致如下：主节点和备节点到Chubby中抢锁，抢到锁的节点在锁的有效期(Lease期)内提供服务，当主节点锁的Lease快要到期时，主节点申请延长锁的超时时间，正常情况下分布式锁服务总是优先满足主节点的请求，当主节点出现故障时，备节点能够抢到锁切换为主节点提供服务。
最后还有一个问题，假设总控节点通过Lease机制检测工作节点是否宕机，这种方案是可靠的，不过当总控节点宕机时，如果不采取任何措施，集群中的所有工作节点都将因为无法重新申请Lease而停止服务，这就是带有总控节点的设计固有的脆弱性，某个设计或者编码的错误都有可能造成严重的影响。解决这个问题一般会有一个叫做Grace Period的机制，工作节点Lease超时时将停止服务，但是工作节点并不一开始就重启或者下线，而是处于一种危险状态(称为Jeopardy)，这种状态持续一个Grace Period，比如45秒。如果在Grace Period内总控节点重启，工作节点和总控节点重新联系上从而可以切换为正常状态继续提供服务。
三、服务器宕机原因及其解决方案
对于广大站长来说，服务器宕机对网站的收录跟排名都是有非常大的影响的，最重要的是宕机会影响网站业务的进行，所以无论不管说是用户还是服务商都不希望服务器出现宕机问题，那假如出现了，我们该如何解决它呢？
服务器宕机是每个服务商都会遇到的问题，一般有以下几种原因：
1.服务器性能
服务器的性能问题有很多，但最多见的应该就是SQL，但我们也不能一概而论，还有别的可能性，例如有些问题就是服务器Bug或错误行为导致的。另外，较差的Schema和索引设计也是较多的出错原因之一。
2.运行环境
如果是这个问题，那么最常见的就是磁盘空间消耗完了。
3.数据丢了或损坏
数据丢失也有很多原因，可能不是用户错误操作，也可能是人为攻击造成的，但一般来说是由drop table错误操作导致，通常出现这个问题都会伴随着缺少可用备份的问题。
4.复制
复制问题一般是由主备数据不一致导致的。
我们了解了这几项宕机原因，那么如何判断或查看服务器宕机原因呢？
（1）查看是否是误操作导致的
（2）查看是否是应用程序导致的
（3）查看是否是应用程序导致内存溢出或者泄露，out of memory导致
（4）查看是否是流量负载过大导致的
（5）查看是否是遭受黑客入侵攻击导致的
那我们查明是如原因后，我们又该如何去解决问题呢？
1.发现服务器宕机后，及时联系服务商解决相关问题，就算短暂的宕机也可能会造成较大的损失，请大家及时联系自己的服务商。
2.做好提前防范的准备。可以同时运行两个网站空间，备份内容，当一个出现问题，立刻启动另一个。
3.使用一款功能好的宕机监控第一时间智能处理，故障发生时可设置自动切换至备用IP，恢复后将切换回原IP，能够有效提高网站可用性和页面性能。有效规避风险降低成本。