Linux查看系统日志的常用命令

P粉602998670

发布时间：2025-09-08 08:29:01

419人浏览过

来源于php中文网

原创

答案是查看Linux日志需综合使用journalctl、dmesg、tail、grep等工具。journalctl用于systemd系统集中查询服务及内核日志，支持时间、优先级、字段等多维度过滤；dmesg专注内核启动与硬件问题；tail -f实时监控日志动态；cat、grep、less结合正则和管道可精准提取关键信息。因日志来源分散（如auth.log、kern.log、应用日志），且问题常涉及多层面，必须多文件联动分析。通过高级过滤、格式控制与文本处理工具组合，可高效定位问题，实现对海量日志的快速搜索与结构化分析。

linux查看系统日志的常用命令

在Linux的世界里，想要了解系统发生了什么，日志就是那本最真实的日记。对我来说，查看系统日志的常用命令主要集中在

journalctl

、

dmesg

，以及传统的

tail

、

cat

配合

grep

等文本处理工具。这些命令各有侧重，理解它们的用途能帮助我们快速定位问题，或者只是单纯地窥探系统的心跳。

说起日志，我个人觉得，现代Linux系统，尤其是采用systemd的发行版，

journalctl

绝对是首选。它不仅仅是查看日志，更像是一个强大的日志管理中心。你可以用它来查看所有服务、内核甚至用户程序的日志，而且支持非常灵活的过滤。比如，想看某个特定服务的日志？

journalctl -u nginx.service

就搞定了。想看最近10分钟的日志？

journalctl -since "10 min ago"

。这种按需查询的能力，在排查问题时简直是神器。

当然，

dmesg

这个老伙计也从没掉线。它专门负责打印内核环缓冲区（kernel ring buffer）的消息，主要记录了系统启动时的硬件检测、驱动加载、内核错误等信息。如果你遇到启动问题、硬件识别异常或者驱动崩溃，

dmesg

几乎是你的第一站。它输出的信息通常比较底层，但却是诊断硬件和内核问题的金钥匙。

而

tail -f

则是实时监控的利器。当你在部署服务、调试脚本或者观察系统行为时，用

tail -f /var/log/syslog

或者

tail -f /var/log/nginx/access.log

就能看到日志的实时更新，就像在看一场系统直播。这对于快速发现问题、验证配置更改效果，简直是不可或缺。

至于

cat

和

grep

的组合，那是处理任何文本文件的万金油。虽然

journalctl

强大，但有时候我们仍然需要直接查看

/var/log

下的传统日志文件，比如

auth.log

、

kern.log

等。

cat /var/log/auth.log | grep "Failed password"

这样的命令，能让你在海量的认证日志中迅速揪出那些失败的登录尝试。而

less

或

more

则是在文件内容过长时，分屏查看的优雅选择，它们自带的搜索功能（

和

）也非常好用。

为什么我们不能只盯着一个日志文件看？

这问题问得好，因为Linux系统的日志体系远比我们想象的要复杂和分散。在我看来，这就像医生诊断病人，不能只看一个指标就下结论。我们不能只盯着一个日志文件看，主要有几个原因：

首先，日志的来源和类型多样化。 传统的syslog服务，会将不同类别的日志（如认证信息、内核信息、邮件信息等）写入不同的文件，比如

/var/log/auth.log

、

/var/log/kern.log

、

/var/log/maillog

。此外，很多应用程序和服务（如Nginx、Apache、MySQL）都有自己的日志文件，通常放在

/var/log

下以其服务名命名的子目录中。这些日志记录着特定应用的行为，与系统层面的日志是互补的。

其次，现代Linux系统引入了

systemd-journald

。

journald

统一管理了所有系统服务的日志，包括内核、initrd、systemd服务、甚至syslogd收集的日志。它将这些日志以二进制格式存储，并通过

journalctl

命令提供强大的查询和过滤功能。这意味着，你可能在

/var/log/syslog

里看到的信息，也能通过

journalctl

查到，但

journalctl

能提供更丰富、更集中的视图。

再者，问题往往是多层面的。 一个系统故障，可能既涉及到内核层面（

dmesg

），又涉及到某个服务（

journalctl -u service

），还可能涉及到用户认证（

/var/log/auth.log

）。如果只看一个日志文件，很可能会错过关键信息，导致诊断陷入僵局。我经常遇到的情况是，一个网络服务不通，排查时需要看Nginx的access/error日志，同时也要看系统防火墙的日志，甚至需要

dmesg

确认网卡驱动有没有异常。所以，多角度、多文件地审视日志，是高效排错的必备技能。

journalctl

的高级用法有哪些，能帮我快速定位问题吗？

当然能！

journalctl

远不止

journalctl -u service

那么简单，它的高级用法简直是定位问题的瑞士军刀。

按时间过滤： 这是我最常用的功能之一。
- ```
journalctl --since "2023-01-01 10:00:00" --until "2023-01-01 11:00:00"
```
  ：查看特定时间段的日志。
- ```
journalctl --since "yesterday"
```
  ：查看昨天的日志。
- ```
journalctl --since "1 hour ago"
```
  ：查看过去一小时的日志。
- ```
journalctl -S "09:00" -U "10:00"
```
  ：查看今天9点到10点之间的日志。这种精确的时间定位，能极大地缩小排查范围。
按优先级过滤： 日志有不同的优先级（从 debug 到 emerg）。

尘月网络企业网站管理系统2010
本版升级功能：1、增加“系统参数设置”功能，可在线管理编辑全站数据库路径、备份路径，无须到程序代码下更改；2、改进后台管理员权限分配问题，严谨、完善、安全的根限分配细分到每个功能页面的列表查看权限、添加权限、编辑权限、删除权限都可以在线分配，确保系统在多用户管理下，安全稳定运行；3、更新优化数据库操作，在线备份、压缩、恢复数据库，管理登录日志；4、增加&am

下载
- ```
journalctl -p err
```
  ：只显示错误（error）级别的日志。
- ```
journalctl -p warning
```
  ：显示警告及更高级别的日志。
- 优先级从0（emerg）到7（debug），数字越小越严重。这个功能在系统正常运行时，帮你快速找出异常信息，忽略那些无关紧要的调试信息。
按特定字段过滤：
```
journalctl
```
允许你根据各种字段进行过滤，比如进程ID（
```
_PID
```
）、用户ID（
```
_UID
```
）、可执行文件路径（
```
_EXE
```
）等。
- ```
journalctl _PID=1234
```
  ：查看特定进程的日志。
- ```
journalctl _COMM=sshd
```
  ：查看特定命令的日志。这在追踪某个特定进程或用户活动时非常有效。
查看内核日志：
- ```
journalctl -k
```
  ：等同于
```
dmesg
```
  的输出，但会包含在
```
journald
```
  中持久化的内核日志。
- ```
journalctl -b
```
  ：显示当前启动会话的日志。
- ```
journalctl -b -1
```
  ：显示上一次启动会话的日志。这在系统崩溃后重启，需要查看上次启动发生了什么时，特别有用。
输出格式控制：
- ```
journalctl -o json
```
  ：以JSON格式输出日志，方便程序处理。
- ```
journalctl -o short-iso
```
  ：以ISO 8601格式输出时间，更易读。
- ```
journalctl -o verbose
```
  ：显示所有字段，提供最详细的信息。

通过这些高级用法，我常常能迅速从海量日志中抽丝剥茧，找到问题的症结所在。这比漫无目的地

grep

整个日志文件要高效得多。

面对海量日志，如何高效地进行搜索和分析？

处理海量日志，光靠几个命令的简单使用是远远不够的，需要一套策略和组合拳。在我多年的经验里，这就像大海捞针，但有了对的工具和方法，效率会指数级提升。

善用管道符和文本处理工具： 这是Linux的精髓。
- ```
cat /var/log/syslog | grep "error" | less
```
  ：先过滤出错误信息，再用
```
less
```
  分页查看。
- ```
journalctl -u nginx.service --since "1 hour ago" | grep "404" | awk '{print $10}' | sort | uniq -c | sort -nr
```
  ：这个命令链条就比较复杂了。它会找出过去一小时内Nginx服务日志中的所有404错误，提取出请求的URL，然后统计每个URL出现的次数，并按次数倒序排列。这能帮你快速发现哪些资源不存在或者被频繁访问。
- ```
sed
```
  和
```
awk
```
  在日志分析中也扮演着重要角色，它们能对日志内容进行复杂的模式匹配、提取和格式化，比如提取IP地址、请求路径等。
理解日志格式： 不同服务和应用的日志格式差异很大。Nginx的访问日志、Apache的错误日志、数据库的慢查询日志，它们的信息结构都不一样。在进行搜索和分析之前，花点时间了解目标日志的格式，知道每个字段代表什么，能让你编写出更精确的
```
grep
```
正则表达式或
```
awk
```
脚本。这虽然有点枯燥，但却是高效分析的基础。
正则表达式的力量：
```
grep
```
结合正则表达式，能让你在日志中进行极其精细的匹配。
- ```
grep -E "IP_ADDRESS|ANOTHER_IP" /var/log/auth.log
```
  ：同时搜索多个IP地址。
- ```
grep -P '(?<=Failed password for ).*?(?= from)' /var/log/auth.log
```
  ：使用Perl兼容正则表达式（PCRE）来提取“Failed password for ”和“ from”之间的用户名。掌握一些基本的正则表达式语法，会让你在日志搜索中如虎添翼。
利用
```
less
```
的交互式搜索： 当你用
```
less
```
打开一个大日志文件时，可以直接输入
```
/
```
后跟搜索词来向下搜索，输入
```
?
```
后跟搜索词来向上搜索。按下
```
n
```
键会跳转到下一个匹配项，
```
n
```
键则跳转到上一个。这对于快速浏览和定位文件中的特定事件非常方便，避免了反复执行
```
grep
```
的麻烦。
日志轮转（Logrotate）和持久化： 虽然这不是直接的搜索分析命令，但理解日志轮转机制（通常由
```
logrotate
```
管理）对于高效分析至关重要。日志文件不会无限增长，它们会被定期压缩、归档或删除。知道日志在哪里，以及历史日志的存储方式，可以帮助你追溯更久远的问题。而
```
journalctl
```
的持久化配置（
```
/etc/systemd/journald.conf
```
中的
```
Storage
```
选项）则决定了
```
journald
```
的日志是否在重启后依然存在。