故障信息收集：日志收集、现场信息采集、用户反馈整理、环境快照
故障复现的第一步，说白了就是「把现场封存好」。
我见过太多工程师，一上来就急着翻代码、查逻辑，结果折腾半天发现——日志不全、环境变了、用户说的和实际对不上。白白浪费一整天。
信息收集不是体力活，是技术活。你得知道：该收什么、怎么收、收完怎么管。
2.1 日志收集——故障分析的「第一手证据」
日志是故障现场最直接的记录。但很多人有个误区：日志越多越好。其实不是。
我个人习惯是：先定范围，再动手收。
2.1.1 日志分类与优先级
| 日志类型 | 优先级 | 典型内容 | 收集要点 |
|---|---|---|---|
| 应用日志 | ★★★★★ | 业务异常、调用链、错误堆栈 | 保留完整时间戳，不要截断 |
| 系统日志 | ★★★★☆ | 内核报错、OOM、磁盘I/O异常 | 关注故障前后各30分钟 |
| 中间件日志 | ★★★★☆ | 数据库慢查询、MQ堆积、连接池耗尽 | 收集配置文件和运行日志 |
| 网络日志 | ★★★☆☆ | 丢包、重传、延迟抖动 | 配合tcpdump抓包更佳 |
| 硬件日志 | ★★★☆☆ | 温度、电压、风扇转速 | IPMI/BMC日志不可忽略 |
我的习惯：每次收日志前，先画一条时间线。把故障发生时间、首次发现时间、影响范围标出来。然后按时间线切分日志，只保留「故障前10分钟到故障后5分钟」的核心窗口。剩下的归档，但不删。
2.1.2 日志收集的「三要三不要」
- 要保留原始格式——别用Excel打开再另存，格式会乱。直接用
cat或tail导出纯文本。 - 要记录收集时间——你什么时候拿到的日志？这个时间本身也是线索。
- 要校验完整性——用
wc -l对比行数，用md5sum做校验。 - 不要只收错误级别——INFO和DEBUG里经常藏着关键上下文。
- 不要覆盖旧日志——每次收集单独建文件夹，别覆盖。
- 不要用压缩工具直接打开——解压到临时目录再查看，避免文件损坏。
我曾经踩过的坑：有一次线上故障，我让运维把应用日志发给我。他直接 tar.gz 打包，然后通过即时通讯软件传过来。结果解压时发现文件头损坏，日志全废了。后来我定了个规矩：日志传输必须带校验和，且保留原始压缩包。
2.2 现场信息采集——别让「环境」成为变量
故障复现最怕什么？最怕环境变了。
你想想看，开发环境跑得好好的，生产环境就崩。为什么？因为环境不一样。所以现场信息采集，核心就是把「环境快照」拍下来。
2.2.1 环境快照清单
| 采集项 | 命令/工具 | 关键信息 |
|---|---|---|
| 操作系统版本 | cat /etc/os-release |
内核版本、发行版、补丁级别 |
| 资源使用率 | top / htop / free -m |
CPU、内存、Swap使用情况 |
| 磁盘状态 | df -h / iostat -x 1 |
分区使用率、I/O等待时间 |
| 进程快照 | ps aux --sort=-%mem |
进程列表、资源占用、启动时间 |
| 网络连接 | ss -tuln / netstat -anp |
监听端口、连接状态、对端地址 |
| 依赖服务状态 | systemctl status |
数据库、缓存、消息队列是否正常 |
核心原则：环境快照必须在「故障未恢复」或「刚恢复但未重启」时采集。一旦重启，很多线索就没了——比如临时文件、进程状态、网络连接。
2.2.2 现场采集的「五步法」
- 先拍照，后动刀——任何操作之前，先把当前状态完整记录一遍。
- 按层级采集——从硬件→操作系统→中间件→应用，逐层往下。
- 关注异常值——CPU 100%？内存快满了？磁盘I/O飙升？这些是重点。
- 保留原始输出——别只看摘要，把
top的完整输出、dmesg的全文都存下来。 - 标记时间戳——每条记录前面加上
date输出，方便后续对齐。
2.3 用户反馈整理——别信「感觉」，要信「数据」
用户反馈是最容易出偏差的信息源。
我遇到过用户说「系统卡死了」，结果一看监控，CPU才用了5%。后来追问才知道，他说的「卡死」其实是某个页面加载慢，等了10秒。
所以，用户反馈必须结构化整理。
2.3.1 用户反馈模板
| 字段 | 说明 | 示例 |
|---|---|---|
| 故障时间 | 精确到秒，注明时区 | 2025-03-15 14:23:05 CST |
| 操作路径 | 用户做了什么操作 | 点击「订单查询」→输入单号→点击「搜索」 |
| 预期结果 | 用户认为应该出现什么 | 页面显示订单详情 |
| 实际结果 | 用户实际看到了什么 | 页面白屏，浏览器控制台报错 |
| 影响范围 | 多少人受影响 | 该用户所在部门共15人 |
| 复现频率 | 每次必现/偶发/首次 | 偶发，今天出现3次 |
我的做法：让用户录屏。录屏比文字描述靠谱100倍。如果条件不允许，至少让用户截图，并标注操作顺序。
2.3.2 用户反馈的「三问法」
- 第一问：你做了什么？——还原操作路径。
- 第二问：你看到了什么？——记录实际现象。
- 第三问：你觉得应该是什么？——确认预期结果。
这三问问完，80%的模糊信息都能澄清。剩下的20%，靠日志和环境快照来交叉验证。
2.4 信息归档——让每一条线索都可追溯
信息收集完了，不是扔到一个文件夹就完事。你得让后续的排查人员（包括未来的你自己）能快速找到需要的东西。
2.4.1 归档目录结构
fault_20250315_142305/
├── 01_logs/
│ ├── app_logs/
│ ├── sys_logs/
│ └── middleware_logs/
├── 02_env_snapshot/
│ ├── os_info.txt
│ ├── resource_usage.txt
│ ├── process_list.txt
│ └── network_status.txt
├── 03_user_feedback/
│ ├── feedback_form.md
│ ├── screenshots/
│ └── screen_recording.mp4
├── 04_config_backup/
│ ├── application.yml
│ └── nginx.conf
└── README.md
注意：README.md 里必须写清楚「收集时间」「收集人」「故障简述」「已知线索」。别偷懒，这个文件能救你的命。
2.5 信息收集的核心逻辑图
下面这张图，是我自己总结的信息收集流程。每次做故障排查前，我都会过一遍。
2.6 本章小结
信息收集是故障复现的基石。你收集得越完整、越规范，后续的定位就越快。
我个人总结了三句话，每次做故障排查前都会默念一遍：
- 日志要全，但别贪多——按时间窗口切分，保留原始格式。
- 环境要快照，别等重启——重启前把现场拍下来。
- 用户反馈要结构化，别信感觉——用模板、录屏、截图说话。
记住：好的信息收集，能让故障定位时间缩短50%以上。反之，信息不全，你就是在盲人摸象。