为什么要集中采集
一次存储故障往往同时在多个位置留痕：阵列事件日志记录卷与盘状态变化，交换机记录端口错误，主机内核记录路径切换与重试，应用记录超时。这些日志分布在四五个系统里且滚动保留，出问题时最常遇到的局面是「关键时间段的那段日志已经被覆盖」。集中采集解决的是时间轴对齐与保留期两个问题，也让分析从逐条阅读变成按事件回溯。
基本信息
| 日志来源 | 阵列与控制器事件日志、扩展柜、交换机、主机内核与多路径、应用层 |
|---|---|
| 采集方式 | 系统日志转发、厂商工具导出、脚本定时采集、审计日志订阅 |
| 保留策略 | 按容量与合规要求设定，关键设备保留期应覆盖故障复盘周期 |
| 分析前提 | 各设备时间同步且时区一致，否则跨设备关联无从谈起 |
| 分析维度 | 时间轴、设备与槽位、错误类型、与业务变更的时间关联 |
| 典型失败 | 只在设备本地查询、日志量过大冲掉历史、跨设备时区不一致 |
典型使用场景
- 故障复盘需要还原某个时间点的完整事件链时
- 合规或审计要求提供指定时间段的存储操作与状态记录时
- 排查间歇性问题，需要把多次事件跨设备对齐比较时
- 交接或厂商升级工单，需要打包完整日志证据时
- 分析历史慢盘与链路错误，判断是否为长期累积问题时
集中转发与按需导出
集中转发与按需导出
# 主机侧：把日志转发到集中服务器（@ 为 UDP，@@ 为 TCP）
# 在 rsyslog 配置中追加转发规则后重载服务
# *.* @@logserver.example.com:514
# 按时间窗导出内核日志，便于与阵列事件对齐
journalctl -k --since '2026-01-01 08:00' --until '2026-01-01 10:00' > /tmp/kernel-window.log
# 定时归档关键统计，避免设备本地日志被冲掉
iostat -x 1 5 >> /var/log/archive/iostat-$(date +%F).log
# 阵列与交换机日志按厂商工具导出，导出后与主机日志按时间轴合并来源与采集要点
| 来源 | 采集方式 | 关注点 |
|---|---|---|
| 阵列事件日志 | 厂商工具导出或系统日志转发 | 保留期与导出频率 |
| 交换机 | 系统日志转发与端口统计导出 | 端口错误与 zone 变更记录 |
| 主机内核与多路径 | journalctl 导出与转发 | 路径事件与重置时间点 |
| 应用日志 | 应用侧集中采集 | 超时与错误的发生时刻 |
日志分析先对齐时间再谈内容。跨设备时间不同步时，你会看到「交换机记录端口错误，但主机在三分钟后才报 IO 异常」这种假象，从而把因果顺序判反。
只依赖设备本地日志是高风险习惯：设备日志缓冲区有限，故障发生后如果无人及时导出，重启或继续运行都会把关键证据冲掉。