直接查看 catalina.out 和 catalina.Y-M-D.log 是分析 Tomcat 运行状态最有效方式，前者适合排查启动卡顿、端口冲突等初始问题，后者适合按时间筛查 INFO/WARNING/SEVERE 事件；两者内容重叠但不完全一致，需结合搜索关键错误模式（如 OutOfMemoryError、BindException）及合理配置 logging.properties 实现日志可控可读。
直接看 catalina.out 和 catalina.Y-M-D.log 是分析 Tomcat 运行状态最有效的方式。它不只记录启动失败，更承载了 JVM 输出、应用异常堆栈、类加载过程、甚至部分应用层 System.out 打印内容——这些信息共同构成问题定位的第一手依据。
catalina.out 与滚动日志的区别
catalina.out 是 Tomcat 启动脚本（catalina.sh/.bat）将标准输出（stdout）和标准错误（stderr）重定向生成的单一文件，不会自动按日期轮转，长期运行后体积极易膨胀。而 catalina.Y-M-D.log 是由 JULI（Tomcat 自带的日志框架）按天生成的滚动日志，受 logging.properties 中 FileHandler 配置控制，内容更结构化、级别更可控。
- catalina.out：适合快速排查启动卡顿、JVM 参数错误、端口冲突等“一上来就挂”的问题
- catalina.Y-M-D.log：适合按时间范围筛查特定时段的 INFO/WARNING/SEVERE 级别事件，例如某次发布后出现的连接池耗尽
- 两者内容有重叠但不完全一致——catalina.out 包含更多底层 JVM 日志（如 GC 日志若未单独配置），而滚动日志默认不记录 console handler 的全部输出
快速定位典型错误的关键模式
不用通读全文，用命令或编辑器搜索以下字符串能快速切入问题核心：
- java.lang.OutOfMemoryError：检查是否伴随频繁 Full GC 或堆内存溢出堆栈，需结合 JVM 启动参数（-Xmx/-XX:MaxMetaspaceSize）评估
- java.net.BindException: Address already in use：说明端口被占用，常见于 8005（shutdown）、8080（HTTP）、8009（AJP）端口冲突
- Caused by:（注意冒号后缩进）：这是异常链的根源，比上面的 “Exception at…” 更接近真实原因
- SEVERE [localhost-startStop-1]：通常指向应用初始化失败，比如 Spring Context 加载异常、数据库连接超时、配置文件缺失
让日志真正可读可控的配置要点
默认日志太宽泛，生产环境必须调整。核心在 $CATALINA_HOME/conf/logging.properties：
- 把
1catalina.org.apache.juli.FileHandler.level = INFO改为SEVERE，大幅减少无关 INFO 日志干扰 - 禁用控制台输出：设
java.util.logging.ConsoleHandler.level = OFF，避免 catalina.out 被重复写入 - 启用访问日志（如需）：在
server.xml中取消 AccessLogValve 注释，并设pattern="combined"获取 Referer 和 User-Agent - 限制单个日志大小：添加
1catalina.org.apache.juli.FileHandler.limit = 10000000（10MB）和1catalina.org.apache.juli.FileHandler.count = 5实现自动轮转
日常维护中容易被忽略的实操细节
清理和归档不是简单删文件，否则会丢失上下文或触发重写异常：
- 不要直接
rm catalina.out；应使用cp /dev/null catalina.out清空内容，保留文件句柄 - 滚动日志（catalina.Y-M-D.log）可安全压缩归档，但建议保留最近 7 天原始文件用于快速回溯
- 若发现 catalina.out 持续暴涨，大概率是应用代码中大量使用
System.out.println()或 log4j 配置了 ConsoleAppender 且级别过低，需从应用层修复 - 配合
tail -f logs/catalina.out实时观察启动过程，比反复查看静态文件更高效
