前言
在“求佛保佑服务器不宕机”、“杀程序员祭天”的环境下，程序员每天可谓是战战兢兢，接到电话和短信都吓得瑟瑟发抖，为了我们的安全，及时发现服务器运行问题已不仅仅是运维的问题了。今天总结一下常见的服务器监控指标，希望各位开发人员都搞一个脚本运行着以保障自己的生命安全。
文章经常被人爬，而且还不注明原地址，我在这里的更新和纠错没法同步，这里注明一下原文地址：http://www.cnblogs.com/zhenbianshu/p/7683496.html
获取服务器信息
多台机器同时需要监控时，每台机器都需要运行一个监控程序，我们首先要获取服务器的信息以分辨机器，发生问题时，也可以评估问题的严重性。
获取IP
获取内网IP：
通过ifconfig命令获取全部的网络信息，并排除掉本地host和ipv6信息。
/sbin/ifconfig | grep inet | grep -v '127.0.0.1' | grep -v inet6 | awk '{print $2}' | tr -d "addr:"
注意这里要使用ifconfig的绝对路径，因为如果监控脚本运行在 crontab 的话，执行时是不会带有环境信息的。
获取外网IP：
外网的IP我们可以通过请求别的网站来回显，有一些网站提供此服务，如 ipecho.net/plain 或者我自己懒得搭建的网站：alwayscoding.net。
命令如下 curl alwayscoding.net
获取系统信息
获取系统信息建议使用 lsb_release -a 方法：
lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch Distributor ID: CentOS Description: CentOS release 6.5 (Final) Release: 6.5 Codename: Final
信息比较丰富，可以截取字符串中需要的部分；
CPU
CPU 负载是我们要监控的首要指标，我们常说的系统负载指的就是它，它是指一段时间内CPU处理进程数占 CPU 能处理最大进程数的比例，即一个 CPU 的最大负载是 1.0，这种情况 CPU 正好能将所有进程执行完，超出这个限制，系统会进入 over load 超载状态，就会有进程需要等待其他进程执行结束。我们一般认为CPU负载在 0.6以下是健康状态。
在终端上查看系统负载通常使用 top 命令，但它是交互型的，且数据较多较杂，不利于写监控脚本，我们一般使用 uptime 通过其 average load 字段获取最近 1分钟、5分钟、15分钟的平均负载。
uptime 16:03:30 up 130 days, 23:33, 1 user, load average: 4.62, 4.97, 5.08
此时系统平均负载约为 5，不是系统已经超载，也没有显示错误，这是因为在考虑负载时还要考虑 CPU 的核心数，多核 CPU 同时能处理的进程数与其核数成正比，其最大负载不是 1，而是其 CPU 核心数 N。
我们使用 nproc 可以查看系统 CPU 核心数，我正在使用的这台机器核心数是 16，所以其最大负载是16，平均负载是 5/16 = 0.32 ， CPU 处于健康状态。
内存
内存是我们要监控的另外一项核心指标，内存占用率太高，无疑会导致进程无法正常分配内存执行。
我们也可以通过 top 命令查看内存占用，但监控中更常用 free 命令：
free -m
total used free shared buffers cached
Mem: 32108 18262 13846 0 487 11544
-/+ buffers/cache: 6230 25878
Swap: 0 0 0我们首先来看 Mem 这一行，共 32108M 内存，已使用 18262M，剩余 13846，那么内存的使用率就是 18262/32108*100% = 56.88%。那么，后面的shared、buffers、cached 又是什么意思呢？
其实在 linux 中，内存的分配也是懒惰原则，在内存分配给一个进程，进程执行完毕后 linux 是不会立即清理内存的，而是把这一部分内存当作缓存存储起来，如果此进程再启动就不必再重新加载了；如果可用内存使用完了，则将这一部分缓存清空，重新利用。这样来看 used 里的 buffers 和 cached 部分是随时可被重用的，不能算作被占用。而 shared 是进程共享内存部分，会作为被占用部分，但一般较少使用，与此相关的内容，可以看文末的参考文章。
真实数据是第三行的去除 buffers 和 cache 的部分，即真正的内存使用率是 6230/(6230+25878)*100% = 19.4%。
而第四行的 swap 是用来临时存储内存 buffers 和 cache 的，正常情况虽然能加快进程的重启，但物理内存较少的情况下，会引起 swap 的频繁读写，增加服务器的 IO 压力，用与不用视情况而定。
网络
网络在 linux 作为 web 服务器时也是一项很重要的指标，相关命令有很多，但各有所长，我们一般监控以下状态：
使用netstat查看监听端口。
netstat -an | grep LISTEN | grep tcp | grep 80 查看是否有进程正在监控80端口。
使用ping监控网络连接
使用 ping 命令可以查看网络是否连接，使用 -c 选项来控制请求次数，使用 -w 选项来控制超时时间（单位：毫秒），最后利用 && 符号的 短路 特性来控制结果输出:
ping -w 100 -c 1 weibo.com &>/dev/null && echo "connected"
硬盘
硬盘不是特别重要的监控指标，但在硬盘满的时候写文件失败也会影响进程的正常执行。
我们使用 df 命令来查看磁盘的使用状态，-h 会以易读格式输出：
df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 6.0G 32G 16% / tmpfs 16G 0 16G 0% /dev/shm /dev/vdb1 296G 16G 265G 6% /data0
我们可以使用 grep 命令找到想要查询的挂载节点，再使用 awk 命令获取结果字段。
另外使用 du [-h] /path/to/dir [--max-depth=n] 可以查看某目录的大小，注意使用 --max-depth=n控制遍历深度。
运行/其他
其他的监控状态主要包括进程错误日志监控，请求数监控，进程存在状态监控等，这些可以用到一些基本命令了，如 ps等。
更详细的信息就需要使用进程日志了，使用 grep 、awk 等命令来分析日志来获取更详细的信息。
总结
最后是监控结果的统计了，可以使用一般的“推”和“拉”方式，建议各机器把结果推到一台机器上进行统计和报警。也可以使用 rsync 方式从各服务器拉取，报警方式像企业微信、短信、邮件等就按要需配置了。
最后，系统监控是个重要且需要持续关注的事情，祝大家的服务器永不宕机。
原文发布时间为：2017-10-18
本文作者：佚名
本文来自云栖社区合作伙伴51CTO，了解相关信息可以关注51CTO。