📚 课程目录第1章日志基础

升级日志分析与问题定位 - 第1节

一、日志基础：日志是什么？为什么升级需要看日志？

聊到日志，很多刚入行的同学会觉得——不就是打印点信息出来看看嘛？

嗯，这话对，也不全对。我做了这么多年SRE，处理过上百次线上事故，可以很负责任地告诉你：日志是系统的“黑匣子”，是事故现场的“第一目击证人”。尤其是在升级场景下，日志几乎是唯一能还原真相的线索。

说白了，日志就是系统在运行过程中，按时间顺序记录下来的“行为轨迹”。

它记录了：

举个例子，你升级了一个微服务，重启后用户反馈登录失败。如果没有日志，你只能靠猜——是代码没更新？配置没生效？还是数据库连不上了？

但如果有日志，你一眼就能看到：

2025-01-15 14:32:18.123 ERROR [auth-service] [http-nio-8080-exec-3] c.u.a.LoginController : 登录失败，用户ID=10086，原因：数据库连接超时

问题在哪，一目了然。

核心观点：日志是升级过程中唯一可信的“事实依据”。没有日志，一切排查都是盲人摸象。

升级这件事，本质上就是在“动手术”。你想想看，一个运行得好好的系统，你改了它的代码、配置、依赖，甚至底层环境——不出问题的概率其实很低。

我个人习惯是：每次升级前、升级中、升级后，日志必须全程盯着。原因有三：

验证升级是否生效——日志里会打印版本号、启动信息、加载的配置项。看一眼就知道新版本有没有跑起来。
快速定位异常——升级后如果出现报错，日志里通常会有堆栈信息。我曾经遇到过一次升级后内存飙升，查了监控没发现异常，最后是日志里的一条“连接池耗尽”暴露了问题。
回滚决策依据——升级后如果错误率持续上升，日志能告诉你：是兼容性问题？还是数据迁移失败？还是新代码有bug？这些信息直接决定你要不要回滚。

我的经验：升级前先看一眼日志的“基线状态”——比如正常时每分钟有多少ERROR日志。升级后如果ERROR量突然翻倍，基本可以判定升级有问题。

日志级别这个东西，看起来简单，但实际用起来很多人会搞混。我见过不少项目，所有日志全用INFO，或者全用ERROR——这其实是在给自己挖坑。

下面这张图，是我自己总结的日志级别金字塔：

级别	含义	生产环境是否开启	典型场景
DEBUG	调试信息，最详细的运行细节	通常关闭	开发环境排查逻辑问题、变量值
INFO	关键业务流程记录	开启	服务启动、请求处理、状态变更
WARN	潜在风险，不影响当前运行	开启	配置即将过期、重试次数超限
ERROR	功能异常，需要人工介入	开启	数据库连接失败、接口返回500
FATAL	系统崩溃，无法自动恢复	开启	OOM、磁盘写满、主进程退出

我拿一次真实的微服务升级来举例：

避坑指南：我曾经遇到过一个项目，所有异常都只打WARN级别，结果线上出了严重问题，运维以为是“警告而已”，拖了半小时才处理。记住：该用ERROR的时候别手软，否则你的告警就是“狼来了”。

我总结了几条经验，分享给你：

INFO是主力，别滥用——INFO应该记录“业务关键路径”，而不是“每行代码都打”。否则日志会变成噪音。
ERROR要带上下文——光打一句“登录失败”没用，要带上用户ID、请求参数、异常堆栈。否则你拿到日志也查不出原因。
FATAL别乱用——只有“系统无法继续运行”时才用FATAL。普通的业务异常用ERROR就够了。
DEBUG只在需要时开——生产环境默认关闭DEBUG。升级排查时可以临时开启，但记得关掉。我见过有人开了DEBUG忘了关，一天产生了几十G日志，磁盘直接打满。

一个小技巧：在代码里给每个日志级别加上“唯一标识符”。比如ERROR日志统一以“ERR_”开头，这样在日志平台里搜索“ERR_”就能快速过滤出所有异常。我在团队里推行这个习惯后，排查效率提升了至少30%。

日志不是“可有可无”的东西。它是升级过程中最忠实的记录者，也是你排查问题的第一把钥匙。

记住三点：