如何在Linux中查看日志 Linux journalctl查询技巧

journalctl是systemd系统中查看日志的核心工具，支持按服务、时间、优先级等多维度过滤，结合-f、-u、--since、-p等参数可高效定位问题，通过创建/var/log/journal实现日志持久化，并可用-o指定输出格式，适用于从基础排查到高级诊断的各类场景。

journalctl

是现代Linux系统，特别是那些采用systemd作为初始化系统的发行版中，查看系统日志的核心工具。它能让你以结构化的方式访问和过滤各种系统服务、内核、应用日志，远比直接翻阅散落在

/var/log

下的文本文件高效且功能强大。简单来说，如果你在Linux上遇到任何问题，第一步往往就是用它来“翻看”系统到底说了什么。

解决方案

要查看Linux中的日志，尤其是通过

journalctl

，我们通常从几个基础命令开始，然后根据需求进行精细化筛选。

首先，最基础的命令就是直接输入

journalctl

。这会显示所有可用的日志条目，默认按时间倒序排列，最新的在底部。它会使用

less

分页器，你可以用上下箭头滚动，

Page Up

/

Page Down

翻页，按

q

退出。

如果你想实时跟踪日志，就像传统的

tail -f

一样，可以加上

-f

（follow）参数：

journalctl -f

这个命令在排查即时问题时非常有用，比如服务启动失败或应用崩溃的瞬间。

有时候，我们只关心当前启动会话的日志，或者前一个启动会话的日志。

journalctl -b

可以显示当前启动会话的所有日志。如果你想看上一次启动的日志，可以用

journalctl -b -1

，

-2

则是再上一次，以此类推。这对于诊断启动时遇到的问题简直是神器。

针对特定服务或单元的日志，

journalctl -u 

是常用手段。例如，要查看SSH服务的日志：

journalctl -u sshd.service

这里的

.service

后缀通常可以省略，

journalctl

会智能识别。

如果你想查看特定时间段的日志，

--since

和

--until

参数就派上用场了。它们接受多种时间格式，比如绝对时间、相对时间：

journalctl --since "2023-10-26 10:00:00" --until "2023-10-26 11:00:00"

或者更人性化的：

journalctl --since "yesterday"

journalctl --since "1 hour ago"

当然，日志的优先级也很重要。

journalctl -p 

可以根据日志级别进行过滤，从0（emerg）到7（debug）。比如，只看错误和更高级别的日志：

journalctl -p err

这会显示

err

、

crit

、

alert

和

emerg

级别的日志。

如何有效地过滤和定位特定日志条目？

在日志海洋中找到你真正需要的信息，这本身就是一门艺术。仅仅是查看全部日志显然不够，我们需要更精细的过滤手段。除了之前提到的按服务（

-u

）、按时间（

--since

/

--until

）和按优先级（

-p

）过滤，

journalctl

还支持一些更深层次的字段过滤，这在我看来，是它区别于传统日志工具的强大之处。

你可以通过特定的字段来过滤，这些字段通常以一个下划线开头，比如

_PID

（进程ID）、

_EXE

（可执行文件路径）、

_COMM

（命令名）、

_UID

（用户ID）等等。

举个例子，如果你知道某个进程的PID是1234，想看它产生的所有日志：

journalctl _PID=1234

或者，你怀疑某个特定的可执行文件有问题，想看它所有的输出：

journalctl _EXE=/usr/bin/nginx

这些字段过滤可以叠加使用，形成非常强大的组合查询。比如，查看过去一个小时内，由

sshd

服务产生的、优先级为

err

或更高的日志：

journalctl -u sshd --since "1 hour ago" -p err

这种组合查询能迅速缩小排查范围，直接命中问题核心。

有时候，日志中会有一些特定的关键词，你可能想用

grep

来进一步筛选。虽然

journalctl

本身在

less

模式下支持

/

进行搜索，但如果你想直接在命令行管道中进行文本匹配，

grep

仍然是你的老朋友：

journalctl -u apache2.service | grep "Permission denied"

不过，要注意的是，

grep

会作用于

journalctl

输出的纯文本，可能会丢失一些结构化信息。对于更复杂的文本模式匹配，

grep

依然是不可替代的。

我个人在使用时，会先用

-u

和

--since

大致框定范围，然后根据日志内容中的线索，再加入

_PID

或

_EXE

进行更精确的定位。这个过程就像侦探破案，一步步缩小嫌疑范围。

深入理解journalctl的输出格式与持久化配置

journalctl

的输出格式不仅仅是默认的文本模式，它提供了多种选项，这在自动化处理或与其他工具集成时显得尤为重要。通过

-o

（output）参数，我们可以指定不同的输出格式。

• journalctl -o short

  ：这是默认的简洁格式，包含时间戳、主机名、进程名和日志消息。

• journalctl -o verbose

  ：提供更详细的元数据，包括所有内部

  journald

  字段，对于深入分析很有帮助。

• journalctl -o json

  ：以JSON格式输出日志条目，每个条目一行。这对于编程解析日志数据非常方便。

• journalctl -o json-pretty

  ：输出格式化的JSON，更易读。

• journalctl -o cat

  ：只输出原始的日志消息，不带任何元数据，就像直接

  cat

  一个日志文件一样。

选择合适的输出格式，能大大提高你处理日志的效率。比如，我写脚本分析日志时，几乎都会用

json

格式，因为它结构化，易于解析。

再来说说日志的持久化配置。默认情况下，

journald

会将日志存储在

/run/log/journal

目录下。这个目录是临时的，意味着系统重启后，这些日志就会丢失。这对于一些生产环境来说是不可接受的，因为你可能需要分析上次重启前发生了什么。

要让

journald

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

/var/log/journal

目录存在。通常，你只需要手动创建这个目录：

sudo mkdir -p /var/log/journal

系统下次启动时，

journald

会自动检测到这个目录，并将日志存储到这里，从而实现日志的持久化。

你还可以通过编辑

/etc/systemd/journald.conf

文件来进一步配置

journald

的行为。其中一些关键参数包括：

• Storage=

  ：可以设置为

  volatile

  （临时，默认）、

  persistent

  （持久化）、

  auto

  （如果

  /var/log/journal

  存在则持久化，否则临时）或

  none

  （不存储日志）。

• SystemMaxUse=

  ：限制所有持久化日志文件占用的最大磁盘空间。

• RuntimeMaxUse=

  ：限制所有临时日志文件占用的最大磁盘空间。

• MaxLevelStore=

  ：设置存储的最高日志级别。

在我看来，为生产系统配置持久化日志是运维的基本要求。但同时，也要注意

SystemMaxUse

等参数的设置，避免日志文件无限增长，最终撑爆磁盘。这是一个需要权衡的细节，但通常默认值已经比较合理了。

诊断系统问题时，journalctl有哪些高级应用技巧？

当系统出现问题，尤其是一些棘手的、间歇性的故障时，

journalctl

的“高级应用”就不再是花哨的功能，而是实实在在的诊断利器。它能帮助我们从纷繁复杂的日志中，抽丝剥茧，找到问题的根源。

一个非常实用的技巧是结合启动会话（

-b

）和优先级（

-p

）来快速定位启动问题。如果你的系统无法正常启动，或者某个服务在启动过程中失败了，

journalctl -b 0 -p err

能让你快速看到当前启动会话中所有的错误信息。如果当前启动失败，那么

journalctl -b -1 -p err

则能让你回顾上一次成功启动或失败启动的错误，这对于对比分析非常关键。

另一个高级用法是利用

journalctl

的字段过滤来追踪特定进程的行为。比如，一个应用偶尔会崩溃，但你不知道是哪个子进程出了问题。你可以先找到主进程的PID，然后用

journalctl _COMM=你的应用名

或者

journalctl _EXE=/path/to/your/app

来查看所有与该应用相关的日志。如果应用会生成多个进程，

journalctl _COMM=nginx

可以让你看到所有

nginx

工作进程的日志，而不仅仅是主进程。这在微服务架构中，对于追踪特定服务实例的行为尤为有效。

在排查服务启动失败的问题时，我发现直接查看该服务的日志往往不够。有时候，一个服务的失败是由于其依赖的其他服务没有正常启动，或者系统资源不足。这时，我会先用

systemctl status 

看一眼，然后立刻

journalctl -u  --since "boot"

。如果日志中没有明确的错误，我会尝试扩大范围，查看系统启动初期的通用错误，甚至查看内核日志：

journalctl -k -p err --since "boot"

。内核日志（通过

-k

参数获取）能揭示驱动问题、硬件故障等底层错误，这些往往是应用层日志无法提供的。

此外，对于那些在特定时间点出现问题的系统，我喜欢利用

journalctl

的精确时间过滤。例如，如果系统每天凌晨3点会卡顿，我会设置

--since "YYYY-MM-DD 02:50:00" --until "YYYY-MM-DD 03:10:00"

来查看那个时间窗口内所有系统事件。然后，我会结合

grep

来搜索CPU、内存、磁盘相关的关键词，看看是否有异常的进程活动。

最后，一个相对不那么常用但很有用的场景是，当你的系统时间被篡改或同步出现问题时，

journalctl

的日志时间戳是相对可靠的。因为

journald

在记录日志时，会同时记录一个单调递增的时间戳（Monotonic Timestamp），这个时间戳不受系统时钟调整的影响。虽然

journalctl

默认显示的是系统时间，但知道这个底层机制能帮助你在时间混乱时更好地理解日志。这其实是一个小细节，但关键时刻能提供额外的诊断依据。