uptime

uptime uptime 可以对cpu使用情况进行监控。 [nukix@bogon ~]$ uptime # 当前时间 系统运行时间 当前登录用户数 系统平均负载 18:56:53 up 1 day, 3:55, 2 users, load average: 0.00, 0.01, 0.05 free free 可以对内存和交换分区进行监控。 [nukix@bogon ~]$ free -h total used free shared buff/cache available Mem: 977M 680M 76M 8.7M 220M 100M Swap: 1.5G 397M 1.1G df df 可以查看系统磁盘的使用情况。 [nukix@bogon ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda3 14G 5.8G 7.5G 44% / devtmpfs 475M 0 475M 0% /dev tmpfs 489M 116K 489M 1% /dev/shm tmpfs 489M 21M 469M 5% /run tmpfs 489M 0 489M 0% /sys/fs/cgroup /dev/sda1 297M 192M 106M 65% /boot tmpfs 98M 28K 98M 1%

提到服务器宕机检测，大家会想到，宕机能够很快知道，这个有什么可做的?实际上，很多时候服务器宕机，并不总是被及时感知。服务器宕机，ping或者ssh这是最简单的做法，但真正的工程实践，没这么简单。 想要获知服务器宕机怎么办?可以通过服务器宕机实时检测： 1)发现宕机。 2)提前告警。 3)告知宕机的详细原因，如硬件故障，内核bug，网络异常等等。 4)自动报修生成工单。 我们知道，进行全网物理机宕机准确探测与实时发现，可以给宕机分析提供第一现场，获取第一现场的日志。也可以尽早将宕机数据推送给业务或运营感知并处理，如自动报修，业务迁移等，从而尽可能将业务影响降到最低。 更重要的是，准确的宕机发现数据可以为宕机预测提供准确的标注数据，为后期宕机预测提供数据基础，并且这些数据提供给运营部门进行整体分析，提升处理效率。 那么，如何可以准确发现宕机，减少误报呢?我们可以有以下操作，比如： 心跳源检测异常 顾名思义，通过心跳源，初步发现异常。通常心跳变化会有三类消息，update消息，delete消息和insert消息。心跳逻辑在于，正常情况下SA服务端与NC建立长连接，每数秒缓存一次心跳，每几分钟打包上报一次，但当NC异常时，长连接感知后，立即上报异常，并修改路由表。所以心跳异常做到秒级感知。 update消息，在有心跳发生变化情况下都会有，心跳异常和心跳恢复正常时都会发起，是主要的心跳来源。

不知道onenote的笔记复制出来就是图片了。。。 来源： https://www.cnblogs.com/lanjianhappy/p/11949677.html

提到服务器宕机检测，大家会想到，宕机能够很快知道，这个有什么可做的?实际上，很多时候服务器宕机，并不总是被及时感知。服务器宕机，ping或者ssh这是最简单的做法，但真正的工程实践，没这么简单。 想要获知服务器宕机怎么办?可以通过服务器宕机实时检测： 1)发现宕机。 2)提前告警。 3)告知宕机的详细原因，如硬件故障，内核bug，网络异常等等。 4)自动报修生成工单。 我们知道，进行全网物理机宕机准确探测与实时发现，可以给宕机分析提供第一现场，获取第一现场的日志。也可以尽早将宕机数据推送给业务或运营感知并处理，如自动报修，业务迁移等，从而尽可能将业务影响降到最低。 更重要的是，准确的宕机发现数据可以为宕机预测提供准确的标注数据，为后期宕机预测提供数据基础，并且这些数据提供给运营部门进行整体分析，提升处理效率。 那么，如何可以准确发现宕机，减少误报呢?我们可以有以下操作，比如： 心跳源检测异常 顾名思义，通过心跳源，初步发现异常。通常心跳变化会有三类消息，update消息，delete消息和insert消息。心跳逻辑在于，正常情况下SA服务端与NC建立长连接，每数秒缓存一次心跳，每几分钟打包上报一次，但当NC异常时，长连接感知后，立即上报异常，并修改路由表。所以心跳异常做到秒级感知。 update消息，在有心跳发生变化情况下都会有，心跳异常和心跳恢复正常时都会发起，是主要的心跳来源。