Day 03 · 看日志：tail -f 是吃饭家伙

前两天在认地形、学动手。今天开始像真的在干活了：系统出问题时，答案几乎总在日志里。

今天要敲的

$ cat /etc/hostname                 # 小文件，直接看
$ sudo less /var/log/messages       # 大文件，翻页看，q 退出
$ sudo head -20 /var/log/messages   # 看开头
$ sudo tail -50 /var/log/messages   # 看结尾
$ sudo tail -f  /var/log/messages   # 实时滚动，Ctrl+C 停

先记住日志在哪

这张图比命令更重要

Day 01 说过日志在 /var/log。但那个目录下有几十个文件，你只需要认识这几个：

/var/log/ —— 红帽系（Rocky / RHEL / CentOS）的日志分布

messages: 系统主日志。内核、服务、大部分程序的消息都往这写。不知道去哪找就先看它。
secure: 认证相关：谁登录了、谁 sudo 了、SSH 谁在爆破。查安全问题看这个。
cron: 定时任务的执行记录。第 25 天排查「crontab 不执行」时会用到。
boot.log: 开机启动过程。系统起不来时看它。
dnf.log: 装过、删过、更新过哪些软件包。追查「谁动了这台机器」很有用。
nginx/: 各个服务自己的日志一般在同名子目录下，比如 nginx/access.log、nginx/error.log。

Ubuntu 的不一样

Ubuntu 系统主日志叫 syslog，认证日志叫 auth.log。红帽系是 messages 和 secure。面试时说对这两个名字，就说明你确实在红帽系上干过。

`cat`

小文件直接倒出来

concatenate。把文件内容整个打印到屏幕上。只适合小文件——对着几百 M 的日志敲 cat，屏幕会疯狂滚动好几分钟，只能 Ctrl+C 打断。

合适的场景

$ cat /etc/hostname          # 一行内容
$ cat /etc/resolv.conf       # 几行的配置
$ cat -n /etc/hosts          # -n 显示行号

`less`

大文件就用它

less 把文件分页显示，不会刷屏，而且不会把整个文件读进内存——几个 G 的日志也能瞬间打开。

很多人只会一个 q 退出。其实这几个键才是它值钱的地方：

在 less 里面按这些键

空格 / b: 向下翻一页 / 向后翻一页。
G: 跳到文件末尾。看日志最常用——最新的记录都在最后。
g: 跳回文件开头。
/关键词: 向下搜索。比如 /error 回车。
n / N: 跳到下一个 / 上一个匹配。
q: 退出。

一个高频组合

打开大日志 → 按 G 跳到最后 → 按 / 搜 error → N 往回找最近一次报错。这套动作你以后一天要做好几遍。

`head` 和 `tail`

只看头几行、尾几行

默认 10 行，-n 指定

$ sudo head /var/log/messages       # 开头 10 行
$ sudo head -20 /var/log/messages   # 开头 20 行
$ sudo tail /var/log/messages       # 结尾 10 行
$ sudo tail -50 /var/log/messages   # 结尾 50 行 ← 最常用

日志是往下追加的，所以最新的事情永远在最后。这就是为什么 tail 用得比 head 多得多。

`tail -f`

今天真正的主角

-f 是 follow。敲下去之后命令不会结束，它会挂在那里，日志一有新内容就实时滚出来。

实时跟踪

$ sudo tail -f /var/log/messages
Sep  7 10:12:03 rocky systemd[1]: Started nginx.
Sep  7 10:12:44 rocky sshd[2841]: Accepted password for devops
▏ 光标停在这，等新日志…… 按 Ctrl+C 退出

真正的用法：开两个窗口

这才是 tail -f 的价值所在，也是今天最该学会的工作方式：

排障时的标准姿势

窗口 A: 挂着 sudo tail -f /var/log/messages，什么都不干，就盯着。
窗口 B: 去复现问题——重启服务、访问网页、执行那个出错的操作。
结果: 报错会在窗口 A 实时滚出来，你能精确看到「做了什么动作 → 冒出什么错」。

为什么这招管用

事后翻日志，你得在几千行里找哪条是刚才那个错。挂着 tail -f 再去操作，新冒出来的就是你要找的——省掉大量翻找时间。

第 14 天「自己搞坏 nginx 再修好」，用的就是这个方法。

`-f` 和 `-F` 的区别

这个细节很多教程不讲，但生产环境天天遇到：

小写 f 会跟丢，大写 F 不会

$ tail -f /var/log/messages
  ↑ 盯住「这个文件」。日志被切割改名后，你盯的还是那个旧文件，
    屏幕就再也不动了 —— 看着像没日志，其实是跟丢了

$ tail -F /var/log/messages
  ↑ 盯住「这个文件名」。文件被切割重建后，自动接着跟新的

什么时候会遇到

系统每天凌晨会自动切割日志（第 29 天讲的 logrotate）。如果你的 tail -f 挂了一整夜，第二天早上它多半已经跟丢了。养成用 -F 的习惯就没这问题。

配合 grep 过滤

日志太多的时候

Day 01 学的管道，今天派上用场：

几个高频组合

# 只看包含 error 的行（-i 忽略大小写）
$ sudo grep -i error /var/log/messages | tail -20

# 实时跟踪，但只显示报错
$ sudo tail -f /var/log/messages | grep -i --line-buffered error

# 看报错的前后各 5 行（上下文往往才是真正的原因）
$ sudo grep -i -A5 -B5 error /var/log/messages | tail -40

# 数一数今天出了多少次错
$ sudo grep -ci error /var/log/messages

-A 和 -B 值得专门记

-A5 是 after，-B5 是 before。只看报错那一行，经常看不出原因；它前面几行往往写着「正在做什么」，后面几行写着「所以退出了」。看上下文，是新手和熟手的分界线之一。

顺带提一句 journalctl

第 13 天详讲

你可能会发现，有些服务的日志在 /var/log/messages 里找不到。因为 systemd 时代还有一套自己的日志系统：

先混个眼熟

$ sudo journalctl -u sshd        # 只看 sshd 这个服务的日志
$ sudo journalctl -f             # 效果类似 tail -f

今天不用深究，知道有这么个东西就行。第 13 天会专门讲，那时候你已经习惯看日志了，学起来很快。

今天的面试点

这两句一说，对方就知道你真干过

「服务出问题，你第一步做什么？」

「开一个窗口挂着 tail -f 看日志，另一个窗口去复现操作，报错会实时滚出来，能直接定位是哪一步出的问题。」

这个回答描述的是一套工作方法，不是一个命令。面试官一听就知道你不是背的。

「日志那么多，怎么找报错？」

基础答案：grep -i error 配合 tail。

加分答案：「我一般会用 grep -A5 -B5 看报错的上下文——光看报错那一行经常不知道原因，前后几行才有线索。」

今天的练习

敲完再走 · 约 12 分钟

cat /etc/hostname，再 sudo cat /var/log/messages 感受一下差别（然后 Ctrl+C 打断它）
用 less 打开 /var/log/messages，练一遍：G 跳末尾 → /error 搜索 → N 往回找 → q 退出
重点：开两个终端窗口。A 窗口挂 sudo tail -f /var/log/secure，B 窗口敲 sudo ls，看 A 窗口有没有实时冒出记录
试试 sudo grep -i -A3 -B3 error /var/log/messages | tail -30，体会上下文的作用
敲一次 sudo journalctl -u sshd | tail -20，混个眼熟

明天预告

Day 04 是 vim 活命三招。真的只有三招——服务器上没有记事本，改配置只能靠它，但你完全不需要学那些花哨操作。