📚 课程目录第4章启动日志配置与采集

4. 启动日志配置与采集

还记得我刚开始做WMS那会儿，启动日志就是简单的print到控制台，出了问题全靠脑补。后来系统越来越复杂，才意识到日志配置这件事，搞不好就是给自己挖坑。今天我们就聊聊启动日志的配置和采集，这个话题看似基础，但里面的门道不少。

4.1 日志级别设置

启动阶段日志级别设置，说白了就是决定哪些话该说、哪些话不该说。

常见的日志级别有这几个：TRACE、DEBUG、INFO、WARN、ERROR、FATAL。从TRACE到FATAL，信息量越来越少，严重程度越来越高。你想想看，启动阶段最要紧的是什么？是每个模块的启动状态、耗时、以及异常信息。这些东西用INFO级别完全够用。

启动阶段我建议用INFO级别打底，关键节点用WARN标记。为啥？因为启动日志追求的是"看得见关键路径"，而不是"看到每一行代码"。

我在项目中遇到过好几次这样的场景：新同事一来就把日志级别调到DEBUG，结果启动日志刷了好几万行，真正有用的信息反而被淹没了。我曾经接手过一个项目，启动日志全用DEBUG级别，光是Bean初始化就打印了2万多行，结果线上出了问题，光翻日志就花了半天。嗯，那之后我定了个规矩——生产环境启动日志绝不开DEBUG。

具体来说，我一般这么配：

核心模块启动：INFO级别，记录"模块名 + 启动状态 + 耗时"
配置加载：INFO级别，记录配置项的值（敏感信息脱敏）
外部依赖检查：WARN级别，如果某个依赖超时或失败，必须显式标记
异常堆栈：ERROR级别，只在真正出问题时输出
调试信息：DEBUG级别，仅在本地开发或排查问题时开启

一个小技巧：在启动命令里加一个开关参数，比如 --debug-startup，只有在加了这个参数时才把日志级别降为DEBUG。这样既能保证线上干净，又能在需要时快速打开。

4.2 日志格式规范

格式这个东西，很多人不重视。但我要说，日志格式直接决定了你排查问题的效率。

一个好的启动日志格式，应该包含以下几个字段：

字段	说明	示例
时间戳	精确到毫秒，带时区	2025-01-15 14:30:00.123 +0800
线程名	区分主线程和异步线程	[main] 或 [async-task-1]
日志级别	5位左对齐	[INFO] [WARN]
类名/模块名	精简后的类名或模块标识	[ModuleA] 或 [DataSourceConfig]
启动阶段标识	标记当前处于启动的哪个阶段	[Phase1/5]
耗时标记	记录从启动开始到当前的耗时	[+235ms]
消息体	具体的日志内容	数据源连接池初始化完成，大小=20

我个人习惯用这种格式：

2025-01-15 14:30:00.123 +0800 [main] [INFO]  [DataSourceConfig] [Phase2/5] [+235ms] 数据源连接池初始化完成，大小=20

我曾经吃过一个亏：日志里没有记录启动阶段标识，结果出了问题时，根本不知道日志对应的是启动的哪个环节。后来花了整整一下午才定位到问题。从那以后，我强制要求每个启动日志都必须带上阶段标识和耗时。

4.3 集中式日志采集方案

单机看日志还好说，一旦上了集群，你就不能指望ssh到每台机器上去tail日志了。集中式日志采集是必须的。

我常用的方案是ELK（Elasticsearch + Logstash/Filebeat + Kibana）或者EFK（Elasticsearch + Fluentd + Kibana）。这里我主要讲采集端，也就是日志怎么从应用里出来，送到集中存储。

# Filebeat 配置示例（采集WMS启动日志）
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/wms/startup.log
  fields:
    app: wms
    env: production
    log_type: startup
  fields_under_root: true

output.elasticsearch:
  hosts: ["http://elasticsearch:9200"]
  index: "wms-startup-%{+yyyy.MM.dd}"

集中式采集的几个要点：

采集器要轻量：Filebeat或Fluentd都是不错的选择，资源占用低，不会影响WMS本身
日志要带上下文的元数据：应用名、环境、主机IP、实例ID，这些字段能帮你快速过滤
启动日志单独存索引：别把启动日志和业务日志混在一起，分开存储查询效率高得多
配置采集延迟：启动日志一般不会有延迟要求，但建议设置合理的采集间隔，别太频繁

不同采集方案怎么选？我整理了一张对比表：

方案	资源占用	吞吐量	配置复杂度	适用场景
Filebeat	低	高	低	纯日志采集场景
Logstash	中	中	中	需要复杂过滤转换的场景
Fluentd	低	高	中	容器化或K8s环境

启动日志采集的一个关键点：要保证应用启动完成后，日志能完整地到达集中存储。我见过不少案例，应用启动到一半挂了，日志还在缓冲区没刷出去，结果排查问题时发现日志不完整。解决办法是在启动脚本里加一个flush操作，或者在日志配置里设置immediateFlush=true。

4.4 整体架构与流程

说了这么多，来张图总结一下整个启动日志配置与采集的体系。

说实话，这张图看起来简单，但背后是我踩过不少坑才总结出来的。从日志级别设置到格式规范，再到集中式采集，每一步都有细节需要注意。

总结一句话：启动日志配置的核心目标是"可回溯、可定位、可度量"。可回溯是指能追溯到每次启动的完整日志；可定位是指能快速找到问题根因；可度量是指能从日志中提取出各阶段的耗时数据。

嗯，以上就是启动日志配置与采集的全部内容。日志到位了，数据才能说话。