为什么要先固定证据
排障现场的很多信息是一次性的：终端滚屏会被覆盖，环形缓冲区写满就丢旧数据，连接表在重启后清空，抓包文件如果没落盘就没有第二次机会。凡是结论需要交给别人复核、或需要向运营商与云厂商举证的问题，都要求先把证据固定下来再动手修复。固定证据的动作本身很轻，代价却是省掉一次「问题不再复现、无法解释」的尴尬。
基本信息
| 要保留什么 | 命令输出、抓包、配置快照、日志片段与统一的时间戳 |
|---|---|
| 工具 | script、tee、tcpdump -w、journalctl --since、配置备份 |
| 原则 | 先留证据再做修复，证据与应用现象要能对应 |
| 目录规范 | 按时间与故障编号归档，避免覆盖 |
| 合规 | 抓包可能含用户数据与凭据，留存与传递需走内部流程 |
典型使用场景
- 间歇故障：长期抓包与日志留存，等待问题再次出现
- 向云厂商或运营商报障：附带证据包的问题处理更快
- 跨团队交接：把证据与时间线一并移交，减少重复排查
- 变更前留底：出问题时可以比对变更前后差异
- 复盘与改进：用过程记录还原当时的判断依据
会话录制与输出留存（Linux）
会话录制与输出留存（Linux）
script -t 2> /tmp/ts.log -a /tmp/session.txt # 录制整个终端会话
ip route | tee -a /tmp/evidence.log
journalctl --since '30 min ago' -u nginx > /tmp/nginx.30min.log
tcpdump -i any -nn -w /tmp/trace.pcap 'host 10.0.0.5 and port 443'
dmesg -T > /tmp/dmesg.log # 内核日志带可读时间配置快照
配置快照
tar czf /tmp/etc-snapshot.tgz -C / etc/nginx etc/sysconfig etc/sysctl.conf etc/sysctl.d 2>/dev/null
ss -s > /tmp/socket-summary.txt # 套接字汇总快照
ip -br a > /tmp/addr-snapshot.txt; ip route > /tmp/route-snapshot.txt # 地址与路由快照证据类型与留存方式
| 证据类型 | 留存方式 | 关键点 |
|---|---|---|
| 命令输出 | tee 或重定向到文件 | 带上时间戳，含命令原文 |
| 终端会话 | script 录制 | 包含交互过程，便于交接 |
| 抓包 | tcpdump -w 落盘并滚动 | 必须加过滤器，避免写满磁盘 |
| 日志 | journalctl 按时间窗导出 | 与应用错误时间对应 |
| 配置 | 打包归档并记录校验值 | 变更前先留一份 |
| 内核状态 | dmesg 与参数快照 | 重启即丢失，优先采集 |
抓包文件可能含业务数据与凭据，例如明文口令或令牌：留存与传递要走内部安全流程，事后按保留期限清理。