journalctl是Linux系统下排查服务日志的核心工具，通过-u参数可定位特定服务日志，结合-f实现实时追踪，-p按级别筛选错误信息，–since和–until支持时间段过滤，组合使用可高效定位问题；为避免日志重启后丢失，需配置/etc/systemd/journald.conf中Storage=persistent并创建/var/log/journal目录以实现持久化存储；此外，journalctl支持查看内核日志（-k）、按PID或可执行文件路径筛选、扩展错误详情（-xe）等高级功能，结合systemctl status可快速诊断系统故障，是系统运维中不可或缺的日志分析利器。
在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
的默认行为造成的。
默认情况下，
journald
会将日志存储在内存文件系统（通常是
/run/log/journal
）中。
/run
目录在每次系统启动时都会被清空，所以日志自然就没了。这种设计是为了在某些特定场景下节省磁盘空间，或者在嵌入式系统上减少写入磨损。但对于服务器或者需要长期审计的系统来说，这显然是不够的。
要让
journalctl
的日志持久化存储，你需要确保
/var/log/journal
这个目录存在。
journald
会检测这个目录，如果它存在，就会将日志写入这里，而不是
/run/log/journal
。
/var/log/journal
是持久化存储的，即使系统重启，日志也不会丢失。
你可以手动创建这个目录，然后重启
systemd-journald
服务：
sudo mkdir -p /var/log/journalsudo 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
快速查看服务状态，如果发现服务处于失败状态，再立即使用
journalctl -u -xe --since "10 minutes ago"
来查看最近的详细错误日志。这种组合拳能让我迅速从宏观状态切入到微观细节。
journalctl
的字段过滤能力也非常强大，你可以通过
_SYSTEMD_UNIT
、
_COMM
（命令名）、
_PID
、
_UID
等各种字段来精确筛选。要查看所有可用的字段，可以运行
journalctl -F
。掌握这些高级用法，能让你在面对各种复杂的系统故障时，拥有更强的日志分析和问题定位能力。它不仅仅是一个日志查看器，更是一个强大的故障诊断平台。
以上就是Linux如何使用journalctl查看服务日志的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/203584.html
微信扫一扫 
支付宝扫一扫 
