7.3 启动与部署故障排查

7.3 启动与部署故障排查

本节摘要：故障排查第一战场：服务起不来与应用部署失败。本节给两条决策树——启动失败的四个分支（端口占用、JDK 版本、配置解析、权限）、部署失败的四个分支（结构缺目录、依赖冲突、描述符错误、热部署残留），每个分支配真实日志样例与处置命令。学完你面对"起不来"与"发不上去"两类工单，能按图索骥十分钟内定位。

观测面已建好（7.2），现在实战。两类故障最高频也最紧急：启动失败让整条管道瘫痪，部署失败让发布窗口无限延长。方法论只有一句：从日志末尾的异常往上找第一个出错的行——决策树的每个分支都从一条特征日志进入。

决策树一：服务起不来

图 7-3：启动故障排查决策树

四个分支里前两个一分钟可断，第三个要对行号，第四个多见于换机器迁移。各配一段真实日志。

端口占用的日志长这样，末尾一行带地址与端口，顺着它查进程即可（2.1 预演过处置）。

严重 [main] org.apache.catalina.core.StandardServer.await
StandardServer.await: create[localhost:8005]:
 java.net.BindException: Address already in use
​

版本不配在启动脚本阶段就被拦下，日志直接点名主版本数字。处置对着 1.3 的锁定表二选一：升级 JDK 或者换用低线 Tomcat。最隐蔽的是权限分支：日志提示无法写临时目录或日志目录，服务起一半僵住——用运行账户手动写一下各目录试出病灶，容器化部署里挂载卷权限不对是高发原因。

配置解析分支值得多说一句，因为新手最容易被它的报错带偏：报错给的是元素名与行号，不是"你哪里写错了"。典型如自闭合标签误删斜杠、属性值引号缺失。拿行号直接翻文件，别盯着报错文字猜语义。改 server.xml 前留一份备份，是排障时能随时回到已知好状态的底气。

决策树二：应用部署失败

服务起来了，应用发布后报 404 或起不来，问题进入部署域。四个分支按检出顺序排。

分支一，结构缺目录：应用的 WEB-INF 不存在或 web.xml 缺失，部署日志直接说找不到部署描述符。处置检查打包产物——构建脚本的资源目录配置错误是常见根因，产物里少了什么，回去补构建，而不是在服务器上手创目录。

分支二，依赖冲突，日志特征是类找不到或类转换异常，栈里带应用或容器的类加载器字样。

严重 [main] org.apache.catalina.core.StandardContext.startInternal
上下文 [订单应用] 启动由于之前的错误而失败
java.lang.ClassNotFoundException: postgresql 驱动类名
​

处置思路两条线：驱动到底进没进包（应用级资源该在应用的库目录）；若走的是全局数据源，驱动必须放容器 lib——5.3 的"谁的类放谁家"在此兑现。同一病灶还有一种变形：应用带的库与容器已有的库版本冲突，表现是莫名的方法不存在，处置是剔除应用内与容器重复的公共包。

分支三，描述符错误：web.xml 元素顺序不对或值非法，日志给出元素名。对照 4.3 讲过的元素顺序规范检查即可。

分支四，热部署残留：表现为"反复部署同一应用"或"改了配置没生效"。前者查三件事——reloadable 是否开着（4.3 的建议是生产关掉）、发布脚本是否循环触发、autoDeploy 是否误判包更新；后者最阴险，是旧 Context 的类加载器没释放，同路径新应用与旧实例并存，改了"看起来对"的文件却毫无反应。处置：重启实例清干净，再修根因（补 5.3 的销毁清理，或改用受控发布）。

💡 关键直觉：部署类故障的日志几乎都在 localhost 日志而非 catalina 日志里——两份日志的分工在 7.2 的表格里。找错文件看半天，是排障时间的第一浪费源。

两个分支的日志样例与平台注意

配置解析分支的真实日志长这样，行号与元素名都在，处置就是翻文件对行号。

严重 [main] org.apache.tomcat.util.digester.Digester.fatalError
解析错误 at line 87 column 11：元素 Connector 未闭合
catalina.startup.Catalina.start 服务初始化失败
​

权限分支的日志特征是"无法写入"字样，多见于迁移机器或容器化挂载卷之后。

严重 [main] org.apache.catalina.core.StandardService.startInternal
无法创建目录用于日志输出：logs 目录不可写
java.io.FileNotFoundException：日志文件拒绝访问
​

两条平台差异值得记录。Windows 上排查端口占用用网络统计命令按端口找进程标识，日志语义与 Linux 一致；权限分支在 Windows 上常因"用管理员装、用普通账户跑"产生，统一运行账户即可根治。容器环境里再加一条：挂载卷的属主必须与容器内运行账户一致，否则权限分支会以"起一半僵住"的形态反复出现。

给容器化部署单独留三行速记：镜像里预建 logs 与 temp 目录并放权限；健康检查探针打管理端的站点状态接口而非首页静态资源；启动脚本先校验配置文件可读再点火，把"起不来"的爆炸半径压到秒级发现。

本节要点回顾

• 一条方法论：从日志末尾的异常往上找第一个出错行，决策树按特征日志进入分支。
• 启动四分支：端口、版本、配置解析、权限，前两个一分钟可断。
• 部署四分支：缺目录、依赖冲突、描述符错误、热部署残留，各自有特征日志。
• 类归属原则反复兑现：驱动与公共库放哪一侧，5.3 的规则直接给出答案。
• 部署故障看 localhost 日志：找对文件是排障效率的第一步。

最后一节把两类高级故障收尾：线上变慢与安全加固——前者用线程转储与垃圾回收日志说话，后者是一份可以直接执行的清单。