注：本文为关于 “journalctl 日志管理 / 查看 / 分析” 的几篇文章合辑。
使用 journalctl 查看和分析 systemd 日志（附实例）
作者：Arindam 译者：LCTT insidentally 2023-02-16 08:52
在系统管理中，日志管理是一项至关重要的任务。它不仅关乎系统的稳定运行，还对于故障排查、性能分析以及安全审计等方面起着关键作用。
本指南介绍了 systemd 的 journalctl 工具及其各种命令的基础知识。
可以使用这些命令对 Linux 中的桌面和服务器日志进行故障诊断。
以下是如何使用 journalctl 查看和分析 systemd 日志的不同例子。
简介
很多人说 systemd 不好，它对系统的影响很大，这也是一个有争议的话题。但不能否认的是，它提供了一套完善的工具来管理和排除系统故障。想象一下，当遇到一个没有 GUI 的损坏系统时，可能会把启动和 GRUB 弄得一团糟。在这种情况下，可以从一个立付Live系统启动，挂上 Linux 分区，然后浏览 systemd 的日志，找出问题所在。
systemd 有三个基本组件，如下所示：
systemd：Linux 操作系统的系统和服务管理器。systemctl：该命令用于反观和控制 systemd 系统和服务管理器的状态。systemd-analyze：该命令提供系统启动时的性能统计，并从系统和服务管理器中检索其他状态和跟踪信息。
除了这三个服务外，systemd 还提供其他服务，如 journald、logind、networkd 等。在本指南中，我们将讨论 systemd 的 journald 服务。
journald - systemd 日志服务
根据设计，systemd 提供了一个集中的方式来处理所有来自进程、应用程序等的操作系统日志。所有这些日志事件都由 systemd 的 journald 守护进程来处理。journald 守护进程收集所有来自 Linux 操作系统各处的日志，并将其作为二进制数据存储在文件中。
以二进制数据集中记录事件、系统问题的好处有很多。例如，由于系统日志是以二进制而不是文本形式存储的，可以以文本、JSON 对象等多种方式进行转译，以满足各种需求。另外，由于日志是按顺序存储的，通过对日志的日期/时间操作，超级容易追踪到单个事件。
请记住，journald 收集的日志文件数以千行计，而且不断更新每次开机、每个事件。因此，如果有一个长期运行的 Linux 操作系统，日志的大小应该以 GB 为单位。由于有着数以千计的日志，最好用基本命令进行过滤，以了解更多系统问题。
journald 配置文件
journald 的配置文件存在于以下路径中。它包含了关于如何进行日志记录的各种标志。可以看一下这个文件，并进行必要的修改。但我建议不要修改这个文件，除非知道自己在做什么。
/etc/systemd/journald.conf
journald 存储二进制日志文件的地方
journald 以二进制格式存储日志。它们被保存在这个路径下的一个目录中：
/var/log/journal
例如，在下面的路径中，有一个目录包含了迄今为止的所有系统日志。
journalctl log file path
不要使用 cat 命令，也不要使用 nano 或 vi 来打开这些文件。它们（是二进制的），无法正常显示。
使用 journalctl 来查看和分析 systemd 日志
journald 基本命令
查看 journald 日志的基本命令是：
journalctl
该命令提供了所有应用程序和进程的日志条目，包括错误、警告等。它显示的列表中，最旧的日志在顶部，当前的日志在底部。需要不断按回车键来逐行滚动浏览。也可以使用 PAGE UP 和 PAGE DOWN 键来滚动。按 q 键可以退出这个视图。
以不同时区的时间查看日志条目
默认情况下，journalctl 以当前系统时区显示日志的时间。然而，可以很容易地在命令中提供时区，将同一日志转换为不同的时区。例如，要以 UTC 查看日志，请使用以下命令：
journalctl --utc
只查看日志中的错误、警告等信息
系统产生的日志有不同的优先级。有些日志可能是可以忽略的警告，有些可能是重要的错误。可能想只看错误，不看警告。这也可以用下面的命令来实现。
要查看紧急系统信息，请使用：
journalctl -p 0
错误代码：
0: 紧急情况
1: 警报
2: 危急
3: 错误
4: 警告
5: 通知
6: 信息
7：调试
当指定错误代码时，它显示该等级及更高的所有信息。例如，如果指定下面的命令，它会显示所有优先级为 2、1 和 0 的信息：
journalctl -p 2
查看特定启动的日志
当运行 journalctl 命令时，它会显示当前启动的信息，即正在运行的会话中的信息。但也可以查看过去的启动信息。
在每次重启时，日志都会持续更新。journald 会记录不同启动时的日志。要查看不同启动时的日志，请使用以下命令。
journalctl --list-boots
- 第一个数字显示的是 journald 的唯一的启动跟踪号码，可以在下一个命令中使用它来分析该特定的启动。
- 第二个数字是启动 ID，也可以在命令中指定。
- 接下来的两个日期、时间组合是存储在相应文件中的日志的时间。如果想找出某个特定日期、时间的日志或错误，这就非常方便了。
要查看一个特定的启动号码，可以选择第一个启动跟踪号码或启动 ID，如下所示。
journalctl -b -45
journalctl -b 8bab42c7e82440f886a3f041a7c95b98
也可以使用 -x 选项，在显示屏上添加 systemd 错误信息的解释。在某些情况下，这是个救命稻草。
journalctl -xb -p 3
查看某一特定时间、日期的日志记录
journalctl 功能强大，可以在命令中提供类似英语的参数，用于时间和日期操作。
可以使用 --since 选项与 yesterday、today、tomorrow 或 now 组合。
下面是一些不同命令的例子。可以根据需要修改它们。它们是不言自明的。以下命令中的日期、时间格式为 "YYYY-MM-DD HH:MM:SS"
journalctl --since "2020-12-04 06:00:00"
journalctl --since "2020-12-03" --until "2020-12-05 03:00:00"
journalctl --since yesterday
journalctl --since 09:00 --until "1 hour ago"
也可以将上述内容与错误级别开关结合起来。
查看内核特定的日志记录
Linux 内核信息也可以从日志中提取出来。要查看当前启动时的内核信息，请使用以下命令：
journalctl -k
查看某个服务、PID 的日志
可以从 journald 日志中过滤出某个 systemd 服务单元的特定日志。例如，如果要查看 NetworkManager 服务的日志，请使用下面的命令。
journalctl -u NetworkManager.service
如果不知道服务名称，可以使用下面的命令来列出系统中的 systemd 服务。
systemctl list-units --type=service
查看用户、组的日志
如果正在分析服务器日志，在多个用户登录的情况下，这个命令很有帮助。可以先用下面的命令从用户名中找出用户的 ID。例如，要找出用户 bob 的 ID：
id -u bob
然后使用 _UID 选项指定该 ID 与来查看该用户产生的日志。
journalctl _UID=1000 --since today
同样地，使用 _GID 选项也可以查到用户组的情况。
查看一个可执行文件的日志
也可以查看某个特定程序或可执行文件的日志。例如，如果想找出 gnome-shell 的信息，可以运行以下命令。
journalctl /usr/bin/gnome-shell --since today
结束语
本指南能帮助使用 journalctl 查看分析 Linux 桌面或服务器上的 systemd 日志，排除故障。
如果知道如何使用这些命令，systemd 日志管理的功能非常强大，它能让在调试时的生活变得轻松一些。
现在所有主流的 Linux 发行版都使用 systemd。Ubuntu、Debian、Fedora、Arch 它们都使用 systemd 作为其默认的操作系统组件。如果想了解不使用 systemd 的 Linux发行版，可能想看看 MX-Linux、Gentoo、Slackware、Void Linux。
via: https://www.debugpoint.com/systemd-journalctl/
作者：Arindam 选题：lkxed 译者：Chao-zhi 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
如何使用 Journalctl 查看并操作 Systemd 日志
ZStack 云计算 于 2017-02-21 09:22:10 发布
内容简介
作为最具吸引力的优势，systemd 拥有强大的处理与系统日志记录功能。在使用其它工具时，日志往往被分散在整套系统当中，由不同的守护进程及进程负责处理，这意味着我们很难跨越多种应用程序对其内容进行解读。
相比之下，systemd 尝试提供一套集中化管理方案，从而统一打理全部内核及用户级进程的日志信息。这套系统能够收集并管理日志内容，而这也就是我们所熟知的 journal。
Journal 的实现归功于 journald 守护进程，其负责处理由内核、initrd 以及服务等产生的信息。在今天的教程中，我们将探讨如何使用 journalctl 工具，并在其帮助下访问并操作 journal 内部的数据。
总体思路
Systemd journal 的深层驱动力在于以集中方式管理对来自任意来源的日志信息。由于大部分引导进程都是由 systemd 进程处理的，因此我们有理由以标准化方式实现日志的收集与访问。其中 jornald 守护进程会收集全部来源的数据并将其以二进制格式加以存储，从而轻松实现动态操作。
这种作法能够实现多种收益。通过单一工具与数据交互，管理员能够以动态方式显示日志数据。另外，我们也可以轻松查看历史引导数据，或者将日志条目同其它相关服务加以结合，从而 完成通信问题调试。
将日志数据以二进制形式存储还意味着这些数据可根据需求随时以二进制输出格式显示。例如，大家可以通过标准 syslog 格式查看日志以实现日常管理，并在需要使用图形服务时将各条目作为 JSON 对象交由图形化服务处理。由于数据不会以纯文本形式被写入磁盘，因此我们无需进行任何格式转换。
大家可以将 systemd journal 与现有 syslog 方案配合使用，也可利用其替代现有 syslog 功能，具体取决于实际需求。尽管 systemd journal 足以涵盖大部分管理工作需求，但其同时也能够补充现有日志记录机制。例如，大家可以建立一套集中式 syslog 服务器，从而对来自多台服务器的数据进行编译；或者，我们也能够利用 systemd journal 将来自多项服务的日志汇总在单一系统当中。
设置系统时间
使用二进制 journal 的一大好处在于，它能够以 UTC 或者本地时间显示日志记录。在默认情况下，systemd 会以本地时间显示结果。
有鉴于此，在我们开始使用 journal 之前，首先要确保时区得到正确设置。Systemd 套件中还提供一款 timedatectl 工具，专门用于解决此类问题。
首先，利用 list-timezones 选项查看可用时区：
timedatectl list-timezones
结果将列出系统上可用的全部时区。而后选择与服务器所在地相匹配的项目，并使用 set-timezone 选项加以设置：
sudo timedatectl set-timezone zone
为了确保我们的设备使用正确的时间，可单独使用 timedatectl 命令或者添加 status 选项。显示结果如下：
timedatectl status
Local time: Thu 2015-02-05 14:08:06 EST
Universal time: Thu 2015-02-05 19:08:06 UTC
RTC time: Thu 2015-02-05 19:08:06
Time zone: America/New_York (EST, -0500)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
第一行所示应为正确时间。
基础日志查看
要查看 journald 守护进程收集到的日志，可使用 journalctl 命令。
在单独使用时，系统中的每个 journal 条目都会被显示在单一 pager 中供我们浏览。条目时间越早，排列越靠前：
journalctl
-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal [243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal [243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald [139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit (1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules
. . .
大家可以一页页进行翻看，不过如果系统运行时间较长，那么 systemd 中的日志也将成千上万，这也证明了 journal 数据库中可观的数据量。
其格式与标准的 syslog 日志非常相似。然而，其收集数据的来源较 syslog 要丰富得多。其中包含有来自先前引导进程、内核、initrd 以及应用程序标准错误与输出的日志。这一切都可在 journal 中查看到。
大家可能还注意到，全部时间戳都以本地时间为准。由于已经为系统正确设置了本地时间，所以显示的时间戳也都准确无误。
如果大家希望以 UTC 显示时间戳，则可使用–utc 标记：
journalctl --utc
按时间进行 journal 过滤
浏览大量数据当然有其作用，但信息量过于庞大则会让我们很难甚至根本不可能找到真正重要的内容。因此，journalctl 提供了极为关键的过滤选项。
显示当前引导进程下的日志
其中最常用的就是 - b 标记了，其将显示全部最近一次重新引导后收集到的 journal 条目。
journalctl -b
通过这种方式，我们能够识别并管理源自当前环境下的信息。
如果不使用这项功能，而且显示的引导数量超过一天，那么 journalctl 会在在系统关闭处插入说明：
. . .
-- Reboot --
. . .
这种方式能够帮助我们有效区分来自不同引导会话的信息。
过往引导记录
大家通常只需要查看当前引导环境下的信息，但有时候查看过往引导记录也非常必要。Journal 能够保存大量过往引导信息，从而允许 journalctl 轻松显示相关内容。
有些版本会在默认情况下保存过往引导信息，而有些则默认禁用这项功能。要启用此功能，可以使用以下功能以创建用于存储 journal 信息的目录：
- sudo mkdir -p /var/log/journal
或者直接编辑 journal 配置文件：
- sudo nano /etc/systemd/journald.conf
在 [Journal] 区段下将 Storage = 选项设定为 “persistent” 以启用持久记录：
/etc/systemd/journald.conf
. . .
[Journal]
Storage=persistent
当启用保存过往引导信息功能后，journalctl 会提供额外命令以帮助大家将各引导记录作为独立单元操作。要查看 Journald 中已经记录的引导信息，可使用–list-boots 选项：
journalctl --list-boots
-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
这里每次引导都将显示为一行。第一列可用于在 journalctl 中引用该次引导。如果大家需要更为准确的引用方式，则可在第二列中找到引导 ID。末尾记录的两次时间为当次引导的开始与结束时间。
要显示这些引导中的具体信息，则可使用第一或者第二列提供的信息。
例如，要查看上次引导的 journal 记录，则可使用 - 1 相对指针配合 - b 标记：
journalctl -b -1
另外，也可以使用引导 ID：
journalctl -b caf0524a1d394ce0bdbcff75b94444fe
时间窗
按照引导环境查看日志条目当然非常重要，但我们往往还需要使用与系统引导无关的时间窗作为浏览基准。这种情况在长期运行的服务器当中较为常见。
大家可以利用–since 与–until 选项设定时间段，二者分别负责说明给定时间之前与之后的记录。
时间值可以多种格式输出。对于绝对时间值，大家可以使用以下格式：
YYYY-MM-DD HH:MM:SS```
例如，我们可以通过以下命令查看全部 2015 年 1 月 10 日下午 5：15 之后的条目：
journalctl --since “2015-01-10 17:15:00”```
如果以上格式中的某些组成部分未进行填写，系统会直接进行默认填充。例如，如果日期部分未填写，则会直接显示当前日期。如果时间部分未填写，则缺省使用 “00：00：00”（午夜）。第二字段亦可留空，默认值为 “00”：
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
另外，journal 还能够理解部分相对值及命名简写。例如，大家可以使用 “yesterday”、“today”、“tomorrow” 或者 “now” 等表达。另外，我们也可以使用 “-” 或者 “+” 设定相对值，或者使用 “ago” 之前的表达。
获取昨天数据的命令如下：
journalctl –since yesterday
要获得早 9：00 到一小时前这段时间内的报告，可使用以下命令：
journalctl --since 09:00 --until "1 hour ago"
如大家所见，时间窗的过滤机制非常灵活且易用。
按信息类型过滤
现在我们要探讨如何利用感兴趣的服务或者组件类型实现过滤。Systemd journal 同样提供多种方式供大家选择。
按单元
最常用的此类过滤方式当数按单元过滤了。我们可以使用 - u 选项实现这一效果。
例如，要查看系统上全部来自 Nginx 单元的日志，可使用以下命令：
journalctl -u nginx.service```
一般来讲，我们可能需要同时按单元与时间进行信息过滤。例如，检查今天某项服务的运行状态：
journalctl -u nginx.service --since today
我们还可以充分发挥 journal 查看多种单元信息的优势。例如，如果我们的 Nginx 进程接入某个 PHP-FPM 单元以处理动态内容，则可将这两个单元合并并获取按时间排序的查询结果：
journalctl -u nginx.service -u php-fpm.service --since today```
这种能力对于不同程序间交互及系统调试显然非常重要。
按进程、用户或者群组 ID
由于某些服务当中包含多个子进程，因此如果我们希望通过进程 ID 实现查询，也可以使用相关过滤机制。
这里需要指定_PID 字段。例如，如果 PID 为 8088，则可输入：
journalctl _PID=8088
有时候我们可能希望显示全部来自特定用户或者群组的日志条目，这就需要使用_UID 或者_GID。例如，如果大家的 Web 服务器运行在 www-data 用户下，则可这样找到该用户 ID：
id -u www-data
33```
接下来，我们可以使用该 ID 返回过滤后的 journal 结果：
journalctl _UID=33 --since today
Systemd journal 拥有多种可实现过滤功能的字段。其中一些来自被记录的进程，有些则由 journald 用于自系统中收集特定时间段内的日志。
之前提到的_PID 属于后一种。Journal 会自动记录并检索进程 PID，以备日后过滤之用。大家可以查看当前全部可用 journal 字段：
man systemd.journal-fields```
下面来看针对这些字段的过滤机制。-F 选项可用于显示特定 journal 字段内的全部可用值。
例如，要查看 systemd journal 拥有条目的群组 ID，可使用以下命令：
journalctl -F _GID
32
99
102
133
81
84
100
0
124
87
其将显示全部 journal 已经存储至群组 ID 字段内的值，并可用于未来的过滤需求。
按组件路径
我们也可以提供路径位置以实现过滤。
如果该路径指向某个可执行文件，则 journalctl 会显示与该可执行文件相关的全部条目。例如，要找到与 bash 可执行文件相关的条目：
journalctl /usr/bin/bash
一般来讲，如果某个单元可用于该可执行文件，那么此方法会更为明确且能够提供更好的相关信息（与子进程相关的条目等）。但有时候，这种作法则无法奏效。
显示内核信息
内核信息通常存在于 dmesg 输出结果中，journal 同样可对其进行检索。要只显示此类信息，可添加 - k 或者–dmesg 标记：
journalctl -k
默认情况下，其会显示当前引导环境下的全部内核信息。大家也可以使用常规的引导选择标记对此前的引导记录进行查询。例如，要查询五次之前引导环境的信息：
journalctl -k -b -5
按优先级
管理员们可能感兴趣的另一种过滤机制为信息优先级。尽管以更为详尽的方式查看日志也很有必要，不过在理解现有信息时，低优先级日志往往会分散我们的注意力并导致理解混乱。
大家可以使用 journalctl 配合 - p 选项显示特定优先级的信息，从而过滤掉优先级较低的信息。
例如，只显示错误级别或者更高的日志条目：
journalctl -p err -b
这将只显示被标记为错误、严重、警告或者紧急级别的信息。Journal 的这种实现方式与标准 syslog 信息在级别上是一致的。大家可以使用优先级名称或者其相关量化值。以下各数字为由最高到最低优先级：
- 0: emerg
- 1: alert
- 2: crit
- 3: err
- 4: warning
- 5: notice
- 6: info
- 7: debug
以上为可在 - p 选项中使用的数字或者名称。选定某一优先级会显示等级与之等同以及更高的信息。
修改 journal 显示内容
到这里，过滤部分已经介绍完毕。我们也可以使用多种方式对输出结果进行修改，从而调整 journalctl 的显示内容。
截断或者扩大输出结果
我们可以缩小或者扩大输出结果，从而调整 journalctl 的显示方式。
在默认情况下，journalctl 会在 pager 内显示各条目，并通过右箭头键访问其信息。
如果大家希望截断输出内容，向其中插入省略号以代表被移除的信息，则可使用–no-full 选项：
journalctl --no-full
. . .
Feb 04 20:54:13 journalme sshd [937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd [937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd [937]: PAM 2 more authentication failures; logname...ot
大家也可以要求其显示全部信息，无论其是否包含不可输出的字符。具体方式为添加 - a 标记：
journalctl -a
标准输出结果
默认情况下，journalctl 会在 pager 内显示输出结果以便于查阅。如果大家希望利用文本操作工具对数据进行处理，则可能需要使用标准格式。在这种情况下，我们需要使用–no-pager 选项：
journalclt --no-pager
这样相关结果即可根据需要被重新定向至磁盘上的文件或者处理工具当中。
输出格式
如果大家需要对 journal 条目进行处理，则可能需要使用更易使用的格式以简化数据解析工作。幸运的是，journal 能够以多种格式进行显示，只须添加 - o 选项加格式说明即可。
例如，我们可以将 journal 条目输出为 JSON 格式：
journalctl -b -u nginx -o json
{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
. . .
这种方式对于工具解析非常重要。大家也可以使用 json-pretty 格式以更好地处理数据结构：
journalctl -b -u nginx -o json-pretty
{
"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
"__REALTIME_TIMESTAMP" : "1422990364739502",
"__MONOTONIC_TIMESTAMP" : "27200938",
"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
"PRIORITY" : "6",
"_UID" : "0",
"_GID" : "0",
"_CAP_EFFECTIVE" : "3fffffffff",
"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
"_HOSTNAME" : "desktop",
"SYSLOG_FACILITY" : "3",
"CODE_FILE" : "src/core/unit.c",
"CODE_LINE" : "1402",
"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
"SYSLOG_IDENTIFIER" : "systemd",
"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
"_TRANSPORT" : "journal",
"_PID" : "1",
"_COMM" : "systemd",
"_EXE" : "/usr/lib/systemd/systemd",
"_CMDLINE" : "/usr/lib/systemd/systemd",
"_SYSTEMD_CGROUP" : "/",
"UNIT" : "nginx.service",
"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}
. . .
以下为可用于显示的各类格式：
- cat: 只显示信息字段本身。
- export: 适合传输或备份的二进制格式。
- json: 标准 JSON，每行一个条目。
- json-pretty: JSON 格式，适合人类阅读习惯。
- json-sse: JSON 格式，经过打包以兼容 server-sent 事件。
- short: 默认 syslog 类输出格式。
- short-iso: 默认格式，强调显示 ISO 8601 挂钟时间戳。
- short-monotonic: 默认格式，提供普通时间戳。
- short-precise: 默认格式，提供微秒级精度。
- verbose: 显示该条目的全部可用 journal 字段，包括通常被内部隐藏的字段。
这些选项允许大家以最适合需求的格式显示 journal 条目。
活动进程监控
Journalctl 命令还能够帮助管理员以类似于 tail 的方式监控活动或近期进程。这项功能内置于 journalctl 当中，允许大家在无需借助其它工具的前提下实现访问。
显示近期日志
要显示特定数量的记录，大家可以使用 - n 选项，具体方式为 tail -n。
默认情况下，其会显示最近十条记录：
journalctl -n
大家可以在 - n 之后指定要查看的条目数量：
journalctl -n 20
追踪日志
要主动追踪当前正在编写的日志，大家可以使用 - f 标记。方式同样为 tail -f：
journalctl -f
Journal 维护
存储这么多数据当然会带来巨大压力，因此我们还需要了解如何清理部分陈旧日志以释放存储空间。
了解现有磁盘使用量
大家可以利用–disk-usage 标记查看 journal 的当前磁盘使用量：
journalctl --disk-usage
Journals take up 8.0M on disk.
删除旧有日志
如果大家打算对 journal 记录进行清理，则可使用两种不同方式（适用于 systemd 218 及更高版本）。
如果使用–vacuum-size 选项，则可硬性指定日志的总体体积，意味着其会不断删除旧有记录直到所占容量符合要求：
sudo journalctl --vacuum-size=1G
另一种方式则是使用–vacuum-time 选项。任何早于这一时间点的条目都将被删除。
例如，去年之后的条目才能保留：
sudo journalctl --vacuum-time=1years
限定 Journal 扩展
大家可以配置自己的服务器以限定 journal 所能占用的最高容量。要实现这一点，我们需要编辑 /etc/systemd/journald.conf 文件。
以下条目可用于限定 journal 体积的膨胀速度：
- SystemMaxUse=: 指定 journal 所能使用的最高持久存储容量。
- SystemKeepFree=: 指定 journal 在添加新条目时需要保留的剩余空间。
- SystemMaxFileSize=: 控制单一 journal 文件大小，符合要求方可被转为持久存储。
- RuntimeMaxUse=: 指定易失性存储中的最大可用磁盘容量（/run 文件系统之内）。
- RuntimeKeepFree=: 指定向易失性存储内写入数据时为其它应用保留的空间量（/run 文件系统之内）。
- RuntimeMaxFileSize=: 指定单一 journal 文件可占用的最大易失性存储容量（/run 文件系统之内）。
通过设置上述值，大家可以控制 journald 对服务器空间的消耗及保留方式。
总结
到这里，systemd journal 对系统及应用数据的收集与管理机制就介绍完毕了。其出色的灵活性源自将广泛的元数据自动记录至集中化日志之内。另外，journalctl 命令则显著简化了 journal 的使用方式，从而让更多管理员得以利用它完成面向不同应用组件的分析与相关调试工作。
本文来源自 DigitalOcean Community。英文原文：How To Use Journalctl to View and Manipulate Systemd Logs By Justin Ellingwood
翻译：diradw
Systemd 日志管理服务：Journald 以及重要配置选项
简单 IoT 于 2020-03-07 17:26:42 发布
Journald 是 systemd 引入的用于收集和存储日志数据的系统服务。它试图使系统管理员可以在越来越多的日志消息中更轻松地找到有趣且相关的信息。为了实现此目标，日记中的主要更改之一是用为日志消息优化的特殊文件格式替换简单的纯文本日志文件。这种文件格式使系统管理员可以更有效地访问相关消息。它还为单个系统带来了数据库驱动的集中日志记录实现的某些功能。
概览 systemd-journald 系统
Journald 系统主要由三个主要的系统日记服务组件组成：
- 守护程序：
systemd日志服务由systemd-journald守护程序处理。 - 配置文件：日志服务的配置在
/etc/systemd/journald.conf里面设置。 - 日志搜索程序：用于搜索日记日志文件的程序是
journalctl。
本文主要介绍systemd-journald日志相关的重要配置选项：主要包括systemd-journald logrotate和存储类型选择功能。
Journald 支持的不同类型的存储
我们可以通过修改 /etc/systemd/journald.conf 文件控制存储类型值，在 [Journal] 字符串下面可以修改存储类型。
[Journal]
#Storage=auto
Storage 支持的值为 volatile，persistent，auto 和 none，默认是 auto，所有值的含义如下
- 如果为
volatile，则日志数据将仅存储在内存中，即在/run/log/journal目录下（根据需要创建）。 - 如果是
persistent，则数据将会存储在磁盘上，即/var/log/journal目录下，并且在早期引导阶段磁盘不可写的时候把数据保存到/run/log/journal目录下。 auto值意味着把日志数据存储在/var/log/journal/目录中。但是该目录必须已经存在并且设置了适当的权限。如果不存在，则日记数据将存储在易失性/run/log/journal/目录中，并且在系统关闭时会删除该数据。none关闭所有存储，所有接收到的日志数据将被丢弃。
对日志文件执行 logrotate
systemd-journald 日志文件的 logrotate 将基于以下值执行：
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
这些设置将会限制日志文件的大小上限。 以 System 开头的选项用于限制磁盘使用量， 也就是 /var/log/journal 的使用量。 以 Runtime 开头的选项用于限制内存使用量， 也就是 /run/log/journal 的使用量。
RuntimeMaxUse/SystemMaxUse=控制日志最大可使用多少磁盘空间，然后对日志文件执行systemd-journald logrotate。默认为分配给节点的总物理内存的 10％RuntimeKeepFree/SystemKeepFree=控制systemd-journald将为其他用途保留多少磁盘空间，之后将对日志文件执行systemd-journald logrotate。默认为分配给节点的总物理内存的 15％SystemMaxFileSize=/RuntimeMaxFileSize=限制单个日志文件的最大体积， 到达此限制后日志文件将会自动滚动。 默认值是对应的SystemMaxUse=/RuntimeMaxUse=值的 1/8 ， 这也意味着日志滚动 默认保留 7 个历史文件。SystemMaxFiles/RuntimeMaxFiles=限制最多允许同时存在多少个日志文件， 超出此限制后， 最老的日志文件将被删除， 而当前的活动日志文件 则不受影响。 默认值为 100 个。MaxRetentionSec=日志滚动的时间间隔。通常并不需要使用基于时间的日志滚动策略， 因为由SystemMaxFileSize/RuntimeMaxFileSize=控制的基于文件大小的日志滚动策略已经可以确保日志文件的大小不会超标。 默认值是一个月， 设为零表示禁用基于时间的日志滚动策略。MaxRetentionSec=日志文件的最大保留期限。 当日志文件的最后修改时间 (mtime) 与当前时间之差，大于此处设置的值时，日志文件将会被删除。 通常并不需要使用基于时间的日志删除策略。
如果我们检查 systemd-journald 的状态，那么我们可以看到它的报告日志已轮换：
$ systemctl status systemd-journald
● systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
Active: active (running) since Sat 2019-11-23 08:34:43 CST; 3 months 14 days ago
Docs: man:systemd-journald.service (8)
man:journald.conf (5)
Main PID: 404 (systemd-journal)
Status: "Processing requests..."
Tasks: 1 (limit: 9484)
CGroup: /system.slice/systemd-journald.service
└─404 /lib/systemd/systemd-journald
Nov 23 08:34:43 ubuntu systemd-journald [404]: Journal started
Nov 23 08:34:43 ubuntu systemd-journald [404]: Runtime journal (/run/log/journal/0bc1c3fec0b84c47ac1b0ea61a9db220) is 8.0M, max 79.5M, 71.5M free.
Nov 23 08:34:43 ubuntu systemd-journald [404]: Time spent on flushing to /var is 46.023ms for 1754 entries.
Nov 23 08:34:43 ubuntu systemd-journald [404]: System journal (/var/log/journal/0bc1c3fec0b84c47ac1b0ea61a9db220) is 504.0M, max 4.0G, 3.5G free.
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
journalctl 清理 journal 日志
2018-06-25 09:57 九重霄
在 CentOS 7 开始使用的 systemd 使用了 journal 日志，这个日志的管理方式和以往使用 syslog 的方式不同，可以通过管理工具维护。
使用df -h检查磁盘文件，可以看到/run目录下有日志目录/run/log/journal，占用了数G空间
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 8.5G 4.2G 4.4G 49% /
tmpfs 16G 1.6G 15G 11% /run
在日志目录下有很多历史累积的日志。
检查当前journal使用磁盘量
journalctl --disk-usage
清理方法可以采用按照日期清理，或者按照允许保留的容量清理
journalctl --vacuum-time=2d
journalctl --vacuum-size=500M
如果要手工删除日志文件，则在删除前需要先轮转一次journal日志
systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald.service
要启用日志限制持久化配置，可以修改 /etc/systemd/journald.conf
SystemMaxUse=16M
ForwardToSyslog=no
然后重启
systemctl restart systemd-journald.service
检查journal是否运行正常以及日志文件是否完整无损坏
journalctl --verify
journal配置参考
[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
RateLimitInterval=30s
RateLimitBurst=500
SystemMaxUse=2048M
#SystemKeepFree=1024M
#SystemMaxFileSize=
RuntimeMaxUse=2048M
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
ForwardToKMsgno=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
MaxLevelStore=warning
MaxLevelSyslog=warning
MaxLevelKMsg=warning
MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
配置目录及其优先级
默认设置是在编译期间确定的， 所以仅在确实需要修改默认设置的情况下， 才需要使用配置文件。位于 /etc/systemd/ 目录中的初始配置文件， 仅包含了展示选项默认值的注释， 目的在于方便系统管理员查看和直接修改。
如果软件包想要自定义某些默认设置， 那么必须将自定义的配置文件安装到 /usr/lib/systemd/*.conf.d/ 目录中。 /etc/ 目录仅供系统管理员使用。 系统管理员可以利用下面的逻辑来覆盖默认设置： 主配置文件最先被读取， 优先级也最低。 所有 *.conf.d/ 中的配置文件 都会覆盖主配置文件中的设置。 所有 *.conf.d/ 中的配置文件(无论位于哪个目录中)， 统一按照文件名的字典顺序处理。 当多个配置文件都设置了同一个选项的时候： (1)如果该选项仅接受一个单一值，那么仅以文件名最靠后(字典顺序)的那一个为准； (2)如果该选项可接受一个值列表，那么将会按照文件名的字典顺序将所有值列表拼接起来。 为了便于排序， 建议给所有 *.conf.d/ 中的配置文件 都加上两位十进制数字的文件名前缀。
如果系统管理员想要屏蔽 /usr/lib/ 目录中的某个配置文件， 那么最佳做法是在 /etc/ 目录中 创建一个指向 /dev/null 的同名符号链接， 即可彻底屏蔽 /usr/lib/ 目录中的同名文件。
选项
所有选项都位于 “[Journal]” 小节：
-
Storage=在哪里存储日志文件： “
volatile” 表示仅保存在内存中， 也就是仅保存在/run/log/journal目录中(将会被自动按需创建)。 “persistent” 表示优先保存在磁盘上， 也就优先保存在/var/log/journal目录中(将会被自动按需创建)， 但若失败(例如在系统启动早期"/var"尚未挂载)， 则转而保存在/run/log/journal目录中(将会被自动按需创建)。 “auto”(默认值) 与 “persistent” 类似， 但不自动创建/var/log/journal目录， 因此可以根据该目录的存在与否决定日志的保存位置。 “none” 表示不保存任何日志(直接丢弃所有收集到的日志)， 但日志转发(见下文)不受影响。 默认值是 “auto” -
Compress=默认值"yes"表示： 压缩存储大于特定阈值的对象。
-
Seal=默认值"yes"表示：如果存在一个"sealing key"(由 journalctl(1) 的
--setup-keys命令创建)， 那么就为所有持久保存的日志文件启用 FSS(Seekable Sequential Key Generators)保护， 以避免日志文件被恶意或无意的修改。 -
SplitMode=设置是否按照每个用户分割日志文件，以实现对日志的访问控制(日志守护进程会确保每个用户都能读取自己的日志文件)。 可以使用的分割策略如下： “
uid” 表示每个用户都有自己专属的日志文件(无论该用户是否拥有登录会话)，但系统用户的日志依然记录到系统日志中。这是默认值。 “none” 表示不对日志文件按不同用户进行分割，而是将所有日志都记录到系统日志中。这意味着非特权用户根本无法读取属于自己的日志信息。 注意，仅分割持久保存的日志(/var/log/journal)， 永不分割内存中的日志(/run/log/journal)。 -
RateLimitIntervalSec=,RateLimitBurst=用于限制日志的生成速度(设为零表示不作限制)。
RateLimitIntervalSec=用于设置一个时间段长度，默认值是30秒。RateLimitBurst=用于设置一个正整数，表示消息条数，默认值是1000条。 表示在RateLimitIntervalSec=时间段内， 每个服务最多允许产生RateLimitBurst=数量(条数)的日志。 在同一个时间段内，超出数量限制的日志将被丢弃，直到下一个时间段才能再次开始记录。 对于所有被丢弃的日志消息，仅用一条类似"xxx条消息被丢弃"的消息来代替。 这个限制是针对每个服务的限制，一个服务超限并不会影响到另一个服务的日志记录。RateLimitIntervalSec=可以使用下面的时间单位：“ms”, “s”, “min”, “h”, “d” -
SystemMaxUse=,SystemKeepFree=,SystemMaxFileSize=,SystemMaxFiles=,RuntimeMaxUse=,RuntimeKeepFree=,RuntimeMaxFileSize=,RuntimeMaxFiles=限制日志文件的大小上限。 以 “
System” 开头的选项用于限制磁盘使用量， 也就是/var/log/journal的使用量。 以 “Runtime” 开头的选项用于限制内存使用量， 也就是/run/log/journal的使用量。 以 “System” 开头的选项仅在/var/log/journal目录确实存在且可写时才有意义。 但以 “Runtime” 开头的选项永远有意义。 也就是说， 在系统启动早期/var尚未挂载时、 或者系统管理员禁止在磁盘上存储日志的时候， 仅有 “Runtime” 开头的选项有意义。 journalctl 与 systemd-journald 工具会忽略日志目录中 所有后缀名不等于 “.journal” 或 “.journal~” 的文件。 换句话说， 日志目录中不应该存在后缀名不等于 “.journal” 或 “.journal~” 的文件， 因为这些文件永远不会被清理。SystemMaxUse=与RuntimeMaxUse=限制全部日志文件加在一起最多可以占用多少空间。SystemKeepFree=与RuntimeKeepFree=表示除日志文件之外，至少保留多少空间给其他用途。 systemd-journald 会同时考虑这两个因素， 并且尽量限制日志文件的总大小，以同时满足这两个限制。SystemMaxUse=与RuntimeMaxUse=的默认值是10%空间与4G空间两者中的较小者；SystemKeepFree=与RuntimeKeepFree=的默认值是15%空间与4G空间两者中的较大者； 如果在 systemd-journald 启动时， 文件系统即将被填满并且已经超越了SystemKeepFree=或RuntimeKeepFree=的限制，那么日志记录将被暂停。 也就是说，如果在创建日志文件时，文件系统有充足的空闲空间， 但是后来文件系统被其他非日志文件过多占用， 那么 systemd-journald 只会立即暂停日志记录， 但不会删除已经存在的日志文件。SystemMaxFileSize=与RuntimeMaxFileSize=限制单个日志文件的最大体积， 到达此限制后日志文件将会自动滚动。 默认值是对应的SystemMaxUse=与RuntimeMaxUse=值的1/8 ， 这也意味着日志滚动默认保留7个历史文件。 日志大小的值可以使用以1024为基数的 K, M, G, T, P, E 后缀， 分别对应于 1024, 1024², … 字节。SystemMaxFiles=与RuntimeMaxFiles=限制最多允许同时存在多少个日志文件， 超出此限制后， 最老的日志文件将被删除， 而当前的活动日志文件则不受影响。 默认值为100个。 -
MaxFileSec=日志滚动的时间间隔。 通常并不需要使用基于时间的日志滚动策略， 因为由
SystemMaxFileSize=与RuntimeMaxFileSize=控制的基于文件大小的日志滚动策略 已经可以确保日志文件的大小不会超标。 默认值是一个月， 设为零表示禁用基于时间的日志滚动策略。 可以使用 “year”, “month”, “week”, “day”, “h”, “m” 时间后缀， 若不使用后缀则表示以秒为单位。 -
MaxRetentionSec=日志文件的最大保留期限。 当日志文件的最后修改时间超过此期限后将被删除。 默认值零表示不使用基于时间的日志删除策略。 通常并不需要使用基于时间的日志删除策略，因为由
SystemMaxUse=与RuntimeMaxUse=控制的基于文件大小的日志滚动策略 已经可以确保日志文件的大小不会超标。 可以使用 “year”, “month”, “week”, “day”, “h”, “m” 时间后缀， 若不使用后缀则表示以秒为单位。 -
SyncIntervalSec=向磁盘刷写日志文件的时间间隔，默认值是五分钟。 刷写之后，日志文件将会处于离线(OFFLINE)状态。 注意，当接收到 CRIT, ALERT, EMERG 级别的日志消息后， 将会无条件的立即刷写日志文件。 因此该设置仅对 ERR, WARNING, NOTICE, INFO, DEBUG 级别的日志消息有意义。
-
ForwardToSyslog=,ForwardToKMsg=,ForwardToConsole=,ForwardToWall=ForwardToSyslog=表示是否将接收到的日志消息转发给传统的 syslog 守护进程，默认值为"no"。 如果设为"yes"，但是没有任何进程监听对应的套接字，那么这种转发是无意义的。 此选项可以被内核引导选项 “systemd.journald.forward_to_syslog” 覆盖。ForwardToKMsg=表示是否将接收到的日志消息转发给内核日志缓冲区(kmsg)，默认值为"no"。 此选项可以被内核引导选项 “systemd.journald.forward_to_kmsg” 覆盖。ForwardToConsole=表示是否将接收到的日志消息转发给系统控制台，默认值为"no"。 如果设为"yes"，那么可以通过下面的TTYPath=指定转发目标。 此选项可以被内核引导选项 “systemd.journald.forward_to_console” 覆盖。ForwardToWall=表示是否将接收到的日志消息作为警告信息发送给所有已登录用户，默认值为"yes"。 此选项可以被内核引导选项 “systemd.journald.forward_to_wall” 覆盖。 -
MaxLevelStore=,MaxLevelSyslog=,MaxLevelKMsg=,MaxLevelConsole=,MaxLevelWall=MaxLevelStore=设置记录到日志文件中的最高日志等级，默认值为"debug"；MaxLevelSyslog=设置转发给传统的 syslog 守护进程的最高日志等级，默认值为"debug"；MaxLevelKMsg=设置转发给内核日志缓冲区(kmsg)的最高日志等级，默认值为"notice"；MaxLevelConsole=设置转发给系统控制台的最高日志等级，默认值为"info"；MaxLevelWall=设置作为警告信息发送给所有已登录用户的最高日志等级，默认值为"emerg"； 这些选项既可以设为日志等级的名称， 也可以设为日志等级对应的数字： “emerg”(0), “alert”(1), “crit”(2), “err”(3), “warning”(4), “notice”(5), “info”(6), “debug”(7) 。 所有高于设定等级的日志消息都将被直接丢弃， 仅保存/转发小于等于设定等级的日志消息。 上述设置可以被如下内核引导选项覆盖： “systemd.journald.max_level_store=”, “systemd.journald.max_level_syslog=”, “systemd.journald.max_level_kmsg=”, “systemd.journald.max_level_console=”, “systemd.journald.max_level_wall=” -
ReadKMsg=是否收集内核日志。 默认值 yes 表示从
/dev/kmsg中读取内核产生的日志消息。 -
TTYPath=指定
ForwardToConsole=yes时所使用的控制台TTY， 默认值是/dev/console -
LineMax=在将日志流转化为日志记录时，每条日志记录最大允许的长度(字节)。 如果将单元的标准输出(STDOUT)/标准错误(STDERR)通过流套接字连接到日志中， 那么将会以换行符(“
\n”, ASCII 10)与NUL字符(“\0”, ASCII 0)作为分割符， 把日志流切分成一条条独立的日志记录。 如果超过此处设置的长度之后仍然没有遇到分割符， 那么将会自动插入一个分割符，以强制将单行超长日志截断为多行。 此选项的值越大，每个日志流客户端日志守护进程占用的内存也越大(最大值等于此选项的值)。 另外，此选项的值太大也会造成与传统日志传输协议的不兼容(太长的日志无法封装在单个AF_UNIX或AF_INET报文内)。 此选项的值以字节为单位，同时也可以在数字的末尾加上 K, M, G, T 后缀(以1024为基准)。 默认值 48K 是一个足够大并且也能保持与传统日志传输协议兼容的值。 注意，不能设为小于 79 的值(将被自动提升到79)。
日志转发
有两种不同的日志转发方法： (1)通过套接字文件(/run/systemd/journal/syslog) 可以将收集到的日志消息 立即转发给套接字的监听进程(传统的 syslog 守护进程)。 此方法受 ForwardToSyslog= 指令的控制。 (2)日志接收进程作为客户端运行，就像 journalctl(1) 一样读取日志文件。 因此，此方法在 Storage=none 时无效。 此方法不能实时读取日志消息， 但是可以读取先前保存的日志消息(例如在系统启动完成之后读取系统启动早期的日志消息)。 此方法还可以读取到完整的日志元数据。 此方法一般无法读取当前最新的日志消息， 只能读取已经被记录到文件系统上的日志消息。 注意，syslog 守护进程通常使用此方法(而不是前一种方法)， 因此 Storage= 选项(而不是 ForwardToSyslog= 选项) 不应该设为"none"。
via：
-
如何使用 Journalctl 查看并操作 Systemd 日志_journalctl -u nginx.service-CSDN 博客 ZStack 云计算 于 2017-02-21 09:22:10 发布
https://blog.csdn.net/zstack_org/article/details/56274966 -
Systemd日志管理服务：Journald以及重要配置选项_设置journald大小为100-CSDN博客 简单 IoT 于 2020-03-07 17:26:42 发布
https://simpleiot.blog.csdn.net/article/details/104716582 -
journalctl 清理 journal 日志 - 九重霄 - 博客园 posted on 2018-06-25 09:57 九重霄
https://www.cnblogs.com/jiuchongxiao/p/9222953.html