Apache Spark Worker反复存活死亡及重复打印SecurityManager日志问题咨询

Hey，这种Worker反复在ALIVE/DEAD之间横跳+SecurityManager日志重复打印的问题，我在运维Spark集群时碰到过好几次，本质是Worker进程反复重启+Master心跳失联的连锁反应，具体原因可以拆解成这几个方面：

Spark Master和Worker之间靠心跳包维持状态：

• Worker默认每隔10秒向Master发送一次心跳，证明自己存活
• 如果Master在默认60秒的超时窗口内没收到Worker的心跳，就会把该Worker标记为DEAD
• 要是你的Worker是由监控工具（比如systemd、supervisor）或者Spark自带的容错机制托管的，Worker进程一旦挂掉/被标记为DEAD，就会被自动重启
• 重启后的Worker会重新向Master注册，状态变回ALIVE，但如果导致心跳失联的根因没解决，很快又会再次触发超时，进入「ALIVE→DEAD→重启→ALIVE」的循环

而你看到的重复打印的SecurityManager: authentication disabled; ui acls disabled; users with view permissions:日志，就是Worker每次重启时，初始化安全组件都会输出的启动日志——日志重复的次数，基本对应了Worker被重启的次数。

下面是最容易导致这个问题的几个原因：

• 网络连通性异常：Master和Worker之间的网络不稳定，比如防火墙拦截了心跳端口、网络抖动丢包、端口冲突（Worker的通信端口被其他进程占用），导致心跳包无法正常传输。Master收不到心跳就标记Worker为DEAD，Worker重启后暂时恢复连接，随后又因为网络问题再次失联。
• Worker节点资源耗尽：Worker所在机器的CPU、内存、磁盘资源被占满，比如内存耗尽导致Worker进程被系统的OOM Killer杀死，或者磁盘IO过高让Worker无法及时生成/发送心跳包。进程死后被重启，恢复后又很快因为资源不足再次崩溃。
• 配置参数不合理：比如把spark.worker.timeout设置得过短（比如小于30秒），或者spark.heartbeat.interval设置得过长，导致Master过早判定Worker死亡；还有可能是spark.master地址配置错误（比如写错了Master的IP/端口），Worker注册后很快失去连接。
• 进程本身的异常：Worker进程存在bug，或者依赖环境不兼容（比如Java版本和Spark版本不匹配、Hadoop依赖包冲突），导致Worker运行一段时间后崩溃，随后被监控工具重启。

如果你要定位具体原因，可以从这几步入手：

• 先看Worker节点的系统日志（比如/var/log/messages或者dmesg），有没有OOM Killer杀死Spark Worker进程的记录
• 测试Master和Worker之间的网络连通性，用telnet <master-ip> 7077和ping <master-ip>验证基础网络是否正常
• 检查Spark的配置文件（比如spark-env.sh、spark-defaults.conf），确认心跳相关参数（spark.worker.timeout、spark.heartbeat.interval）是否符合集群环境
• 查看监控工具的配置（比如systemd的service文件），确认是不是开启了自动重启Worker的规则

内容的提问来源于stack exchange，提问作者Curious one