搜「Linux查看日志的命令是什么」的人，通常不是想背命令清单，而是已经登上一台机器，想知道日志在哪、用哪个命令能立刻看到最近出错的那几行、要不要跟着滚。最省事的起步方式是先用 ls /var/log 确认日志目录里有什么，再用 tail -n 50 看文件尾部，遇到需要持续观察时再用 tail -f 或 journalctl -f。具体走哪条路，取决于服务由 systemd 托管还是自己往文件里写，这一点必须先确认，不能一上来就套命令。
查看 Linux 日志没有唯一命令，判断依据是日志的落地方式：由 systemd 托管的服务优先用journalctl -u 服务名，写文件的服务用tail、less、grep组合。操作上先用ls -l /var/log和systemctl status确认日志位置，再按时间或关键字缩小范围；验证方式是命令返回内容里有时间戳和明确的单元名、进程名。边界在于：权限不足、日志被轮转、容器内日志不走宿主机 journal，都可能让命令看似“没输出”，需要结合环境确认。
Linux查看日志的命令有哪些全面详细实用案例
这一步在排查顺序里对应的是“定位日志来源”，也就是先在动手 grep 之前确认日志到底写在哪。判断方法很具体：先执行 systemctl status 服务名，看输出里有没有 Loaded: loaded (/usr/lib/systemd/system/xxx.service) 和 Main PID，如果服务由 systemd 拉起，它的标准输出通常进 journal，命令是 journalctl -u 服务名；同时可以看 /etc/systemd/system/服务名.service 里的 StandardOutput 字段，若写着 append:/var/log/xxx.log，日志就落在那个文件。
如果服务自己写文件，检查 /var/log 下的实际文件：ls -lt /var/log | head 能看到最近修改的文件和大小。常见的有 /var/log/messages（部分发行版）、/var/log/syslog（Debian 系）、/var/log/nginx/access.log 和 error.log。核对位置时不要只看文件名，还要看权限和属主，普通用户读不了 /var/log/secure 时要先确认是不是权限问题，而不是日志为空。
值得注意的还有配置文件里写的路径。比如应用配置里的 log_path、logging.file.name 这类字段，写的是相对路径时，实际位置取决于进程的工作目录，可以用 ls -l /proc/$(pgrep -f 进程名)/cwd 确认进程当前目录，再去对应位置找日志。这一步比盲目 grep -r 整个根目录高效得多。
查看日志的命令：先把能核对的事实摆清楚
先不下结论，把能直接核对的东西列出来。第一类是命令本身：tail 看尾部、less 翻页、grep 过滤、journalctl 查 systemd 日志、dmesg 看内核环形缓冲区、zcat 或 zless 读已压缩的轮转文件。第二类是日志位置：/var/log 下的常规文件、/var/log/journal 下的二进制 journal、容器里 docker logs 容器名 或 kubectl logs Pod名。第三类是面板或字段：systemctl status 输出里的 Active、journalctl 输出里的 _PID 和 _COMM 字段、tail -f 时每行开头的时间戳。
前提条件也要摆清楚：读 /var/log/secure、/var/log/audit 这类文件需要 root 或相应组权限；journalctl 普通用户默认只能看自己的日志，看系统日志通常要加 sudo 或把用户加入 systemd-journal 组；日志如果已经轮转成 .gz，直接 tail 看不到内容，要换成 zcat。
可核对的现象是：命令能返回带时间戳的行，且时间与故障发生的时间段对得上；journalctl -u 服务名 --since "10 min ago" 能返回最近十分钟的单元日志。如果返回 No entries，先别断定没有报错，要确认服务名拼写、unit 是否存在、以及 journal 是否启用了持久化存储。
查看日志的命令最容易搞错的一点
最常见的误解是把 tail -f /var/log/messages 当成万能入口。实际上 systemd 托管服务的 stdout、stderr 默认进 journal，不写 /var/log/messages；在这些机器上 tail -f 会看起来“日志不更新”，但服务其实一直在打日志，只是打在了另一个地方。反过来，有些容器或老服务确实只写文件，这时 journalctl -u 返回空，也不代表服务没输出。
能把两种情况区分开的检查动作是：先用 systemctl cat 服务名 看 unit 文件，确认是否存在以及 StandardOutput 指向哪里；再执行 ls -l /proc/$(pgrep -f 服务名)/fd/1，看进程的 fd 1 指向哪个文件或管道。如果指向 /dev/null 或 pipe:，日志大概率在 journal 里；如果指向某个 .log 文件，就回到 tail 那条路。这个动作比反复 grep 快，也能避免误判。
查看日志的命令：一个照着就能做完的做法
下面的路径可以按顺序执行，每一步都写明应该看到什么。命令里的“服务名”替换成自己的 unit 名，如 nginx、mysql。
# 第 1 步：确认服务是否存在并看状态
systemctl status nginx
# 预期：Active 行显示 active (running)，并给出 Main PID
# 第 2 步：看 unit 文件里标准输出指向哪里
systemctl cat nginx
# 预期：看到 ExecStart、StandardOutput 等字段；没有 StandardOutput 则默认走 journal
# 第 3 步：走 journal 的情况，查最近 200 行
sudo journalctl -u nginx -n 200 --no-pager
# 预期：每行开头是日期时间，末尾是日志正文
# 第 4 步：按时间段缩小
sudo journalctl -u nginx --since "20 min ago" --no-pager
# 预期：只返回最近 20 分钟的条目；空结果需核对时间范围和 unit 名
# 第 5 步：只找错误级别
sudo journalctl -u nginx -p err --since today --no-pager
# 预期：只出现 err 及以上级别条目
# 第 6 步：写文件的情况，直接看日志尾部
tail -n 200 /var/log/nginx/error.log
# 预期：每行带时间戳，按时间递增
# 第 7 步：实时观察
tail -f /var/log/nginx/error.log
# 预期：有请求进来时新行会持续追加，按 Ctrl+C 退出需要过滤关键字时，把 grep 串在后面，例如 tail -n 2000 /var/log/nginx/error.log | grep -i timeout；journal 里直接用 sudo journalctl -u nginx --since today | grep -i error。日志文件较大的场合，用 less 而不是 cat，避免一次刷屏：less /var/log/nginx/access.log，进入后按 Shift+G 跳到文件尾，输入 /关键字 向前搜索。
轮转后的文件要换命令：zcat /var/log/nginx/error.log.1.gz | tail -n 100，或者 zgrep -i error /var/log/nginx/error.log.*.gz。如果只想看某个进程最近写了什么，可以先用 lsof -p PID | grep log 查出它打开的文件，再去 tail 对应文件。
查看日志的命令：怎么验证结果对不对
验证的核心是“命令返回的日志能否和实际现象对上”。对 journal 方式，可用 sudo journalctl -u nginx --since "-5m" --no-pager | wc -l 看条目数量，如果服务正在处理请求，数量通常大于零且随时间增长；再加上一次 tail -f 观察是否有新增行，就能确认观察的是活动日志而不是历史残留。对文件方式，可用 tail -n 5 /var/log/nginx/error.log 与 stat /var/log/nginx/error.log 的 Modify 时间做比对，修改时间应当接近当前时间。
正常结果的样子是：每行都有可识别的时间戳，日志内容里能出现与故障时间段重合的记录，报错级别与 systemctl status 显示的 Active 状态变化能对应上。如果查到的只有启动日志而没有后续记录，要检查是不是 --since 时间范围写错、时区不一致，或者 journal 未启用持久化导致重启后旧日志丢失，可用 journalctl --disk-usage 和 ls /var/log/journal 确认是否存在持久化目录。这些都需要结合具体环境再判断，不能凭一次命令的输出直接下结论。