读飞牛的日志：几个真实故障的排查路径
日志不是给程序员看的，是给遇到问题的人看的。会看几条关键记录，能省下重装的时间。
NAS 出问题时，日志里基本都留了痕迹。难的不是找不到日志，是不知道该看哪一行。
这篇用几个典型故障，演示一下日志怎么读。
先知道去哪看
飞牛的日志中心里有分类：系统日志、应用日志、登录日志、诊断日志。界面上能按时间、级别筛选。
想看更底层的，SSH 进去用 journalctl 和 dmesg。
案例一：硬盘突然掉线
现象：存储空间提示降级，某块盘不见了。
看哪里：内核日志 dmesg，或者日志中心里的系统日志。
典型的记录长这样：
ata3: link is slow to respond, please be patient
ata3: hard resetting link
ata3: SError: { RecovComm }
怎么读：ataX 对应某个 SATA 接口。link reset、SError 说明通信中断了。
先怀疑线材和供电——换根 SATA 线、换电源接口、换插槽。如果换了还这样，再跑 SMART，多半是盘的问题。
案例二：服务起不来
现象：某个应用打不开，界面转圈。
看哪里：journalctl -u 服务名 -n 100，或者应用自己的日志目录。
常见原因：
- 端口被占：日志里写着
bind: address already in use； - 权限不够：
Permission denied，指向某个目录或设备； - 配置语法错：
unexpected token、invalid configuration； - 依赖服务没起来：连不上数据库、连不上 Redis。
怎么读：从最后一行往上找第一个 ERROR，通常那一行就是根因，后面的是连锁反应。
案例三：远程访问时断时续
现象：外网访问 NAS 有时候能开，有时候超时。
看哪里：系统日志里的网络相关记录，路由器的连接日志，以及服务自身的访问日志。
关注：
- 有没有反复的
link down/link up：网线或网卡问题； - 有没有大量来自陌生 IP 的失败登录：扫描；
- 时间是否准确：时间偏差会导致证书校验失败。
案例四：备份任务失败
现象：计划任务里的备份昨晚没跑完。
看哪里：计划任务的执行日志，加上备份工具自己的输出。
常见线索：
No space left on device：目标盘满了；Connection timed out：网络中断；Permission denied：目标端权限变了；- 进程被 OOM 杀掉：内存不够。
读日志的通用方法
- 先定位时间点：问题什么时候发生的，就筛那一段；
- 从下往上找第一个错误，不要被后面的连锁报错带偏；
- 关注关键词：
error、fail、timeout、denied、reset、OOM； - 对比正常时段：出问题前后的日志差异，往往直接给出答案；
- 别只看一个来源：系统日志说没问题，可能是应用层的问题。
常见的坑
日志刷屏：某个服务疯狂报错，把有用的信息淹了。先停掉那个服务再排查。
时区不对：日志时间和你的时间差 8 小时，找错时段。
只看级别高的：WARNING 里经常藏着根因。
日志被清空：重启或清理任务把日志删了，问题现场就没了。出问题先别重启。
小结
日志的价值不在于「有没有报错」，而在于报错的时间顺序。
养成一个习惯：出问题时先看日志、再动手。重启能解决一时，但解决不了根因，还会把线索抹掉。
留言