如何在Linux中查看服务日志 Linux journalctl查询技巧-linux运维-PHP中文网

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

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

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

systemd

登录后复制

管理的服务，最核心、最强大的工具就是

journalctl

登录后复制

。它不仅仅是简单地读取日志文件，更像是一个日志数据库的查询界面，能让你以各种维度去筛选和分析海量的日志信息。

解决方案

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

systemd

登录后复制

体系下的，

journalctl

登录后复制

是你的首选工具。

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

journalctl

登录后复制

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

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

journalctl -u nginx

登录后复制

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

想要实时跟踪日志，就像

tail -f

登录后复制

一样，加上

-f

登录后复制

参数：

journalctl -u sshd -f

登录后复制

这样你就能看到

sshd

登录后复制

服务的新日志实时更新。

时间过滤是

journalctl

登录后复制

的强项。想看今天凌晨以来的日志：

journalctl -S today

登录后复制

或者从昨天开始的：

journalctl -S yesterday

登录后复制

甚至可以精确到某个时间点，比如“从下午两点开始”：

journalctl -S "2023-10-27 14:00:00"

登录后复制

如果你只关心最近5分钟的日志，可以这样：

journalctl -S "-5min"

登录后复制

结合起来，比如查看Nginx服务从昨天到现在的日志：

journalctl -u nginx -S yesterday -U now

登录后复制

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

journalctl -p err

登录后复制

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

journalctl -p warning

登录后复制

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

-b

登录后复制

参数就派上用场了。

journalctl -b

登录后复制

会显示当前启动的日志。

journalctl -b -1

登录后复制

则会显示上一次启动的日志，以此类推。

journalctl

登录后复制

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

我个人觉得，

journalctl

登录后复制

和我们过去习惯的

/var/log/messages

登录后复制

、

/var/log/syslog

登录后复制

这类文本日志最大的区别，在于它的“结构化”和“中心化”。传统日志就是纯文本文件，虽然人类阅读起来很直观，但机器解析起来就得依赖各种正则和脚本，效率和准确性都打折扣。而

journalctl

登录后复制

背后是

systemd-journald

登录后复制

服务，它把日志存储为二进制格式，并且自带了各种元数据，比如时间戳、服务单元、进程ID、用户ID等等。

这意味着什么呢？当你用

journalctl

登录后复制

查询时，它不是简单地

grep

登录后复制

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

journalctl

登录后复制

直接一个

_EXE=/usr/bin/python

登录后复制

就能搞定。

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

cat

登录后复制

或者

less

登录后复制

去查看这些二进制文件，也不能直接用

grep

登录后复制

。所有操作都必须通过

journalctl

登录后复制

这个命令来完成。但这其实是个优势，因为它把日志的管理和查询能力都封装在了工具内部，避免了我们手动解析可能出现的错误。而且，

journald

登录后复制

默认的日志存储位置，

/run/log/journal

登录后复制

，在系统重启后是会清空的，这和

/var/log

登录后复制

下的持久化日志行为不同。当然，你也可以配置让它持久化存储，这个我们后面会聊到。

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

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

journalctl

登录后复制

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

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

journalctl -u myapp.service -S "-1hour" -p err

登录后复制

这就能帮我快速锁定

myapp.service

登录后复制

在一个小时内产生的所有错误日志。

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

grep

登录后复制

来进一步筛选

journalctl

登录后复制

的输出。记住，

journalctl

登录后复制

的输出默认是文本格式，所以可以直接管道给

grep

登录后复制

：

journalctl -u nginx | grep "failed to bind"

登录后复制

这能帮我找出Nginx服务中所有包含“failed to bind”字样的日志行。

journalctl

登录后复制

自身也支持正则表达式搜索，通过

--grep

登录后复制

参数：

journalctl -u docker --grep="Error|Failed to pull"

登录后复制

这会找出Docker服务日志中包含“Error”或“Failed to pull”的行。这比管道给

grep

登录后复制

更高效，因为

journalctl

登录后复制

在内部处理了正则匹配。

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

journalctl

登录后复制

也能直接根据这些元数据来过滤：

journalctl _PID=12345

登录后复制

journalctl _UID=1000

登录后复制

甚至可以根据可执行文件的路径来过滤：

journalctl _EXE=/usr/local/bin/my_script.sh

登录后复制

这些都是传统日志工具难以直接实现的，而

journalctl

登录后复制

因为其结构化存储的优势，做起来得心应手。我发现，一旦你习惯了这些高级用法，回过头再去看纯文本日志，会觉得效率低了不少。

如何处理

journalctl

登录后复制

日志过大或持久化问题？

journalctl

登录后复制

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

journald

登录后复制

的日志是存储在内存文件系统

/run/log/journal

登录后复制

下的，这意味着系统重启后，这些日志就会丢失。

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

/etc/systemd/journald.conf

登录后复制

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

```
SystemMaxUse=
```
登录后复制
: 设置所有日志文件在磁盘上占用的最大空间。比如，
```
SystemMaxUse=1G
```
登录后复制
表示日志文件总大小不超过1GB。
```
SystemKeepFree=
```
登录后复制
: 确保在日志存储分区上保留多少空间不被日志占用。比如，
```
SystemKeepFree=100M
```
登录后复制
。
```
RuntimeMaxUse=
```
登录后复制
: 限制非持久化日志（也就是
```
/run/log/journal
```
登录后复制
登录后复制
登录后复制
下的）的最大大小。