Linux的的故障排除

如果我们服务器上的某个程序出问题了,无法提供服务了,我们应该如何检测呢? 我们可以按一下几个步骤来检测

  1. 检测硬盘空间的使用情况
    [huinong@devserver ~]df -h
    Filesystem                        Size  Used Avail Use% Mounted on
    /dev/mapper/vg_devserver-lv_root   50G  6.6G   41G  15% /
    tmpfs                             6.9G  2.5G  4.4G  37% /dev/shm
    /dev/sda1                         485M   39M  421M   9% /boot
    /dev/mapper/vg_devserver-lv_home  860G   55G  762G   7% /home
    

    如果上面中有一个分区的Use%出现了 100%的情况,就肯定出问题了,而这种硬盘空间被用满是最常见的故障实在是太常见了,原因无他,就是运行时的日志等数据文件将空间占满了。特别是系统配置了自动备份程序时,备份数据日积月累,很容易将空间占满。
    有时候,我们也会用free命令看一下内存的使用情况,但如果程序发送故障,一般不是内存问题,内容不够的时候系统只会很慢,但还活着。

  2. 检测防火墙设置

    sudo iptables --list
    

    看看防火墙上是否打开了制定的端口。这是个低级错误,但碰巧是最容易犯的。特别是那些非80端口的服务程序。
    注意:这个例子是CentOs6上的,我们目前一般用CentOs7,相关的命令请看另外一篇文章

  3. 先看看我们的程序是否在跑
    这也是个低级错误:** 我们根本就没运行这个程序** 。很无语,但也很容易发送,例如系统重启后,就没自动启动相关程序。

    ps -ef | grep java
    

    这个命令就是查看是否有名为java的进程在跑,这个命令敲起来太长了,所以我们所有的服务器都为这个命令加了alias别名:pp,上述命令可以用 “pp java”来执行。

    [huinong@devserver ~]pp java
    huinong  21113     1  0 09:31 ?        00:00:59 /usr/bin/java -Djava.util.logging.config.file=/mnt/disk1/huinong/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=192.168.100.10 -server -XX:PermSize=64M -XX:MaxPermSize=128m -Djava.endorsed.dirs=/mnt/disk1/huinong/tomcat7/endorsed -classpath /mnt/disk1/huinong/tomcat7/bin/bootstrap.jar:/mnt/disk1/huinong/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/mnt/disk1/huinong/tomcat7 -Dcatalina.home=/mnt/disk1/huinong/tomcat7 -Djava.io.tmpdir=/mnt/disk1/huinong/tomcat7/temp org.apache.catalina.startup.Bootstrap start
    huinong  24036 23918  0 14:11 pts/2    00:00:00 grep java    
    

    这个命令就显示了我们有个java程序在跑,从参数中,我们可以看到这个是放在/mnt/disk1/huinong/tomcat7目录下的tomcat,在我们部署了多个tomcat的时候,可以通过参数来区分到底那个进程是那个tomcat的。

  4. 检测我们的程序是否监听了网络端口 : netstat -lnp
    程序在运行并不代表能建立网络服务,因为那个端口有可能是被其他程序占有的,或者当前操作的账号本来就没用权利监听那个端口,在某些环境下,1000以下的端口都是不能随便监听的。即使监听了,也就监听错的情况,例如如果监听的网站是127.0.0.1或者是一个内网地址,而不是0.0.0.0,就表示只能通过本机或者内网访问,外网不能访问。

    [huinong@devserver ~]netstat -lnp
    (Not all processes could be identified, non-owned process info
    will not be shown, you would have to be root to see it all.)
    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
    tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LISTEN      -                   
    tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      -                   
    tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      27968/nginx         
    tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   
    

    通过查看那些端口在监听,我们很容易知道我们的程序是否已经跑起来,并监听了端口。

  5. 如果上述都正常,就表示是程序自己的问题,要看日志

  6. 如果日志也没用什么问题,那可能就是碰到最悲剧的情况:死锁 ,死锁是很麻烦的情况,我们只能通过jconsole来查看,但不幸,我们绝大多数的项目都没用配置可让jconsole连接的url。也可以通过jmx来检测,但更加不行,目前我们通过jmx检测死锁的那个开源工具还没实现呢。

其他测试手段

  1. 用telnet看看端口是否开着

    telnet 127.0.0.1 端口号
    
  2. 用curl 访问一个应该存在的连接
    curl http://xxx.com/xxx.html
    
Sidebar