查看linux服务日志的核心工具是journalctl。1.使用journalctl -u [服务单元名称]查看特定服务日志，例如journalctl -u nginx.service；2.添加-f参数实时跟踪日志，如journalctl -u docker.service -f；3.通过--since和--until指定时间范围，如journalctl -u sshd.service --since "yesterday"；4.使用-p过滤日志级别，如journalctl -u myapp.service -p err查看错误日志；5.结合-e跳转到日志末尾快速定位启动失败原因；6.利用grep搜索关键词进一步筛选问题线索；7.配置/etc/systemd/journald.conf实现日志持久化存储，设置storage=persistent；8.通过systemmaxuse、systemkeepfree等参数管理日志占用的磁盘空间；9.必要时可手动清理日志，如按大小清理sudo journalctl --vacuum-size=100m或按时间清理sudo journalctl --vacuum-time=7d。
在Linux系统中，查看服务日志的核心工具是 journalctl。它是一个非常强大的命令行实用程序，用于查询和显示由 systemd 日志守护进程（systemd-journald）收集的日志信息。基本上，如果你在找某个服务出了什么问题，或者想了解它的运行状态，journalctl 就是你第一时间应该想到的。它能帮你从海量的系统事件中，精准地捞出你想要的那部分。
要查看Linux服务日志，journalctl 是你的首选。
最基本的用法是直接运行 journalctl，它会显示所有可用的日志，通常是从最旧的开始。但这样信息量太大，我们通常需要更精确的过滤。
比如，要查看特定服务的日志，你需要知道它的 systemd 单元名称。这个名称通常和服务的可执行文件或者配置文件名类似，比如 nginx.service、docker.service 或者 php-fpm.service。
查看特定服务的日志：
journalctl -u [服务单元名称]
例如：journalctl -u nginx.service
如果你想实时跟踪某个服务的日志，就像 tail -f 那样，可以加上 -f 参数：
journalctl -u [服务单元名称] -f
例如：journalctl -u docker.service -f
有时候，我们只关心最近的日志，或者某个时间段的日志。journalctl 提供了 --since 和 --until 参数来指定时间范围。
查看从昨天开始的 sshd 服务日志：
journalctl -u sshd.service --since "yesterday"
查看特定日期时间范围内的日志：
journalctl -u apache2.service --since "2023-01-01 10:00:00" --until "2023-01-01 11:00:00"
你也可以用更口语化的表达，比如 today、yesterday、now，或者相对时间如 -5min (5分钟前)、-1h (1小时前)。
此外，日志是有优先级的，从 emerg (紧急) 到 debug (调试)。如果你只想看错误或警告，可以用 -p 参数：
journalctl -u myapp.service -p err (只看错误日志)
journalctl -u myapp.service -p warning (看警告及更高级别的日志)
这些只是 journalctl 的冰山一角，但对于日常的服务日志查看和初步问题排查，它们已经足够强大了。掌握好这些基础命令，能省下你不少时间。
查看特定服务的历史日志，这几乎是日常运维中最常用的一个场景了。你可能刚接手一个服务，或者某个老服务突然出了问题，想看看它过去一段时间的运行状况。journalctl 在这方面做得非常出色，因为它把所有日志都集中管理起来了，不像以前散落在各个 /var/log 目录下，找起来特别费劲。
要查看特定服务的历史日志，核心还是那个 -u 参数，它用来指定你感兴趣的服务单元。比如，你想看 mysql.service 的历史日志，最直接的就是：
journalctl -u mysql.service
默认情况下，这会显示 mysql.service 从系统启动以来，或者日志文件存在以来的所有日志。这可能非常多，所以我们通常会结合时间过滤器来缩小范围。
比如说，我想看看 mysql.service 在上周五下午2点到3点之间发生了什么：
journalctl -u mysql.service --since "last Friday 14:00" --until "last Friday 15:00"
这里的 --since 和 --until 参数非常灵活，你可以用各种自然语言描述的时间，比如 yesterday (昨天), today (今天), last week (上周), 1 hour ago (1小时前), 或者具体的日期时间 YYYY-MM-DD HH:MM:SS。
有时候，你可能只记得大概是哪个启动周期出了问题。journalctl 可以通过 _BOOT_ID 来过滤特定启动周期的日志。你可以先用 journalctl --list-boots 查看所有启动记录和对应的ID，然后用 journalctl -b [boot_id] 来查看某个启动周期的日志。结合服务单元，就是：
journalctl -u nginx.service -b 0 (查看当前启动周期的nginx日志)
journalctl -u nginx.service -b -1 (查看上一个启动周期的nginx日志)
甚至，如果你怀疑是某个进程ID (PID) 导致的异常，你也可以用 _PID 来过滤：
journalctl _PID=12345
虽然这不直接是服务历史日志，但当你知道某个服务在某个时间点启动了一个特定的进程，而这个进程又出了问题时，这个技巧就很有用了。通常，你会先用 -u 锁定服务，再通过日志内容找到可疑的PID，然后用 _PID 进行更细致的追踪。
说真的，journalctl 最大的优点之一就是它能让你以多种维度去“切片”日志数据。了解这些过滤参数，就能让你在海量日志中迅速找到那根针。
服务启动失败，这几乎是每个系统管理员或开发者都会遇到的头疼事。当 systemctl status 告诉你服务是 failed 的时候，下一步通常就是深入日志去探究原因。journalctl 在这里简直是救星，它能帮你快速聚焦到关键信息。
首先，最直接的办法是查看该服务的日志，并跳转到日志末尾，因为启动失败的信息通常会出现在最后：
journalctl -u [服务单元名称] -e-e 参数会将你直接带到日志的末尾，这样你就可以从最新的日志开始向上查找错误信息。如果日志量很大，你可能需要向上滚动几屏。
如果 -e 依然让你觉得信息太多，你可以尝试结合优先级过滤。服务启动失败通常会伴随着 error 或 warning 级别的日志：
journalctl -u [服务单元名称] -p err -ejournalctl -u [服务单元名称] -p warning -e
注意，err 会显示错误及更高级别的日志，warning 会显示警告及更高级别的日志。有时候，一个 warning 可能就是导致后续 error 的根源。
另一个非常有效的策略是结合 grep。虽然 journalctl 自身有强大的过滤能力，但对于日志内容中的特定关键词，grep 依然是不可替代的：
journalctl -u [服务单元名称] --no-pager | grep -i "error|fail|failed|permission denied|address already in use"
这里 --no-pager 是为了让 journalctl 直接输出到标准输出，而不是通过 less 等分页器，这样 grep 才能直接处理。grep -i 是忽略大小写，后面列举了一些常见的错误关键词。根据你的服务类型，你可能需要添加更多特定的关键词，比如数据库连接错误、端口冲突等。
有时候，服务启动失败可能不是因为服务本身的问题，而是其依赖的资源或系统环境问题。例如，端口被占用、文件权限不对、内存不足等。日志中通常会给出线索。
如果服务是新部署的，或者配置文件刚修改过，启动失败很可能是配置错误。日志里会提示类似 syntax error、invalid directive 等信息。
一个不太常用的但有时很管用的技巧是查看特定可执行文件的日志，尤其是在服务内部启动了其他子进程的情况下：
journalctl _COMM=[可执行文件名]
例如，如果你的服务内部调用了 python 脚本，而 python 脚本又报错了，你可以尝试 journalctl _COMM=python 来看看。这需要你对服务内部的运行机制有一定了解。
总之，定位服务启动失败，是一个侦探般的工作。从 journalctl -u service -e 开始，结合 grep 和优先级过滤，一步步缩小范围，通常就能找到症结所在。别忘了，有时候错误信息可能不是那么直观，需要结合服务本身的文档或者源码来理解。
journalctl 的日志默认行为是存储在内存中 (/run/log/journal)，这意味着系统重启后，这些日志就会丢失。对于生产环境，这显然是不够的，我们通常需要日志能够持久化，以便在系统重启后还能追溯历史问题。同时，日志文件会占用磁盘空间，所以管理好存储空间也至关重要。
日志持久化：
要让 journalctl 的日志持久化，你需要修改 systemd-journald 的配置文件 /etc/systemd/journald.conf。找到 Storage 选项：
#Storage=auto Storage=persistent
将 Storage=auto (或被注释掉的行) 改为 Storage=persistent。
auto：这是默认值。如果 /var/log/journal 目录存在，则日志会持久化到那里；如果不存在，则日志只存储在内存中。persistent：无论 /var/log/journal 目录是否存在，都会尝试创建并强制日志持久化到该目录。volatile：日志只存储在内存中，系统重启后会丢失。none：不存储日志。修改配置文件后，你需要重启 systemd-journald 服务来使更改生效：
sudo systemctl restart systemd-journald
完成这一步后，你的系统日志就会被写入到 /var/log/journal/ 目录下。通常，这个目录下会有一个或多个子目录，以 boot ID 命名，每个子目录包含对应启动周期的日志文件。
存储空间管理：
日志文件如果无限增长，迟早会把磁盘空间占满。systemd-journald 提供了非常方便的机制来管理日志文件的最大占用空间。同样在 /etc/systemd/journald.conf 文件中，你可以找到以下几个关键参数：
SystemMaxUse=：这是最常用的一个。它定义了所有持久化日志文件在磁盘上占用的最大空间。例如，SystemMaxUse=1G 表示日志文件最多占用1GB空间。当达到这个限制时，旧的日志文件会自动被删除。SystemKeepFree=：这个参数定义了 journald 在删除旧日志时，会尝试保留多少空闲磁盘空间。例如，SystemKeepFree=15% 表示 journald 会努力确保磁盘至少有15%的空闲空间。如果 SystemMaxUse 和 SystemKeepFree 都设置了，journald 会以更严格的那个为准。SystemMaxFileSize=：限制单个日志文件的最大大小。这有助于防止单个日志文件变得过于庞大难以处理。RuntimeMaxUse= 和 RuntimeKeepFree=：这两个参数与 SystemMaxUse 和 SystemKeepFree 类似，但它们是针对非持久化（即内存中）日志的限制。例如，一个比较合理的配置可能是：
SystemMaxUse=500M SystemKeepFree=10% SystemMaxFileSize=50M
这表示持久化日志最多占用500MB，并且会尝试保持10%的磁盘空闲，单个日志文件不超过50MB。
修改这些参数后，同样需要重启 systemd-journald 服务。
手动清理（不推荐常规操作）：
虽然 journald 会自动管理日志文件，但你也可以手动触发清理操作。
sudo journalctl --vacuum-size=100M (保留最新的100MB日志)sudo journalctl --vacuum-time=7d (保留最近7天的日志)
通常情况下，设置好 SystemMaxUse 等参数后，你不需要手动干预。手动清理更多是在调试或特殊场景下使用。总的来说，日志持久化是确保系统可追溯性的基石，而合理的空间管理则是保证系统稳定运行的关键。在生产环境中，花点时间配置好这些参数，绝对是值得的。
以上就是如何查看Linux服务日志 journalctl日志查询技巧的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
831
收藏
