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的默认行为造成的。
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
快速查看服务状态，如果发现服务处于失败状态，再立即使用journalctl -u
来查看最近的详细错误日志。这种组合拳能让我迅速从宏观状态切入到微观细节。-xe --since "10 minutes ago"
journalctl的字段过滤能力也非常强大，你可以通过
_SYSTEMD_UNIT、
_COMM（命令名）、
_PID、
_UID等各种字段来精确筛选。要查看所有可用的字段，可以运行
journalctl -F。掌握这些高级用法，能让你在面对各种复杂的系统故障时，拥有更强的日志分析和问题定位能力。它不仅仅是一个日志查看器，更是一个强大的故障诊断平台。
