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

答案是journalctl是Linux中查看systemd服务日志的核心工具，支持按服务、时间、日志级别等多维度过滤，具备结构化查询能力，优于传统文本日志；通过配置journald.conf可管理日志大小与持久化，创建/var/log/journal目录实现日志永久保存，结合-f、-u、-S、-p等参数及--grep可高效定位问题，是运维排查的高效手段。

在Linux系统里，查看服务日志，特别是那些由

管理的服务，最核心、最强大的工具就是。它不仅仅是简单地读取日志文件，更像是一个日志数据库的查询界面，能让你以各种维度去筛选和分析海量的日志信息。

解决方案

要查看Linux中的服务日志，特别是

体系下的，是你的首选工具。

最基础的用法，不带任何参数执行

，它会显示所有可用的系统日志，从最旧的开始。这通常会刷屏，不太实用。

如果你想看某个特定服务的日志，比如Nginx，命令是：

这会列出Nginx服务产生的所有日志。

想要实时跟踪日志，就像

一样，加上参数： 这样你就能看到服务的新日志实时更新。

时间过滤是

的强项。想看今天凌晨以来的日志： 或者从昨天开始的： 甚至可以精确到某个时间点，比如“从下午两点开始”： 如果你只关心最近5分钟的日志，可以这样： 结合起来，比如查看Nginx服务从昨天到现在的日志：

按日志级别筛选也很有用。比如，只看错误日志：

或者只看警告及更高级别的日志：

查看特定启动会话的日志，

参数就派上用场了。会显示当前启动的日志。则会显示上一次启动的日志，以此类推。

journalctl

登录后复制

和传统日志文件有什么不同？

我个人觉得，

和我们过去习惯的、这类文本日志最大的区别，在于它的“结构化”和“中心化”。传统日志就是纯文本文件，虽然人类阅读起来很直观，但机器解析起来就得依赖各种正则和脚本，效率和准确性都打折扣。而背后是服务，它把日志存储为二进制格式，并且自带了各种元数据，比如时间戳、服务单元、进程ID、用户ID等等。

这意味着什么呢？当你用

查询时，它不是简单地一个文本文件，而是像查询数据库一样，能够高效地根据这些元数据进行过滤和排序。比如，我想看所有与某个特定可执行文件相关的日志，传统方式可能要遍历所有日志文件并猜测，但直接一个就能搞定。

当然，这种二进制存储也有它的“缺点”，或者说是我刚开始接触时觉得不适应的地方：你不能直接用

或者去查看这些二进制文件，也不能直接用。所有操作都必须通过这个命令来完成。但这其实是个优势，因为它把日志的管理和查询能力都封装在了工具内部，避免了我们手动解析可能出现的错误。而且，默认的日志存储位置，，在系统重启后是会清空的，这和下的持久化日志行为不同。当然，你也可以配置让它持久化存储，这个我们后面会聊到。

查找特定错误或事件日志的实用技巧

在日常运维中，我们最常做的就是定位问题，而日志就是我们排查问题的“线索”。

在这方面提供了很多高阶的查询技巧，能大大提高效率。

比如说，我经常需要查看某个服务最近有没有报错。结合之前提到的时间过滤和级别过滤，我可以直接：

这就能帮我快速锁定在一个小时内产生的所有错误日志。

有时候，错误信息可能不是以标准的“error”级别记录的，或者我只是想找一些关键词。这时，我们可以结合

来进一步筛选的输出。记住，的输出默认是文本格式，所以可以直接管道给： 这能帮我找出Nginx服务中所有包含“failed to bind”字样的日志行。

自身也支持正则表达式搜索，通过参数： 这会找出Docker服务日志中包含“Error”或“Failed to pull”的行。这比管道给更高效，因为在内部处理了正则匹配。

当你知道某个错误是由特定进程ID（PID）产生的，或者想追踪某个特定用户的行为时，

也能直接根据这些元数据来过滤： 甚至可以根据可执行文件的路径来过滤： 这些都是传统日志工具难以直接实现的，而因为其结构化存储的优势，做起来得心应手。我发现，一旦你习惯了这些高级用法，回过头再去看纯文本日志，会觉得效率低了不少。

如何处理

journalctl

登录后复制

日志过大或持久化问题？

的日志文件，特别是如果你的系统运行了很长时间，或者有很多服务在不断输出日志，可能会变得非常庞大，占用大量磁盘空间。同时，前面也提到了，默认情况下的日志是存储在内存文件系统下的，这意味着系统重启后，这些日志就会丢失。

对于日志过大的问题，我们可以在

这个配置文件里进行管理。几个关键的配置项：

• SystemMaxUse=

  登录后复制
  : 设置所有日志文件在磁盘上占用的最大空间。比如，

  SystemMaxUse=1G

  登录后复制
  表示日志文件总大小不超过1GB。

• SystemKeepFree=

  登录后复制
  : 确保在日志存储分区上保留多少空间不被日志占用。比如，

  SystemKeepFree=100M

  登录后复制
  。

• RuntimeMaxUse=

  登录后复制
  : 限制非持久化日志（也就是

  /run/log/journal

  登录后复制
  下的）的最大大小。

修改这些配置后，你需要重启

服务来让它们生效：

如果你想手动清理旧日志，

也提供了方便的命令：

• 按大小清理：

  journalctl --vacuum-size=500M

  登录后复制
  会将日志大小清理到500MB以下。
• 按时间清理：

  journalctl --vacuum-time=7d

  登录后复制
  会删除7天以前的日志。 这些命令在日志文件膨胀得厉害时非常有用。

至于日志持久化，这是很多运维人员初次接触

时会遇到的“坑”。默认情况下，的日志是非持久化的，重启就没了。要让日志持久化存储，你只需要创建一个目录： 服务检测到这个目录存在后，就会自动将日志存储到下，并且在系统重启后保持不变。我个人经验是，对于任何生产服务器，这都是一个必须做的配置，否则一旦系统崩溃或重启，你将失去宝贵的故障排查线索。

处理好日志大小和持久化，

才能真正成为你可靠的日志管理伙伴。它确实改变了我查看和分析系统日志的方式，虽然刚开始有点学习曲线，但投入是绝对值得的。

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