![长期解决方案](https://linux22.com/image/1204264/%E9%95%BF%E6%9C%9F%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88.png)
我的journalctl
日志保存了超过 300 MB 的日志,如 所示journalctl --disk-usage
。当我运行 时,一切似乎都井然有序journalctl --verify
:
$ journalctl --disk-usage
Archived and active journals take up 328.0M on disk.
$ journalctl --verify
PASS: /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/system.journal
PASS: /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/user-65534.journal
PASS: /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/system@02f1aae76e32467390ab88ba03ae559e-0000000000000001-00056515dbdcd67e.journal
PASS: /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/user-1000.journal
PASS: /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/user-65534@9838f64d6ee047bebec9d30d329064d4-00000000000005bb-00056515dbfe8d9d.journal
grep
我注意到当我通过管道传输到时系统有多慢journalctl
。
我怎样才能合理地减少我所保存内容的大小journalctl
?
答案1
systemd
配有一个漂亮的吸尘器
将日志文件限制为特定大小systemd
提供了vacuum
从日志文件中“吸取”旧信息的功能。允许的参数包括:
--vacuum-size=BYTES Reduce disk usage below specified size
--vacuum-files=INT Leave only the specified number of journal files
--vacuum-time=TIME Remove journal files older than specified time
例如,要将 312 MB 的消耗减少到 200 MB(或更少),请使用:
$ sudo journalctl --vacuum-size=200M
Deleted archived journal /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/[email protected]~ (56.0M).
Deleted archived journal /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/[email protected]~ (8.0M).
Deleted archived journal /var/log/journal/d7b25a27fe064cadb75a2f2f6ca7764e/user-1000@1bbb77599cf14c65a18af51646751696-000000000000064f-00056444d58433e1.journal (112.0M).
Vacuuming done, freed 176.0M of archived journals on disk.
节省磁盘空间
尺寸journalctl
大幅减小:
$ journalctl --disk-usage
Archived and active journals take up 136.0M on disk.
大小从 312 MB 降至 136 MB,节省了 176 MB,比预期多 64 MB。这可能是由于单个日志文件特别大而导致的一次性异常。如果有新信息,我会在一个月后修改此答案。
减少启动日志
启动日志的数量journalctl
原来是 32 个,现在减少到 26 个:
$ journalctl --list-boots
-26 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14
-25 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17
-24 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19
-23 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Sat 2018-02-24
-22 7f71ac2fb9714c49aa05989b741655f2 Sat 2018-02-24 04:24:36 MST—Sat 2018-02-24
-21 b12a48c363474e5fb39311a166a98d54 Sat 2018-02-24 04:28:09 MST—Sun 2018-02-25
-20 fbef1e659de64a0cbdcb9994f5a39457 Sun 2018-02-25 17:48:20 MST—Mon 2018-02-26
-19 3d9b4c10f98d4ef7aab1cb2baa9b74e1 Mon 2018-02-26 08:37:01 MST—Mon 2018-02-26
-18 4412b117dcc648aa9eceabcd0f205207 Mon 2018-02-26 08:38:00 MST—Mon 2018-02-26
-17 f6794cbb7fb24213a6f2c3e368f666a1 Mon 2018-02-26 08:39:12 MST—Mon 2018-02-26
-16 472f968506ed446ab12cf7abc65fa81a Mon 2018-02-26 08:49:37 MST—Mon 2018-02-26
-15 d575c609d82e4ecd8dcebb70d40160d7 Mon 2018-02-26 17:07:36 MST—Mon 2018-02-26
-14 878cfd9239a84dae80c62e7413c72951 Mon 2018-02-26 17:24:54 MST—Mon 2018-02-26
-13 7f9913c7dbff46ab9bbd7c2cbefc4d7d Mon 2018-02-26 17:35:19 MST—Mon 2018-02-26
-12 bf90829ef13a4e9fa1794bf0a88f4033 Mon 2018-02-26 17:45:12 MST—Wed 2018-02-28
-11 fb879a836c7c459ab27f6332bee6013b Wed 2018-02-28 03:56:29 MST—Wed 2018-02-28
-10 b0fec230765046f5bf3d654db1dc13ee Wed 2018-02-28 20:03:15 MST—Thu 2018-03-01
-9 72a2d6789eab4396be16348d9ead0408 Thu 2018-03-01 03:58:25 MST—Fri 2018-03-02
-8 8bccdc9b16124d26af05c34c8a30a0f5 Fri 2018-03-02 16:54:36 MST—Sat 2018-03-03
-7 40c2875db30349f5a9b1dfc849a47c05 Sat 2018-03-03 10:03:48 MST—Sat 2018-03-03
-6 781c79d2ec7946afba0fa2300e8ebe56 Sat 2018-03-03 10:04:34 MST—Sat 2018-03-03
-5 bb66dc875e414021940b7233072516d2 Sat 2018-03-03 17:43:08 MST—Tue 2018-03-06
-4 ba3bcfdc71584757b8bef9df16e7b0f6 Tue 2018-03-06 16:56:36 MST—Tue 2018-03-06
-3 60faa0fda99a4ef4b14b73c412d69e50 Tue 2018-03-06 17:00:47 MST—Tue 2018-03-06
-2 9b317bb8403344ca84dd2f288bc90410 Tue 2018-03-06 17:02:15 MST—Tue 2018-03-06
-1 dcb126be665a4531aae4312af7e51a34 Tue 2018-03-06 17:09:00 MST—Tue 2018-03-06
0 6a105af650d5442a9b03004165e58adf Tue 2018-03-06 17:42:45 MST—Wed 2018-03-07
性能提升
验证完整性的时间journalctl
明显更快:
时间从10秒减少到4秒。
归功于此来源。
长期解决方案
我创建了一项cron
任务,每月运行一次吸尘器。
评论中提到的另一个选项是SystemMaxUse=50M
在 中设置/etc/systemd/journald.conf
。实际上您可以在四个不同的地方设置该选项:
/etc/systemd/journald.conf
/etc/systemd/journald.conf.d/*.conf
/run/systemd/journald.conf.d/*.conf
/usr/lib/systemd/journald.conf.d/*.conf
其实很多选择您可以使用类似的目标:
SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles=
重新加载配置:
$ sudo systemctl restart systemd-journald
答案2
您可以指示 journalctl 显示较少的内容。有多种方法可以做到这一点,例如:
-u [unit]
或者--unit=[unit]
:这告诉 journalctl 仅显示来自 systemd 单元的日志。例如,您可以输入journalctl -u NetworkManager.service
,然后您将获得来自 NetworkManager 的日志。-S [time]
或--since=[time]
:这告诉 journalctl 忽略某个时间(指定为 )之前的任何条目yyyy-mm-dd hh:mm:ss
。如果您想要省略时间,journalctl 将使用 00:00:00,同样,如果您省略秒数,则使用 :00。此外,如果您省略日期,journalctl 将使用当前日期。以下是取自手册页的示例:journalctl -S 2012-10-30 18:17:16
。-U [time]
或--until=[time]
:这与上面的非常相似,只是它省略了来自后比指定时间更长。参数和语法相同。-n [x]
或--lines [x]
:限制输出行数,其中“x”是整数。如果输入journalctl -n 12
,则只有十二个最近的将显示日志。
您还可以减少保留的数据量,但 WinEunuuchs2Unix 已经指出了这一点,所以我不会浪费时间重复这些信息。