java连接超时异常_Alluxio实战手册之异常排查篇

Alluxio集群运行过程中, 可能会因为硬件软件故障, 系统设置错误, 系统环境变更等原因导致集群运行出现异常. 本篇记录了我在平时工作中总结的一些故障排查的经验. 希望能帮到大家. 同时也建议大家碰到问题在我们的邮件列表(链接, 墙内镜像) 上提问之前, 可以先参照本文列出的考察点, 先自我排查一遍. 很可能就发现了问题的原因.

常用链接

• Alluxio项目官网
• Alluxio Inc网站
• Alluxio在各大厂用例
• 关注Alluxio微信公众号: Alluxio_China

master和worker进程是否正常

通常碰到问题后, 首先来确定当前的Alluxio集群的master和worker都在正常工作.

最简单直接的方法是连接并查看Alluxio的WebUI, 其默认地址为http://MasterHost:19999. 如果WebUI不响应, 则多半master节点出现了问题. 此外也可以运行一些简单的Alluxio shell 命令来确认master正常响应客户端的请求. 比如运行

bin/alluxio fs ls /

从WebUI中还可以可以看到很多有用的信息: 比如总worker数目, 是否有worker掉线, 以及每一个worker距上一次和master心跳的时间(如果是几分钟前上一次心跳, 多半worker出了问题). 在Alluxio 1.8当中将会添加一个fsadmin report命令让大家可以从命令行来监视集群的健康状况.

如果出现WebUI进程停止服务或shell命令超时, 以及如果有worker被判掉线, 下一步就是登录到这些机器上, 查看master或者worker其工作日志.

master和worker节点的工作日志

在每台运行master以及worker进程的节点上, ${ALLUXIO_HOME}/conf目录下的master.log以及worker.log文件分别是master 进程还有worker进程的工作日志. 登录这些节点查看工作日志内是否有有Exception被记录. 常见错误包括但不局限于下列这些:

• UFS连接中断(比如HDFS的namenode宕机或负载过大), 导致一些Alluxio UFS 操作超时;
• UFS操作权限不够被拒绝;
• UFS端数据源被绕过Alluxio的操作改动, 导致Alluxio与UFS层失去同步;
• 高负载下Master线程池耗尽, 无法响应新的客户端请求.

从工作日志当中, 能够发掘出很多有用的系统报错信息. 毫不夸张的说, master以及worker进程的工作日志是debug的主要来源.

Alluxio文件系统日志(Journal)

与存储在每台服务器节点本地上的master或者worker工作日志不同, Alluxio文件系统日志(Journal)通常是保存在一个外部的存储系统比如HDFS上. 具体地址可见alluxio.master.journal.folder设置.

Alluxio Journal中保存了所有对Alluxio文件系统元数据层面的操作, 所以当Alluxio服务重新启动, 或者HA(高可用)模式下leader master更迭的时候, 整个Alluxio文件系统依然最新状态. 如果当Journal所处的存储系统出现连接问题的时候(比如namenode宕机, 或者具体存储Journal文件的datanode掉线)的时候, 可能会导致Alluxio系统对元数据写操作的失败, 导致Alluxio文件系统拒绝新的文件操作.

所以检查存储Alluxio Journal的存储系统的健康也是排查工作的一部分.

是否有频繁的JVM GC

Master以及worker进程频繁及长时间的JVM GC可能会引起master或worker节点的服务中断或连接超时, 节点连接心跳超时, 表现为Alluxio服务的不稳定. 通常高GC压力会表现为JVM进程的CPU占用率飙升. 为了排查这种可能, 可以在alluxio-env.sh当中, 为master或者worker进程的JVM参数添加GC相关的参数, 比如

ALLUXIO_JAVA_OPTS=" -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+PrintGCTimestamps"

这样在"${ALLUXIO_HOME}/conf"目录下的master.out 或者worker.out当中, 会有系统的GC记录.

如果只要检测master(或者worker)的GC历史, 替换ALLUXIO_JAVA_OPTS为ALLUXIO_MASTER_JAVA_OPTS(或者ALLUXIO_WORKER_JAVA_OPTS)

是否有死锁(查看jstack)

master或者worker服务中断的另一种可能是程序bug导致的死锁. 如果master或者worker进程出现了长时间的不响应及高CPU占用率, 但并没有频繁或者超长GC伴随, 难么有可能是出现了死锁. 在这种情况系啊, 可以先用jps列出进程得到pid, 再用jstack <pid>输出这些进程的分线程callstack状态以供分析.

实时启用DEBUG级别的日志

默认情况下, Alluxio master以及worker进程的工作日志仅仅包括INFO和ERROR级别的日志, 不包括DEBUG level的消息(通常带有更丰富的信息, 比如master端RPC执行错误的callstack). 如下命令可以动态调整master的logging level 至DEBUG, 这样我们可以看到master端执行RPC时候报错的callstack 而不用重启整个服务.

$ bin/alluxio logLevel 
--logName=alluxio.master.file.FileSystemMasterClientServiceHandler 
--target=master 
--level=DEBUG

也可以指定多个目标, 比如不仅包括master, 也包括192.168.100.100这台worker: `--target=master,192.168.100.100:30000`.

更多详情可以参阅 Logging Conventions And Tips - Docs | Alluxio Open Source

总结

• 发现异常时首先排查是否所有进程都在正常工作
• 工作日志非常非常有用, 基本是debug依据的主要来源
• 有时候默认的logging level不够具体, Alluxio提供动态的调整某一个类的logging级别, 非常方别