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

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

是现代Linux系统，特别是那些采用systemd作为初始化系统的发行版中，查看系统日志的核心工具。它能让你以结构化的方式访问和过滤各种系统服务、内核、应用日志，远比直接翻阅散落在下的文本文件高效且功能强大。简单来说，如果你在Linux上遇到任何问题，第一步往往就是用它来“翻看”系统到底说了什么。

解决方案

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

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

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

。这会显示所有可用的日志条目，默认按时间倒序排列，最新的在底部。它会使用分页器，你可以用上下箭头滚动，/翻页，按退出。

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

一样，可以加上（follow）参数： 这个命令在排查即时问题时非常有用，比如服务启动失败或应用崩溃的瞬间。

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

可以显示当前启动会话的所有日志。如果你想看上一次启动的日志，可以用，则是再上一次，以此类推。这对于诊断启动时遇到的问题简直是神器。

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

是常用手段。例如，要查看SSH服务的日志： 这里的后缀通常可以省略，会智能识别。

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

和参数就派上用场了。它们接受多种时间格式，比如绝对时间、相对时间： 或者更人性化的：

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

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

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

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

）、按时间（/）和按优先级（）过滤，还支持一些更深层次的字段过滤，这在我看来，是它区别于传统日志工具的强大之处。

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

（进程ID）、（可执行文件路径）、（命令名）、（用户ID）等等。

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

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

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

服务产生的、优先级为或更高的日志： 这种组合查询能迅速缩小排查范围，直接命中问题核心。

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

来进一步筛选。虽然本身在模式下支持进行搜索，但如果你想直接在命令行管道中进行文本匹配，仍然是你的老朋友： 不过，要注意的是，会作用于输出的纯文本，可能会丢失一些结构化信息。对于更复杂的文本模式匹配，依然是不可替代的。

我个人在使用时，会先用

和大致框定范围，然后根据日志内容中的线索，再加入或进行更精确的定位。这个过程就像侦探破案，一步步缩小嫌疑范围。

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

的输出格式不仅仅是默认的文本模式，它提供了多种选项，这在自动化处理或与其他工具集成时显得尤为重要。通过（output）参数，我们可以指定不同的输出格式。

• journalctl -o short

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

• journalctl -o verbose

  登录后复制
  ：提供更详细的元数据，包括所有内部

  journald

  登录后复制
  字段，对于深入分析很有帮助。

• journalctl -o json

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

• journalctl -o json-pretty

  登录后复制
  ：输出格式化的JSON，更易读。

• journalctl -o cat

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

  cat

  登录后复制
  一个日志文件一样。

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

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

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

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

要让

的日志持久化，你需要确保目录存在。通常，你只需要手动创建这个目录： 系统下次启动时，会自动检测到这个目录，并将日志存储到这里，从而实现日志的持久化。

你还可以通过编辑

文件来进一步配置的行为。其中一些关键参数包括：

• Storage=

  登录后复制
  ：可以设置为

  volatile

  登录后复制
  （临时，默认）、

  persistent

  登录后复制
  （持久化）、

  auto

  登录后复制
  （如果

  /var/log/journal

  登录后复制
  存在则持久化，否则临时）或

  none

  登录后复制
  （不存储日志）。

• SystemMaxUse=

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

• RuntimeMaxUse=

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

• MaxLevelStore=

  登录后复制
  ：设置存储的最高日志级别。

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

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

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

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

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

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

）和优先级（）来快速定位启动问题。如果你的系统无法正常启动，或者某个服务在启动过程中失败了，能让你快速看到当前启动会话中所有的错误信息。如果当前启动失败，那么则能让你回顾上一次成功启动或失败启动的错误，这对于对比分析非常关键。

另一个高级用法是利用

的字段过滤来追踪特定进程的行为。比如，一个应用偶尔会崩溃，但你不知道是哪个子进程出了问题。你可以先找到主进程的PID，然后用或者来查看所有与该应用相关的日志。如果应用会生成多个进程，可以让你看到所有工作进程的日志，而不仅仅是主进程。这在微服务架构中，对于追踪特定服务实例的行为尤为有效。

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

看一眼，然后立刻。如果日志中没有明确的错误，我会尝试扩大范围，查看系统启动初期的通用错误，甚至查看内核日志：。内核日志（通过参数获取）能揭示驱动问题、硬件故障等底层错误，这些往往是应用层日志无法提供的。

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

的精确时间过滤。例如，如果系统每天凌晨3点会卡顿，我会设置来查看那个时间窗口内所有系统事件。然后，我会结合来搜索CPU、内存、磁盘相关的关键词，看看是否有异常的进程活动。

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

的日志时间戳是相对可靠的。因为在记录日志时，会同时记录一个单调递增的时间戳（Monotonic Timestamp），这个时间戳不受系统时钟调整的影响。虽然默认显示的是系统时间，但知道这个底层机制能帮助你在时间混乱时更好地理解日志。这其实是一个小细节，但关键时刻能提供额外的诊断依据。

以上就是如何在Linux中查看日志 Linux journalctl查询技巧的详细内容，更多请关注php中文网其它相关文章！