查看服务日志使用 journalctl -u 服务名，如 journalctl -u nginx.service；2. 实时查看日志加 -f 参数，如 journalctl -u nginx.service -f；3. 查看最近 n 条日志使用 -n 参数，如 journalctl -u nginx.service -n 20；4. 按时间筛选使用 –since 和 –until，如 journalctl -u nginx.service –since "yesterday 09:00" –until "today 17:00"；5. 按优先级筛选使用 -p，如 journalctl -u nginx.service -p err；6. 结合 grep 或 -g 参数搜索关键词，如 journalctl -u nginx.service | grep -i “failed|Error” 或 journalctl -u nginx.service -g "failed|error"；7. 使用 less 分页查看大量日志，如 journalctl -u nginx.service | less；8. 确保日志持久化需配置 storage=persistent 或 auto 并确保 /var/log/journal 存在；9. 配置日志空间限制通过修改 /etc/systemd/journald.conf 中的 systemmaxuse 和 systemkeepfree，如 systemmaxuse=10g systemkeepfree=2g；10. 清理旧日志使用 vacuum 命令，如 sudo journalctl –vacuum-time="1 week ago" 或 sudo journalctl –vacuum-size=2g；11. 修改配置后重启 systemd-journald 服务使配置生效，即 sudo systemctl restart systemd-journald。
在linux系统上，如果你想查看由
systemd
管理的服务（比如Nginx、docker、或者你自己的自定义服务）的运行日志，
journalctl
就是你的首选工具。它能让你以非常灵活的方式查询、过滤和监控这些日志信息，告别过去散落在
/var/log
下各个文件的繁琐。
解决方案
要查看服务日志信息，最直接的方法就是使用
journalctl
命令。
通常，你可能只想看某个特定服务的日志。比如，要查看Nginx服务的日志，你可以这样：
journalctl -u nginx.service
这个命令会列出
nginx.service
从其启动以来的所有日志。如果你只想看最新的日志，并且希望它像
tail -f
一样实时更新，可以加上
-f
参数：
journalctl -u nginx.service -f
这在我日常排查问题时非常常用，特别是当服务出现异常启动或反复重启时，盯着实时日志能很快发现端倪。
有时候，你可能不需要看全部历史，只想看最近的几条，
-n
参数就派上用场了：
journalctl -u nginx.service -n 20
这会显示
nginx.service
最新的20条日志。如果你不指定服务，直接运行
journalctl
，它会显示系统上所有可用的日志，这通常信息量巨大，不适合日常直接阅读。
如何按时间范围或优先级筛选journalctl日志？
在处理日志时，时间范围和日志优先级是两个非常强大的筛选维度。我个人觉得，掌握这两个，能让你在茫茫日志海中迅速锁定目标。
要按时间范围筛选，你可以使用
--since
和
--until
参数。它们支持多种时间格式，非常灵活。
比如，查看从昨天早上9点到今天下午5点的Nginx日志：
journalctl -u nginx.service --since "yesterday 09:00" --until "today 17:00"
你也可以使用相对时间，这在排查最近发生的问题时特别方便。比如，查看过去1小时内的Docker服务日志：
journalctl -u docker.service --since "1 hour ago"
或者，查看从上次系统启动以来的所有日志，这对于定位启动阶段的问题非常有帮助：
journalctl -b
日志优先级（priority）则能让你专注于特定严重程度的信息。
journalctl
支持的优先级从高到低依次是：
emerg
(紧急),
(警报),
crit
(关键),
err
(错误),
warning
(警告),
notice
(通知),
info
(信息),
debug
(调试)。
如果你只想看Nginx服务中所有错误（
err
）及更高级别的日志，可以这样：
journalctl -u nginx.service -p err
这会过滤掉那些不那么重要的
info
或
debug
信息，让你一眼看到关键问题。我经常会结合时间和优先级一起用，比如查看过去半小时内所有服务的错误和警告信息：
journalctl --since "30 minutes ago" -p warning
这种组合拳，能极大地提高日志分析的效率。
遇到日志量巨大时，如何高效定位关键错误信息？
当服务运行时间长、日志输出又非常频繁时，
journalctl
的输出可能会铺满整个屏幕，甚至让你不知所措。这时候，结合一些文本处理工具或者
journalctl
自身的高级筛选功能就显得尤为重要。
一个最常见且有效的方法是结合
grep
命令。
grep
是Linux下强大的文本搜索工具，它可以帮你从
journalctl
的输出中查找包含特定关键词的行。
例如，你想在Nginx日志中查找所有包含“failed”或“error”的行：
journalctl -u nginx.service | grep -i "failed|error"
这里的
-i
表示忽略大小写，
|
是
grep
中的“或”逻辑。这比你肉眼去扫快多了，也准确得多。
journalctl
本身也提供了类似
grep
的功能，使用
-g
或
--grep
参数：
journalctl -u nginx.service -g "failed|error"
这通常比管道连接
grep
效率更高，因为它是在
journalctl
内部完成过滤的。
另外，对于那些需要逐行仔细检查的巨大日志文件，将
journalctl
的输出导入到
less
分页器中是个好习惯：
journalctl -u nginx.service | less
在
less
中，你可以使用
/
进行搜索，
n
和
n
进行上下跳转，这在手动排查问题时非常方便。
如果你的服务在某个特定时间点开始出现问题，而你又怀疑是某个特定的组件或功能导致的，尝试缩小范围。比如，如果问题发生在某个新部署的版本之后，你可以尝试查看从那个版本部署时间点开始的日志，并结合关键词搜索。这不仅仅是命令技巧，更是一种排查问题的逻辑思维。
journalctl日志持久化配置与空间管理策略
默认情况下，
journalctl
管理的日志可能不是持久化的，这意味着系统重启后，内存中的日志就会丢失。这对于日常维护和短期故障排查可能够用，但对于长期分析或追溯历史问题，这显然是不够的。
要让
journalctl
日志持久化，你需要确保
/var/log/journal
目录存在。如果不存在，
systemd-journald
服务会自动创建它，并开始将日志写入磁盘。通常，现代Linux发行版默认都是持久化的。你可以通过检查
/etc/systemd/journald.conf
文件来确认配置。
在这个配置文件中，有几个关键参数值得关注，它们决定了日志的存储策略和空间占用：
-
Storage
: 这个参数决定日志的存储方式。
-
：日志只存在内存中，重启即丢失（不持久化）。
-
persistent
：日志存储在
/var/log/journal
，重启后保留（持久化）。
-
auto
：如果
/var/log/journal
存在则持久化，否则只在内存中。
-
none
：完全禁用日志存储。 我通常会确保它是
persistent
或
auto
，以保证日志的完整性。
-
-
SystemMaxUse
: 这是所有持久化日志文件在磁盘上可以占用的最大空间。
-
SystemKeepFree
: 这是系统在清理旧日志时，至少要保留的空闲磁盘空间。
-
RuntimeMaxUse
和
RuntimeKeepFree
: 对应非持久化（内存中）日志的限制。
例如，如果你想限制日志最大占用10GB，并且至少保留2GB的空闲空间，你可以在
/etc/systemd/journald.conf
中设置：
[Journal] SystemMaxUse=10G SystemKeepFree=2G
修改配置后，记得重启
systemd-journald
服务使之生效：
sudo systemctl restart systemd-journald
此外，你也可以手动清理旧日志来释放空间。比如，删除所有早于一周前的日志：
sudo journalctl --vacuum-time="1 week ago"
或者，将日志大小限制在2GB：
sudo journalctl --vacuum-size=2G
这些管理策略对于服务器的长期稳定运行至关重要。日志文件如果无限增长，最终会耗尽磁盘空间，导致服务崩溃。合理配置日志保留策略，既能保证我们有足够的历史数据可查，又能避免不必要的空间浪费。毕竟，维护一个健康的系统，日志管理是不可或缺的一环。
