一、启动日志基础：从一次线上事故说起
我记得刚接手第一套生产环境时，遇到过这么一件事：凌晨三点，告警电话响了。某个核心服务挂了，重启后还是起不来。我登录上去一看，启动日志里只有一行「Error: connection refused」。就这一行，排查了整整两个小时——后来发现是依赖的缓存集群先挂了，服务启动时连不上，直接退出了。
你想想看，如果当时启动日志能多输出几行关键信息，比如「正在连接缓存集群...失败，重试第1次...重试第3次...放弃启动」，我至少能省下一个半小时。从那以后，我对启动日志的态度就变了——它不只是给机器看的，更是给我们这些半夜爬起来救火的人看的。
1.1 什么是启动日志
启动日志，说白了就是应用从开始启动到完全就绪这段时间里，输出的所有日志信息。它记录了初始化过程中的每一个关键步骤：配置加载、资源申请、依赖检查、服务注册……
我习惯把启动日志比作「飞机的起飞检查单」。飞行员起飞前要逐项确认：油量、引擎、仪表、通讯……每一项都得正常。启动日志就是应用的「起飞检查单」——它告诉你每个环节是否通过，如果没通过，卡在了哪一步。
启动日志 vs 运行日志：运行日志记录的是服务正常工作时的行为，而启动日志记录的是服务「从死到活」的过程。两者关注点完全不同。启动日志更关注初始化顺序、依赖状态、配置有效性——这些信息在服务运行后反而很少出现。
1.2 启动日志的重要性
为什么我要单独开一章讲启动日志？因为它太容易被忽视了。很多团队把精力都放在业务日志上，觉得启动就那么几秒钟，能出什么问题？
我经历过几次惨痛教训后，总结出启动日志的三大价值：
- 故障定位的第一现场——服务起不来，启动日志是唯一的线索。没有它，你只能靠猜。
- 变更验证的关键依据——每次发布、配置变更后，启动日志能第一时间告诉你「这次改动有没有搞砸」。
- 依赖关系的活地图——启动顺序暴露了服务间的依赖链条。哪个先启动、哪个后启动、哪个启动失败会导致连锁反应——日志里全写着。
我的习惯：每次上线新服务，我都会先看一遍它的启动日志。不是为了找问题，而是为了建立「正常启动的基线」。这样下次出问题时，我一眼就能看出哪里不对劲。
1.3 日志级别：DEBUG / INFO / WARN / ERROR / FATAL
日志级别这东西，看起来简单，但用好的团队真不多。我见过把整个启动过程全打INFO的，也见过启动时疯狂输出DEBUG导致日志文件撑爆磁盘的。
先看标准定义：
| 级别 | 含义 | 启动场景示例 | 我的建议 |
|---|---|---|---|
| DEBUG | 调试信息，开发阶段使用 | 「加载配置文件: /etc/app.yml，读取key=db.host，值=127.0.0.1」 | 生产环境默认关闭，排查问题时临时开启 |
| INFO | 关键步骤，正常流程 | 「数据库连接池初始化完成，大小=20」 | 启动过程的核心步骤必须打INFO |
| WARN | 潜在问题，不影响启动 | 「配置项timeout未设置，使用默认值30s」 | 不要忽略WARN，它往往是隐患的前兆 |
| ERROR | 明确错误，启动可能失败 | 「连接数据库失败: timeout after 10s」 | ERROR必须附带上下文信息，不能只给一句话 |
| FATAL | 致命错误，启动立即终止 | 「核心依赖组件缺失，服务无法启动」 | FATAL后必须执行优雅退出，不能直接kill -9 |
这里有个容易踩的坑：ERROR和FATAL的区别。我曾经见过一个团队，所有启动失败都打ERROR，然后继续往下跑。结果服务虽然启动了，但核心功能全废了，用户请求进来直接500。这就是级别用错了——该用FATAL的地方用了ERROR。
避坑指南：我曾经接手过一个遗留系统，启动日志里全是INFO，连「正在加载第3个插件」这种细节都打INFO。结果生产环境出问题时，几千行INFO日志里根本找不到关键信息。后来我强制要求：启动日志中，每个ERROR/FATAL必须附带「失败原因+影响范围+建议操作」。比如「连接数据库失败(ERROR) → 缓存服务将降级为本地模式(WARN) → 用户登录功能不可用(FATAL)」——这样一看就明白。
1.4 启动日志的知识体系
为了让你更直观地理解启动日志在整个运维体系中的位置，我画了张图：
1.5 一个真实案例：级别用错的代价
讲个真实的事。去年我帮一个团队排查线上问题，他们的支付服务每天早上八点准时重启，持续了三天。我看了启动日志，发现一个诡异的现象：
2024-03-15 07:59:58.123 INFO [main] 加载支付网关配置... 成功
2024-03-15 07:59:58.456 INFO [main] 连接银行接口... 超时
2024-03-15 07:59:58.457 INFO [main] 重试连接银行接口... 超时
2024-03-15 07:59:58.458 INFO [main] 重试连接银行接口... 超时
2024-03-15 07:59:58.459 INFO [main] 重试连接银行接口... 超时
2024-03-15 07:59:58.460 INFO [main] 服务启动完成，监听端口8080看出来问题了吗？银行接口连接超时，打了INFO级别，然后重试三次都超时，还是INFO。最后服务「启动成功」了——但所有支付请求进来都报错。因为核心依赖没连上，服务虽然活着，但功能是残废的。
这就是典型的级别滥用。正确的做法应该是：
- 第一次超时 → WARN（潜在问题，但还在重试）
- 重试全部失败 → ERROR（明确失败，需要人工介入）
- 核心依赖不可用 → FATAL（服务不应继续启动）
我的建议：写启动日志时，问自己三个问题——
- 这行日志如果丢了，排查问题时会不会抓瞎？ → 打INFO以上
- 这行日志如果出现，是不是意味着有隐患？ → 打WARN
- 这行日志如果出现，服务还能正常干活吗？ → 打ERROR或FATAL
记住：INFO是给正常人看的，DEBUG是给你自己看的，WARN/ERROR/FATAL是给半夜被叫醒的人看的。
1.6 小结
启动日志不是什么高深的技术，但它决定了你出问题时是「十分钟搞定」还是「通宵排查」。这一章我们聊了：
- 启动日志是服务从启动到就绪的完整记录
- 它在故障定位、变更验证、依赖分析中不可替代
- 五个日志级别各有用途，用错了会付出代价