Linux如何使用journalctl查看服务日志-linux运维-PHP中文网

Linux如何使用journalctl查看服务日志

P粉602998670

发布： 2025-09-11 09:50:02

原创

910人浏览过

journalctl是Linux系统下排查服务日志的核心工具，通过-u参数可定位特定服务日志，结合-f实现实时追踪，-p按级别筛选错误信息，--since和--until支持时间段过滤，组合使用可高效定位问题；为避免日志重启后丢失，需配置/etc/systemd/journald.conf中Storage=persistent并创建/var/log/journal目录以实现持久化存储；此外，journalctl支持查看内核日志（-k）、按PID或可执行文件路径筛选、扩展错误详情（-xe）等高级功能，结合systemctl status可快速诊断系统故障，是系统运维中不可或缺的日志分析利器。

linux如何使用journalctl查看服务日志

在Linux系统上，如果你想查看服务日志，

journalctl

登录后复制

无疑是Systemd生态下最直接、最强大的工具。它能帮你快速、系统地洞察各种服务、内核乃至应用程序的运行状态和潜在问题，是排查故障不可或缺的利器。

说实话，刚接触

journalctl

登录后复制

的时候，我一度觉得它有点复杂，毕竟习惯了

tail -f /var/log/syslog

登录后复制

那种直来直去的风格。但用久了才发现，它的强大之处在于整合性和结构化，几乎所有Systemd管理下的日志都能通过它来查阅。

最基本的用法，当然就是直接敲入

journalctl

登录后复制

，它会显示所有可用的日志，从最旧的开始。但这样信息量太大，通常我们都会带上参数：

查看特定服务的日志：这是最常用的。比如你想看Nginx的日志，就用
```
journalctl -u nginx.service
```
登录后复制
。这个
```
-u
```
登录后复制
（unit）参数简直是我的救星，直接定位到问题服务，省去了大海捞针的麻烦。
实时追踪日志：就像
```
tail -f
```
登录后复制
一样，加上
```
-f
```
登录后复制
（follow）参数，
```
journalctl -f -u sshd.service
```
登录后复制
就能实时看到SSH服务的最新动态，这对调试正在运行的服务非常有用。
按级别筛选：有时候我们只关心错误或者警告，
```
journalctl -p err
```
登录后复制
就能只显示错误级别的日志。常见的级别有
```
emerg
```
登录后复制
,
```
alert
```
登录后复制
,
```
crit
```
登录后复制
,
```
err
```
登录后复制
,
```
warning
```
登录后复制
,
```
notice
```
登录后复制
,
```
info
```
登录后复制
,
```
debug
```
登录后复制
。我个人觉得
```
err
```
登录后复制
和
```
warning
```
登录后复制
是最常关注的。
查看特定启动的日志：系统重启后，之前的日志会归档。如果你想看上一次启动的日志，
```
journalctl -b -1
```
登录后复制
就搞定了（
```
-b 0
```
登录后复制
是当前启动）。这个功能在系统启动失败，需要回溯问题时特别好用。
时间段筛选：当你知道问题大概发生在什么时候，
```
--since
```
登录后复制
和
```
--until
```
登录后复制
参数就派上用场了。比如
```
journalctl --since "2 hours ago"
```
登录后复制
或者
```
journalctl --since "2023-10-26 10:00:00" --until "2023-10-26 10:30:00"
```
登录后复制
，能帮你快速缩小排查范围。

这些命令的组合使用，基本上能满足日常大部分的日志查看需求了。

如何高效地筛选和定位特定服务的日志信息？

在实际运维中，最常见的场景就是某个服务出了问题，我们需要迅速从海量日志中找出相关的线索。

journalctl

登录后复制

的强大之处就在于它提供了非常灵活的筛选机制，远不止上面提到的几个基本参数。

我平时排查问题，最头疼的就是日志太多，不知道从何看起。所以，学会组合使用筛选条件是关键。

比如，我想看Nginx服务在过去一个小时内所有的错误或警告信息：

journalctl -u nginx.service -p err -p warning --since "1 hour ago"

登录后复制

这里我用了两个

-p

登录后复制

参数，意思是同时显示错误和警告。如果问题比较模糊，我可能还会加上

--output=cat

登录后复制

来查看原始的、不带

journalctl

登录后复制

元数据的日志行，方便用

grep

登录后复制

进行二次过滤：

journalctl -u myapp.service --since "yesterday" --until "now" --output=cat | grep "database connection failed"

登录后复制

这种管道操作结合

grep

登录后复制

，能让你在

journalctl

登录后复制

的初步筛选基础上，进一步精确匹配日志内容，找出那些特定关键词。有时候，我甚至会根据PID来筛选，如果我知道是哪个进程出了问题：

journalctl _PID=12345

登录后复制

这比手动翻找要快得多，能省下不少时间。记住，越是精确的筛选条件，你就能越快地定位到问题所在。

为什么我的journalctl日志会在重启后消失？如何确保日志持久化存储？

这个问题我当初也遇到过，一度让我很困惑。系统重启后，之前的日志就没了，感觉就像白查了一样。这其实是

journald

登录后复制

的默认行为造成的。

Android编程之Bundle及Server、布局等教程 PDF版

内容：使用Bundle在Activity间传递数据、Log与DDMS(查看Log等信息)、Activity生命周期、Android应用开发4使用Service、如何使用服务、服务生命周期、进程生命周期、使用服务进行音乐播放、AndroidUI布局等……

查看详情

默认情况下，

journald

登录后复制

会将日志存储在内存文件系统（通常是

/run/log/journal

登录后复制

）中。

/run

登录后复制

目录在每次系统启动时都会被清空，所以日志自然就没了。这种设计是为了在某些特定场景下节省磁盘空间，或者在嵌入式系统上减少写入磨损。但对于服务器或者需要长期审计的系统来说，这显然是不够的。

要让

journalctl

登录后复制

的日志持久化存储，你需要确保

/var/log/journal

登录后复制

这个目录存在。

journald

登录后复制

会检测这个目录，如果它存在，就会将日志写入这里，而不是

/run/log/journal

登录后复制

。

/var/log/journal

登录后复制

是持久化存储的，即使系统重启，日志也不会丢失。

你可以手动创建这个目录，然后重启

systemd-journald

登录后复制

服务：

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal # 确保权限正确
sudo systemctl restart systemd-journald

登录后复制

或者，更推荐的方式是修改

journald

登录后复制

的配置文件。打开

/etc/systemd/journald.conf

登录后复制

，找到

[Journal]

登录后复制

部分，将

Storage

登录后复制

参数设置为

persistent

登录后复制

：

# /etc/systemd/journald.conf
[Journal]
Storage=persistent

登录后复制

保存文件后，同样需要重启

systemd-journald

登录后复制

服务：

sudo systemctl restart systemd-journald

登录后复制

这样设置后，即使你的系统经历了多次重启，历史日志也能完整地保留下来，这对于后续的问题追溯和审计工作至关重要。我个人觉得，对于任何生产环境的服务器，日志持久化都是一个必须配置项，不然出了问题，连“案发现场”都没了。

除了基本查询，journalctl还能帮我解决哪些系统故障？

journalctl

登录后复制

的强大之处远不止于查看服务日志那么简单。它实际上是Systemd统一日志管理的核心，能够收集来自内核、系统服务、应用程序、甚至用户会话的日志。这意味着，当系统出现一些深层次的问题，或者服务行为异常时，

journalctl

登录后复制

能提供更全面的视角。

我个人在排查一些比较棘手的问题时，经常会用到以下几个高级技巧：

查看内核日志：有时候系统启动失败，或者硬件出现问题，服务日志可能根本没来得及记录。这时候，
```
journalctl -k
```
登录后复制
就派上用场了。它只显示内核产生的日志信息，结合
```
-b
```
登录后复制
参数，比如
```
journalctl -k -b -1
```
登录后复制
，就能查看上一次启动的内核日志，这对于定位启动阶段的硬件或驱动问题非常有效。
扩展错误信息：当你看到一条错误日志，但信息不够详细时，可以尝试加上
```
-x
```
登录后复制
或
```
-xe
```
登录后复制
参数。比如
```
journalctl -u myapp.service -xe
```
登录后复制
。
```
journalctl
```
登录后复制
会尝试提供更多上下文信息，比如错误发生的进程、相关的Systemd单元状态，甚至可能指向相关的man page。这个功能在你不确定错误具体含义时，能提供额外的线索。
按可执行文件路径筛选：如果你的服务不是Systemd unit，或者你想查看某个特定程序的运行日志，可以通过其可执行文件的路径来筛选：
```
journalctl _EXE=/usr/bin/python3
```
登录后复制
。这在调试自定义脚本或非标准服务时非常方便。
结合
systemctl status
登录后复制
：我通常会先用
```
systemctl status <service_name>
```
登录后复制
快速查看服务状态，如果发现服务处于失败状态，再立即使用
```
journalctl -u <service_name> -xe --since "10 minutes ago"
```
登录后复制
来查看最近的详细错误日志。这种组合拳能让我迅速从宏观状态切入到微观细节。